DEV Community: CopperSunDev

GEO: What the Research Says About AI Search

CopperSunDev — Thu, 25 Jun 2026 23:40:33 +0000

Three independent research streams — academic, practitioner, and platform — have studied how AI search systems choose which websites to cite. Their findings overlap more than they disagree, and the conclusions challenge several popular assumptions about how to optimize for AI.

This post synthesizes the full research landscape. If you want to skip straight to implementation, see the GEO guide for the complete framework. If you want the deep dive on one specific finding, Part 1 of our LLM Visibility series covers answer capsules in detail.

Quick Navigation

What GEO Research Exists Today
The Princeton GEO Study
The Answer Capsule Research
Platform-Specific Citation Behavior
What the Research Agrees On
What the Research Disagrees On
What This Means for Small Businesses
GEO Glossary
Frequently Asked Questions

What GEO Research Exists Today

GEO research falls into three streams, each approaching the problem from a different angle.

Academic research treats GEO as a formal optimization problem. Researchers run controlled experiments where they modify content using specific strategies and measure whether AI systems cite it more or less often. The Princeton GEO study (Aggarwal et al., 2024) is the most cited example.

Practitioner research studies what already works in the wild. Instead of experimenting with modifications, researchers analyze pages that AI systems are already citing and look for shared structural traits. Adam Gnuse's answer capsule research (published via Search Engine Land, 2025) is the primary example, analyzing 15 domains and 7,500 ChatGPT referral sessions.

Platform research examines how different AI systems behave when selecting sources. This includes tracking studies like Paul DeMott's work on measuring LLM visibility (also published via Search Engine Land) and Authoritas's data on citation patterns across platforms.

None of these streams alone tells the complete story. Together, they form a surprisingly consistent picture.

The Princeton GEO Study

The Princeton study (Aggarwal et al., 2024) was the first academic paper to define "Generative Engine Optimization" as a discipline. The researchers tested nine content optimization strategies and measured their effect on AI citation rates.

The Nine Strategies Tested

Strategy	What They Did	Citation Impact
Cite Sources	Added authoritative citations	+30-40%
Add Statistics	Included specific data points	+30-40%
Expert Quotes	Added quotations from experts	+41%
Fluency Optimization	Improved writing quality alone	Negligible
Technical Terms	Added domain-specific terminology	Moderate
Authoritative Tone	Rewrote in authoritative voice	Moderate
Unique Wording	Used distinctive phrasing	Moderate
Easy to Understand	Simplified language	Moderate
Keyword Stuffing	Added extra keywords	Negative

Key Findings

Expert quotes had the single highest impact at +41% citation improvement. This was the most surprising result — simply adding a relevant expert quotation to content made AI systems significantly more likely to cite it.

Citations and statistics tied for second at +30-40%. Content that included specific data points or referenced authoritative sources saw consistent citation improvements across AI platforms.

Fluency alone did not help. Improving writing quality without changing substance had negligible impact. This is a critical finding because many GEO guides recommend "writing better" as a primary strategy. The Princeton data says better writing only helps when combined with structural changes.

Keyword stuffing actively hurt. Adding extra keywords to content reduced citation rates, suggesting AI systems can detect and penalize low-quality optimization attempts.

What This Means

The Princeton research establishes that GEO is real and measurable. Content modifications can meaningfully change whether AI systems cite you. But the modifications that work are substantive (adding data, quotes, citations) rather than cosmetic (rewriting for fluency, adding keywords).

The Answer Capsule Research

Adam Gnuse's practitioner research (Search Engine Land, 2025) analyzed pages that ChatGPT was already citing and identified structural patterns that the cited pages shared.

The core findings:

72.4% of blog posts cited by ChatGPT contained answer capsules — concise, self-contained explanations placed immediately after headings
91% of cited passages contained no outbound links within the capsule text
52.2% of cited posts contained original data (proprietary statistics, original research, first-party case studies)
38% of pages ranking on Google's first page received zero AI referral traffic

For a full breakdown of answer capsules — what they are, how to write them, and examples — see Part 1: Answer Capsules.

How This Connects to Princeton

The Gnuse findings and Princeton findings are complementary. Princeton tested modifications and found that adding statistics and expert quotes improved citations. Gnuse studied existing cited content and found that cited pages already contained original data and self-contained answer passages.

Both point to the same conclusion: AI systems prefer content that provides complete, extractable answers with supporting evidence.

Platform-Specific Citation Behavior

Different AI platforms choose sources differently. Understanding these differences matters because a page optimized for one platform may not perform identically on another.

ChatGPT

ChatGPT draws from its training data and, when browsing is enabled, from real-time web searches. Its citation behavior tends to favor:

Pages with clear, extractable passages
Content with original data or unique framing
Established domains — but domain authority is not the only factor

Perplexity

Perplexity searches the web in real time for every query and cites sources prominently. It tends to cite:

Multiple sources per response (typically 5-10 citations)
Pages that rank well in traditional search
Content with specific, quotable statements

Google AI Overviews

Google AI Overviews draw primarily from Google's existing search index. Pages that rank well in traditional search results are more likely to be cited in AI Overviews. This creates the strongest overlap between traditional SEO and GEO — Authoritas research found 62% overlap between organic rankings and AI Overview citations.

Claude

Claude uses search-augmented generation when connected to web search tools. Its citation patterns are similar to ChatGPT's browsing mode — structured content with clear answers tends to be cited more frequently.

The Practical Implication

There is no single "AI search algorithm" to optimize for. Each platform has different citation behaviors. But the structural principles (clear answers, original data, extractable passages) work across all of them.

What the Research Agrees On

Despite different methodologies and data sources, the three research streams converge on several points.

Structure Matters More Than Authority

Princeton found citation improvements of +30-40% regardless of site authority. Gnuse found that cited content shared structural traits (answer capsules, link-free formatting) independent of domain strength. This does not mean authority is irrelevant — it means formatting and substance can overcome authority gaps.

Self-Contained Answers Win

AI systems need to extract a passage and present it as part of a response. Content that provides complete, self-contained answers within a few sentences is easier for AI to cite than content that spreads an answer across multiple paragraphs or requires clicking through to understand.

Original Data Is a Moat

Both Princeton (+30-40% for statistics) and Gnuse (52.2% of cited posts had original data) found that original data significantly increases citation likelihood. This makes intuitive sense — AI cannot fabricate your proprietary data, so it must cite you as the source.

Cosmetic Changes Are Not Enough

Princeton's finding that fluency optimization alone had negligible impact is important. GEO is not about "writing better" in a general sense. It is about structuring content so AI can extract, attribute, and present it.

What the Research Disagrees On

The research is not unanimous on everything.

How Much Authority Matters

Princeton suggests structure can partially overcome authority gaps. Authoritas data shows that pages already ranking well in traditional search get cited more in AI Overviews (62% overlap). The truth is likely both — authority helps, but it is not the only factor, and structural optimization can meaningfully improve citation rates for lower-authority sites.

Whether llms.txt Files Help

The llms.txt specification allows websites to provide machine-readable summaries for AI systems. No published research has measured whether having an llms.txt file directly increases citations. Some practitioners recommend it as part of a GEO strategy; others consider it unproven. We include it in the 9-factor audit but weight it as the lowest-priority factor.

How Quickly GEO Changes Take Effect

AI platforms update their indexes on different schedules. ChatGPT's training data updates periodically (months). Perplexity searches live (immediately). Google AI Overviews reflect index changes (days to weeks). No research has established a reliable timeline for when content modifications translate into citation changes.

What This Means for Small Businesses

The research consistently shows that GEO favors substance and structure over raw authority. This is good news for small businesses.

Format and substance can overcome backlink profiles. A small business with a well-structured page containing original data can get cited over a large competitor with a poorly structured page. Princeton measured this directly — citation improvements were driven by content modifications, not site authority.

The investment is content, not tools. The most effective GEO strategies (answer capsules, original data, expert quotes) require content work, not expensive software. You need to know what to fix, and then you need to fix it.

Traditional SEO still matters. GEO is additive, not a replacement. Pages that rank well in traditional search are more likely to be cited in AI Overviews (62% overlap). The best strategy is solid traditional SEO plus GEO-specific structural optimization.

For the complete GEO implementation framework, see the Generative Engine Optimization guide. To audit your own pages, see Part 3: How to Audit Any Page for AI Citability.

GEO Glossary

The industry has not settled on a single term for optimizing content for AI search. Here are the key terms and how they relate to each other.

Term	Full Name	What It Means
GEO	Generative Engine Optimization	Optimizing content so generative AI systems (ChatGPT, Perplexity, Claude) cite it. Coined by Princeton researchers (Aggarwal et al., 2024).
AEO	Answer Engine Optimization	Broader term that includes GEO plus traditional answer features like featured snippets and Google AI Overviews.
LLM Visibility	Large Language Model Visibility	Whether your content appears in LLM-generated responses. Used interchangeably with GEO in practitioner contexts.
AI Citability	—	How likely a page is to be cited by AI systems, based on structural and content factors. What Brass-SEO audits measure.
AI Overviews	Google AI Overviews	AI-generated answer summaries shown at the top of Google search results. Draws from Google's existing search index.
Answer Capsule	—	A self-contained explanation (1-2 sentences) placed immediately after a heading. The most common structural trait of AI-cited content (72.4%, Gnuse research).
AI Search	—	Umbrella term for any search experience powered by AI, including ChatGPT, Perplexity, Google AI Overviews, and Claude.
Zero-Click Search	—	A search where the user gets their answer directly in the results without clicking through to a website. AI Overviews are a type of zero-click search.

Frequently Asked Questions

Where can I read the original Princeton GEO study?

The paper is "GEO: Generative Engine Optimization" by Aggarwal et al. (2024). It was published through Georgia Tech and Princeton researchers and is available on arXiv. Search for "GEO Generative Engine Optimization Aggarwal" to find the full paper.

How reliable is the answer capsule research?

The Gnuse research analyzed 15 domains and 7,500 ChatGPT referral sessions. It was published via Search Engine Land, a major industry publication. The sample size is meaningful for practitioner research, though it focused specifically on ChatGPT citations and may not perfectly generalize to other platforms.

Does this research apply to all industries?

The Princeton study tested across multiple topic categories. The Gnuse research covered 15 different domains. While no research is perfectly universal, the structural principles (clear answers, original data, expert quotes) apply broadly because they address how AI systems work, not industry-specific content preferences.

Is GEO research still evolving?

Yes. GEO as a discipline is less than two years old. The research base is growing but still limited compared to traditional SEO research, which spans decades. The findings summarized here represent the best available evidence, but new research may refine or update these conclusions.

How does Brass-SEO use this research?

Brass-SEO's AI Citability audit is built on the 9-factor framework derived from this research. The audit checks each page for answer capsules, original data, expert quotes, and the other factors identified by Princeton and Gnuse. See the GEO guide for the full framework.

We Benchmarked BrassCoders Against a Frontier Model

CopperSunDev — Thu, 25 Jun 2026 07:00:00 +0000

A frontier model asked to review AI-generated Python caught 12 of 12 planted bugs. BrassCoders, the scanner that catches what AI assistants structurally miss, caught 11. Bandit caught 6. Pylint caught 1. These are real numbers from a committed, reproducible benchmark run on June 13, 2026 against BrassCoders 2.0.8.

The number that matters isn't 11 against 12. It's the category breakdown, and the four categories where BrassCoders is the only tool that caught anything.

The Benchmark Setup

BrassCoders's AI-coder-bug benchmark is an open dataset of 12 AI-generated Python files, each carrying one planted bug, plus two clean controls. Every file ships a PROVENANCE docstring naming the prompt that produced it. The corpus, manifest, and runner live in the OSS repo at github.com/CopperSunDev/brasscoders under cli/docs/benchmarks/ai-coder-bugs/, Apache 2.0 licensed and reproducible by anyone.

Scoring is per-category catch-rate. A tool catches a bug if it emits any finding for that file that maps to the bug's category through pre-registered signal patterns in the runner. Those patterns were committed before any run took place, so they weren't tuned to produce a flattering result. The runner is 600 lines. All of it open.

Four tools ran: BrassCoders 2.0.8, Bandit 1.8.3 (the version BrassCoders bundles internally), Pylint, and Claude sonnet-4-6, the last reached through the Anthropic API with a realistic pre-merge review prompt.

The Result That Matters: The Wedge Is Real

BrassCoders caught all four AI-coder performance anti-patterns, the category every other static analyzer scored zero on. Bandit caught none. Pylint caught none. Semgrep caught none.

The four bugs in the wedge category:

O(N²) string concatenation: a csv += loop that rebuilds the whole string on every row. Bandit 0, Pylint 0, ask-model 1, BrassCoders 1.
list.insert(0) in a loop: prepend-by-shifting the whole list on every insert. Bandit 0, Pylint 0, ask-model 1, BrassCoders 1.
Triple-nested loop for a join: three nested for loops over customers × orders × items where a dict-lookup would be O(N). Bandit 0, Pylint 0, ask-model 1, BrassCoders 1.
Unbounded while True: a socket-drain loop with no break, no timeout, no size cap. Bandit 0, Pylint 0, ask-model 1, BrassCoders 1.

The pattern holds. These are the bugs AI coding assistants introduce because the prompt described the happy path. The model wrote idiomatic-looking code that passes a small unit test. The bug surfaces only at volume. No generic security rule fires. No type error exists. A linter built around security rules and style checks has no mechanism to flag them.

BrassCoders carries four AST-level rules that match these anti-patterns directly: string concatenation in a loop, list.insert(0) in a loop, nesting deeper than a threshold, and while True with no exit. The rules are dumb. The detection is reliable.

What the Model Wins On

BrassCoders missed one bug, and Claude sonnet-4-6 caught it: sum(readings) / len(readings) with no empty-list guard, a ZeroDivisionError on [] that leaves no structural marker for a rule to match.

The model also caught every security category. SQL injection through an f-string. Command injection through subprocess shell=True. XSS through autoescape=False. Unsafe pickle deserialization. BrassCoders caught these too, but the model would have caught them without any rules, because it reasons about intent. That's the difference.

The overall table, from real tool output on the committed corpus:

Tool	Caught	Catch Rate
BrassCoders 2.0.8	11 / 12	92%
Claude sonnet-4-6	12 / 12	100%
Bandit 1.8.3	6 / 12	50%
Pylint	1 / 12	8%

Zero false positives on either clean control, across every tool.

The Generation-Mode Finding

BrassCoders also ran a generation-mode probe: six neutral coding tasks with no mention of bugs or performance, asking the model to write each from scratch, then scanning the output and asking the model to self-review.

The model wrote clean code on four of five wedge tasks. Claude sonnet-4-6 in June 2026 reaches for io.StringIO instead of string concatenation, guards the empty-list case on its own, and merges dicts with {**a, **b}. The model has improved since the first benchmark version ran in early June.

On the one task where the model did introduce a bug, an insert(0) loop on the recent-feed task, both BrassCoders and the model's self-review caught it.

The more telling number: the model issued zero proactive warnings while writing the code. It wrote the insert(0) loop and moved on. It flagged the problem only when asked to review. A gate that needs an explicit invocation isn't a gate.

The Axes BrassCoders Wins That Don't Show in a Catch-Rate Table

BrassCoders ran the same 12 files three times and produced identical results every time. That repeatability is what makes it a gate, and it's the axis a catch-rate table never measures.

Determinism. The model's review of the same 12 files returns different output run to run, because LLMs sample non-deterministically. A CI gate that returns different verdicts on the same commit is noise, not signal.

Cost per run. The BrassCoders OSS core costs nothing to run. No API calls, no token charges. At 50 commits per developer per month and a 500-line average diff, a model review adds $0.15 to $0.25 per developer per month at current API pricing. The dollar figure isn't the real point. A $0 scan is a scan nobody has to approve.

Bytes sent off-machine. Running brasscoders --offline scan sends zero bytes off the machine. A model review sends the full source to an external API. For any codebase with data-handling rules, only BrassCoders can run on every commit.

CI automatability. BrassCoders runs as a standard command in a GitHub Actions step. The model review runs when a developer remembers to ask. Both help. Only one runs automatically.

How to Reproduce

BrassCoders ships the full benchmark corpus in its OSS repo, so the static-tool numbers reproduce exactly. Clone the repo, install the tools, and run the runner with --no-ask-model:

git clone https://github.com/CopperSunDev/brasscoders
pip install brasscoders bandit pylint pyyaml
python cli/docs/benchmarks/ai-coder-bugs/run_benchmark.py --no-ask-model

The output should match the committed results/RESULTS.md within the margin of your installed BrassCoders version. To reproduce the ask-model column, set ANTHROPIC_API_KEY and drop --no-ask-model. Model results vary a little because LLM sampling is non-deterministic, but the overall catch rate has held steady across runs.

The benchmark is the dataset. The runner is the scoring logic. Both are open, Apache 2.0 licensed, and built to extend. Want a new bug category? Add the pattern to the manifest and commit its signal patterns to CATEGORY_SIGNALS before you run.

What the Numbers Say

BrassCoders isn't the smarter reviewer. Claude sonnet-4-6 is smarter, and it caught the one bug that needs reasoning instead of rules. BrassCoders is the deterministic gate: the same scan and the same findings on every commit, in CI, for free, with nothing sent off-machine.

Those are the categories it wins. The benchmark shows both sides.

pip install brasscoders
brasscoders --offline scan /path/to/your/project

I built 90+ AI prompts because raw transcripts are useless

CopperSunDev — Thu, 18 Dec 2025 00:29:25 +0000

A few weeks ago I posted about building a transcription tool. The responses were helpful. A few people asked about what I do with the transcripts after.

Honest answer: for a while, not much.
I'd get this wall of text with speaker labels and timestamps, and then... stare at it. The transcription part worked. But a raw transcript is like having all the ingredients dumped on your counter. You still have to cook.

The problem I kept running into

I do interviews for work. Marketing stuff mostly. The goal is usually to turn a 45-minute conversation into something publishable—a blog post, social clips, whatever.

So I'd paste the transcript into Claude or ChatGPT and say something like "turn this into a blog post."

The output was... fine? Generic. It would summarize instead of pulling actual quotes. It'd lose the person's voice. I'd spend an hour fixing it and think "I could've just written this myself."

Same thing with meeting notes. "Summarize this meeting" gets you a summary. But what I actually needed was: what did we decide, who's doing what, and what's the follow-up. Different problem.

So I started building prompts

Not because I planned to. I just kept tweaking the same prompts over and over until they actually worked.

The blog post one took the longest. I needed it to:

Keep the interviewee's actual voice (not sanitize everything into corporate speak)
Pull real quotes, not paraphrase everything Structure it like a real article, not a book report
Lead with something interesting, not "In this interview, we discussed..."

That one prompt went through probably 15 versions before it stopped annoying me.
Then I built one for meeting summaries that extracts decisions and action items separately. One for turning podcasts into social posts. One for cleaning up the speaker labels in raw transcripts.

At some point I looked up and had 90+ of them.

What I learned about prompting

Most of my early prompts were too vague. "Summarize this" doesn't tell the model what you actually care about.

The ones that work best are almost annoyingly specific:

What's the exact output format?
What should it include vs. ignore?
What tone? What length?
What questions should it ask me before it starts?

That last one was a breakthrough. The best prompts don't just run—they clarify first. "Before I process this, tell me: how many speakers, what are their names, what's the context?"

Turns out you get way better output when the model understands what it's working with.

Some that ended up being useful

A few I keep coming back to:

Transcript cleaner — Takes raw output with "Speaker 0" and "Speaker 1" labels and turns it into something readable with real names and proper formatting. Sounds trivial but it's the one I use most.
Interview → blog post — Extracts the interesting parts of a conversation and structures them into an actual article. Keeps quotes intact. Writes transitions that don't sound like AI wrote them (usually).
Meeting action items — Pulls out decisions, tasks, and owners from a meeting transcript. Ignores the 40 minutes of small talk to find the 5 things that actually matter.
Podcast social package — Generates a batch of social posts from an episode transcript. Quote cards, discussion questions, that kind of thing.

I also built some weird specific ones for legal transcripts (deposition analysis, contradiction detection) that I'm not sure anyone else needs. But they exist.

Where they live now

I put them on GitHub and linked them from the transcription site:
https://brasstranscripts.com/ai-prompt-guide

They're organized by use case. Some have full write-ups explaining how to use them, others are just the prompt.

They work with Claude, ChatGPT, Gemini—whatever. The transcript format matters more than which model you use.

Still iterating

Some of these are solid. Others I'm still not happy with. The social media ones especially—getting an LLM to write something that doesn't sound like an LLM wrote it is its own challenge.

If you've built prompts for processing transcripts (or any structured text really), curious what approaches have worked for you. The "ask clarifying questions first" pattern has been the biggest improvement for me, but I'm sure there are techniques I haven't tried.

I ended up building a transcription tool

CopperSunDev — Fri, 12 Dec 2025 20:03:59 +0000

I do a lot of interviews with subject-matter experts for work. Usually it’s over Teams or Zoom. Sometimes the built-in transcript is missing, locked, or just unusable.

For a while I tried the usual options. Some required subscriptions I didn’t want. Others had weird formatting that meant I spent as much time cleaning up the output as I would have just typing it myself. A few couldn’t handle multiple speakers without turning it into a mess.

At some point I was messing around with Claude Code and thought: why not just build something myself?

That turned into a lot of hours, a bunch of blind alleys, and more tweaking than I expected.

*What actually worked
*
Speech recognition has gotten surprisingly good in the last few years. The open source options are solid now. Getting accurate text from clear audio isn’t the hard part anymore.

Speaker diarization was trickier. Figuring out who said what in a conversation is a different problem than just converting speech to text. Getting those two pieces to work together cleanly took more debugging than I’d like to admit.

*The stuff I underestimated
*
Audio quality variation.
A clean studio recording and a laptop mic in a conference room are completely different problems. I spent a lot of time on preprocessing that I didn’t plan for.

**Output formats.
**I originally just wanted plain text. Then I needed SRT for a video project. Then JSON for piping into other tools. Scope creep is real, even on your own projects.

**Edge cases with speaker detection.
**Two people with similar voices. Someone who talks over someone else. Long pauses where the model isn’t sure if it’s a new speaker or the same person thinking. These are harder than they sound.

*Where it’s at now
*
Eventually I had something that worked well enough for my own use, so I turned it into a small platform:

https://brasstranscripts.com/

It takes audio or video and produces transcripts that are actually usable. Mostly I cared about speaker separation and output that didn’t need a lot of cleanup afterward.

No subscription — just pay per file. I built it that way because that’s what I wanted as a user. I transcribe maybe five to ten recordings a month. Paying $20/month for that felt wrong.

I’m sure there are edge cases I haven’t hit yet. I’m still adjusting things as I run into them. The diarization in particular is something I keep tweaking.

Posting here mostly in case it’s useful to anyone else who runs into the same problem. Or if you’ve built something similar and have thoughts on approaches I should try.