Overview of GEO Corpus

The End of the Retrieval Contract

Search has stopped delivering users to publishers and started extracting fragments from publishers to deliver answers. The retrieval contract that financed two decades of web content has ended; every honest GEO conversation begins by admitting that.

The contract that just expired

For roughly twenty years the web operated under an implicit deal. Publishers wrote freely indexable content. Google crawled it, ranked it, and surfaced it as ten blue links. Users clicked through. Publishers monetized the click — with advertising, subscription tripwires, lead capture, or simply the brand impression of being the place a reader landed. The system was lossy and dominated by a single intermediary, but the contract was legible: you index my content; I receive your traffic; we both make money on the user’s attention.

That contract has ended. Not deteriorated, not strained — ended. The retrieval system no longer hands users to publishers; it ingests publishers and hands answers to users. The visible artifact of a search has changed shape: from a ranked list of destinations to a synthesized paragraph with optional, half-trusted citations underneath. The user is satisfied earlier, clicks less often, and increasingly never knows which publishers contributed to the answer they accepted.

The data on the shift is now too consistent to wave away. More than half of Google sessions resolve without an external click. Google’s AI Mode traffic clicks external links a fraction as often as classic Google did. ChatGPT and Perplexity are no longer rounding errors in referral logs — they are appearing in conversion paths, brand-discovery interviews, and inbound calls. Publishers from local news up to enterprise SaaS are watching their organic traffic plateau or drop while their content continues to be cited inside answer panels they cannot measure and cannot bill.

What replaces the contract is not a contract

The most important thing to internalize is that there is no new contract waiting in the wings. AI search systems are not negotiating with publishers in the way Google did, even tacitly. They ingest, they rerank, they synthesize, they cite when it suits the generation, and they do not return value to the publisher in proportion to the value extracted. This is not a moral complaint; it is the operating reality you have to optimize within.

Two responses dominate the publisher conversation right now, and both are wrong. The first is litigation and licensing — the bet that publishers can sue, opt out, or strike paid feed deals back into prominence. A handful of brands with genuine leverage (Reuters, the AP, the FT) can play this game; the other ninety-nine percent of publishers cannot. The second is withdrawal — block the AI bots in robots.txt and trust traditional SEO to keep paying the bills. This is the path most CMOs take when they discover their content is being ingested without traceable return, and it is the worst available choice. A publisher who blocks AI crawlers is not protecting their value; they are removing themselves from the surfaces where users are increasingly forming opinions about brands, products, neighborhoods, and answers to professional questions.

The right response is to recognize that the unit of value has changed. Under the old contract, the unit was the click. Under the new regime, the unit is the citation — the inclusion of your content as a source the model trusts, attributes to, and surfaces in its answer. Citations do not arrive as traffic. They arrive as influence: brand presence inside the answer-mediated conversation that increasingly precedes the human decision. Optimizing for citation is what we mean by GEO. Optimizing for clicks is what SEO did. They are related disciplines; they are not the same discipline.

The three failure modes the retrieval contract used to mask

For most of the web’s history, three categories of failure simply did not register because the click contract papered over them.

Retrieval failure — the AI system never fetches your content. Your robots.txt blocks the relevant crawlers. Your origin returns 403 to the user agents that matter. Your JavaScript-rendered page produces nothing useful when fetched. Your sitemap omits the URLs that contain the citable material. Under classic SEO this was rare because the entire SEO industry was organized around making Googlebot happy, and most CMSes had Googlebot accommodation baked in. Under AI search this is the modal failure: dozens of new bot identities, no equivalent of Search Console to surface the problem, and an industry of CDN defaults that block AI bots out of risk-aversion no one has audited.

Parsing failure — the AI system fetches your content but cannot extract anything useful. Your page is a hero image, a video embed, and three lines of marketing copy. The substance is in a PDF, behind a form, inside a Webflow interactive that renders as visual presentation but contains no underlying text. Under SEO this was rewarded with a fine ranking on brand queries; under AI search it produces zero citations because there is nothing to lift.

Citation failure — the AI system fetches and parses your content but does not cite you. The model finds the same facts on a Wikipedia entry, a competitor’s blog, a Reddit thread, and a government data set. It cites the source it trusts most or the source whose passage is most extractable. Your content was in the candidate pool but lost the retrieval tournament. Under SEO this looked like “page two of Google” — survivable; under AI search this looks like invisibility.

Each failure mode requires a different intervention. We will spend the rest of this manual laying out which interventions matter for which failure modes, in what order, on what budget, with what measurement.

What this manual will and will not do

This manual is written for the practitioner who already knows their way around an SEO stack and is now responsible for the next discipline. It assumes you understand robots.txt, structured data, sitemaps, server logs, and the rough shape of a ranking algorithm. It does not assume you have built a translation layer, instrumented bot traffic for cross-engine attribution, or run a 4-model probe against your own brand queries. If you have, much of what follows will give names to things you already do; if you have not, it will give you the order of operations.

We will not pretend this is settled science. AI search architectures shift quarterly. The bot names you saw in your logs six months ago are not the bot names you see today; the engines that mattered last year are merging, deprecating, or surging this year. What we describe as canonical here is canonical as of the date stamped at the top of this page. Where we make a load-bearing claim, we cite the measurement, the engine, and the date. Where we make a thesis without measurement, we frame it as a thesis. Hedging will not help you ship.

From Sessions to Standing Conversations

The relevant unit of analysis is no longer the query, the session, or even the user. It is the standing conversation a user maintains with an AI system over weeks and months — one in which your brand either persists across exchanges or disappears between them.

The session is the wrong unit

Classic search analytics is built on a clean conceptual model: a user issues a query, a system returns ranked results, the user clicks or refines, the session ends. The unit of measurement is the query (or, for richer analyses, the session of related queries within a short time window). Tools, dashboards, and KPIs are organized around it. Click-through rate, dwell time, bounce, return visits — all of these depend on the discrete-session assumption.

That assumption no longer holds. A user with ChatGPT Plus, Claude, Perplexity Pro, or Gemini Advanced does not run discrete sessions in any way the analytics layer understands. They run an ongoing conversation. They asked the assistant about a vendor in March, came back in April with a refinement, and in May asked it which of the vendors it had recommended back in March was “the one with the better security posture.” The assistant either remembers, retrieves prior context from memory, or reconstructs the relevant material on the fly. If your brand was cited in March but not retrievable in May, you have disappeared from a conversation you never knew you were in.

This is not a hypothetical. Every major AI engine now ships persistent memory in some form: ChatGPT’s memory feature, Claude’s Projects, Gemini’s memory, and Perplexity’s Spaces. Each one stores user-relevant context across sessions and reuses it in retrieval and synthesis. The implication for GEO is straightforward and severe: your brand needs to be present and consistent across multiple exposures separated by weeks, often without any new content shipping. Volatility — appearing in one answer and not the next — is itself a competitive disadvantage that prior search regimes did not impose.

Three behaviors that did not exist five years ago

Refinement instead of reformulation. Classic search rewarded users who restated their query with better keywords. AI search rewards users who refine their previous answer (“narrow that to options under $200”) without restating context. The retrieval system has to reach back across the conversation, understand which of the prior turns establishes the latent constraints, and surface content that fits the cumulative state. Your content needs to be retrievable not for the original query but for the implicit slot the conversation has built up.

Comparison-as-default. Conversational systems handle comparisons natively. Users who would once have visited three vendor sites and built their own mental model now ask the assistant directly to compare. The retrieval system pulls fragments from each vendor and from independent sources; the synthesis lays them side by side. If your content does not produce extractable side-by-side fragments — clear specifications, named features, quantified outcomes — you lose this comparison to a competitor who does. The comparison is happening whether or not your sales team is in the room.

Delegated research. Users now ask AI to do research that previously would have been a multi-tab session. “Find me three vendors in this category, summarize their pricing, and tell me which has the best reviews from finance customers.” The system runs a multi-source retrieval, picks the citations it trusts, and presents the synthesis. Your brand either survives that triage or it does not. The user’s mental model of the market is being constructed from the citations the system selected, not from your homepage hero.

Persistence is the new volatility

The most measurable consequence of the conversational shift is that the same query, asked at two points in time by the same user, can return materially different answers. We see this routinely in our own measurement work: a brand cited in three out of four engines on Monday is cited in one out of four on Wednesday, with no observable content change on either side. This is not noise. It reflects retrieval-system updates, index churn, model rotations, prompt-template revisions on the engine side, and seasonal fan-out behavior. Treating volatility as noise is the wrong frame; treating volatility as a measurement target is the right one.

The practical implication is that any serious GEO program must measure citation persistence, not citation presence. Persistence is the percentage of canonical queries on which your brand is cited consistently across, say, four engines and four time slices over a month. A brand that scores 90% persistence in a quarter has stable citation; a brand that scores 30% persistence has citation that is theatrical — visible when you check, absent when the user does. We will describe the measurement infrastructure for this in Chapters 12 and 13.

What this changes about content strategy

If the unit of analysis is the standing conversation and the metric is persistence, then content strategy has to optimize for two things at once: retrievability at any given moment (the content is fetchable, parseable, citable on any of the four leading engines today) and durability across moments (the content survives reranking churn because it carries signals — structured data, authoritative citations, distinctive data — that systems consistently weight high).

The first is a technical problem solvable with infrastructure: clean HTML, structured data, llms.txt, accessible bot view, fast TTFB. The second is a content problem solvable only with substance: original data, named entities with stable identifiers, claims that corroborate across independent sources, freshness signals that are real rather than cosmetic. The first you can ship in a month. The second compounds over years and is the thing your competitors with deeper content equity already have.

Intent After the Keyword

Intent has stopped being a property of the query and become a property of the conversation, the user’s history, and the system’s decision about what to do next. The content that wins is not the content that matches the keyword; it is the content that satisfies the slot the system has decided to fill.

Broder is necessary; Broder is not sufficient

The 2002 Broder taxonomy — informational, navigational, transactional — remains a useful first cut. A user who types “chase bank” is probably navigational; one who types “how to refinance an FHA loan” is probably informational; one who types “buy iPhone 16 Pro” is probably transactional. The taxonomy is still load-bearing in SEO content briefs and content templates, and that is fine.

It is also wildly insufficient for AI search. The reason is that AI systems do not classify intent once and route the query. They orchestrate intent: they decide, on the fly, whether the user wants a comparison, a tutorial, an opinion, a recommendation, a forecast, a critique, a synthesis of disagreement, or some compound of several. The result is that the same surface query can land in radically different content surfaces depending on the conversation state, the user’s history, and the system’s own heuristics about what kind of answer to produce.

The intent surfaces an AI system actually fills

Practically, we observe AI engines operating across at least seven intent surfaces that classic SEO does not name well:

• Comparative. The system has decided to produce a side-by-side, even if the user did not ask for one. Wins go to content with clean attribute-value pairs (specifications, prices, named features, quantified outcomes) that the system can lift into rows.
• Exploratory. The user is in an early stage of understanding; the system produces a broad overview. Wins go to content that defines named concepts clearly and links them to canonical entities.
• Clarifying. The system asks the user a follow-up before answering. Wins go to content that anticipates the disambiguation axes (location, budget, use case, audience).
• Orchestrated. The system runs a multi-step retrieval where each step is invisible to the user. Wins go to content that satisfies a single hidden sub-query cleanly.
• Ambient. The user did not ask; the system surfaces something it predicted they wanted (Gemini in Workspace, Copilot in Microsoft 365). Wins go to content that ranks well as a recommendation in a context the user did not initiate.
• Procedural. The user wants the system to do something on their behalf — book, buy, summarize a document, draft an email. Wins go to content that exposes structured affordances the model can act on.
• Diagnostic. The user describes a symptom; the system has to identify the underlying problem and recommend a path. Wins go to content that names symptoms and binds them to canonical causes.

You can map these to traditional intent if you want, but the mapping is not informative. The point is that the system is no longer dispatching the query to a ranked list of pages; it is dispatching parts of the synthesis to fragments inside pages. The page that wins is the page whose fragments fit the part of the synthesis the system decided to fill.

UX versus AX — agent experience as a real discipline

The most useful reframing we have encountered is to treat machine retrieval as its own design discipline rather than an extension of UX. Where UX optimizes for the human reading the page (visual hierarchy, scan patterns, persuasive narrative arcs), AX (agent experience) optimizes for the retrieval agent reading the page (entity definitions, structural metadata, action parameters, clean passage boundaries). The two are not mutually exclusive and they are not fully aligned. A page that is gorgeous for humans can be opaque for agents; a page that is verbose for agents can be unreadable for humans.

The conventional response to this tension is to design for humans and hope the agents adapt. The AnswerShare response is to design two surfaces: one for humans, one for agents, both serving the same content but optimized for the radically different parsers consuming them. This is what we mean by the Translation Layer™, and Chapter 29 lays out the architecture in detail. For now: treat AX as a first-class design discipline, not a fallback for when the human design fails.

Query rewriting — the layer you cannot inspect but must optimize for

Every major AI engine rewrites the user’s query before retrieval. Perplexity is the most aggressive and the most legible about it: you can occasionally observe the rewritten queries in its “sources” panel, and the rewrites are frequently dramatic transformations of the user’s typed input. Google’s AI Mode rewrites silently. ChatGPT’s search tier rewrites silently. Claude’s search tier rewrites silently. The user types one thing; the system retrieves against something else.

This has two implications. First, classic keyword research — the discipline of identifying the terms users type and optimizing for those terms — is dramatically less valuable than it was, because the terms users type are not the terms the system retrieves against. Second, the discipline that replaces it is closer to what iPullRank correctly calls latent intent mining: identifying the full distribution of sub-queries the rewrite layer is likely to generate from a seed user intent, and ensuring you have content surfaces that satisfy as many of them as possible. We will return to this in Chapter 8 on fan-out.

Where AnswerShare lands on intent

Our pragmatic stance: do not try to optimize for intent as a property of the query. Optimize for intent as a property of the content. Every content surface you ship should make explicit what slot it fills — comparison, exploration, clarification, procedure, diagnosis — through its structure (headings, schema type, named entities, attribute tables). The engine then chooses your content for whichever conversational slot the system has decided to fill. You are not predicting the user’s intent; you are advertising the slots your content can satisfy.

The Fragmented Gatekeepers

There is no single gatekeeper of AI search. There are at least four major retrieval surfaces with materially different architectures, plus a long tail of vertical engines whose share is small individually and substantial in aggregate. A GEO program that optimizes for one engine and ignores the others is solving the wrong problem.

The map you have to hold in your head

Picture the gatekeeper landscape as a grid with two axes. The horizontal axis is distribution scale — how many users actually receive answers from this engine in a given week. The vertical axis is retrieval openness — how willing the engine is to retrieve from the open web in real time, versus relying on a pretrained or licensed corpus.

The top-right quadrant — large distribution, open retrieval — is where the action is. Google’s AI Mode and AI Overviews sit there with by far the largest user base. Perplexity sits there with a smaller user base but the most legible retrieval behavior. ChatGPT’s search tier sits there with growing distribution and an opportunistic, on-demand fetch model. The bottom-right quadrant — smaller distribution, open retrieval — contains the vertical engines: You.com, Phind for developers, Consensus for academic research, Andi, Brave Search’s AI Answer, and a few enterprise-licensed retrieval tools sold to private corpora.

The top-left quadrant — large distribution, closed retrieval — is Microsoft Copilot in its M365 mode (drawing primarily from tenant data) and ChatGPT’s non-search default behavior (relying on pretraining). These surfaces matter for citation only insofar as your brand made it into the training corpus during the relevant cutoff; once it did, there is little incremental optimization available beyond keeping your content publicly indexable so the next training cycle picks it up.

The bottom-left quadrant — small distribution, closed retrieval — is mostly noise: experimental engines, niche assistants, internal corporate deployments. Not zero; not your priority.

The four engines that matter today

Google — AI Overviews and AI Mode. Largest distribution, two billion monthly users. Retrieval is built on Google’s existing index plus query fan-out into more specialized sub-systems. The defining property of optimizing here is that you are still substantially optimizing the same surfaces classic Google rewards — clean HTML, structured data, authority signals, fresh content, internal linking, sitemap discipline. The differences are at the margin: AI Overviews favor pages with extractable passages near the top of body content, AI Mode appears more sensitive to entity-level identifiers (Knowledge Graph entries, Wikidata IDs, schema.org type breadth) than classic Google.

ChatGPT search. Mid distribution, growing. The defining architectural property is that ChatGPT does not maintain a persistent index of the open web. When the user query triggers a search, the system fetches URLs on demand and reasons over what it retrieves. This rewards instant accessibility — sub-second TTFB, no aggressive bot-blocking, content that renders without JavaScript — over accumulated SEO equity. A site that ranks ninth on Google can win the ChatGPT citation if its passage is cleanly extractable and it returned to the fetcher in under two seconds.

Perplexity. Smaller distribution, fastest-growing share-of-mind among technical users and researchers. The defining property is legibility: Perplexity exposes which sources it pulled, in what order, with which retrieved passages. This makes it the cheapest engine to instrument and the right place to run your first probes. The tactics that move Perplexity citations — structured data, passage clarity, citation-worthy original data — are the tactics that generalize most cleanly to less inspectable engines.

Claude (Anthropic) with search. Smallest of the four in user distribution but high in influence-per-user; technical buyers, researchers, lawyers, policy operators. Claude’s retrieval (when enabled) is conservative, tends to favor primary sources, and frequently cites institutional domains (.edu, .gov, established publishers) over commercial blogs. The implication: brand-authority signals matter disproportionately here. A B2B SaaS competing against an academic paper on a niche topic will lose the Claude citation; the response is to publish original research that is itself citable.

The long tail and why you do not ignore it

The four engines above account for most of the volume but underweight the surfaces where vertical credibility is forming. A few categories where vertical engines drive real outcomes:

• Developer-tool selection increasingly runs through Phind, Cursor’s in-product reasoning, and direct documentation queries inside Claude. Your developer docs need to be retrievable here even if the volume looks small.
• Academic and clinical decision-making runs through Consensus, Elicit, and increasingly direct PubMed integrations inside Claude and Perplexity Pro. Original research with proper DOI and CrossRef registration wins.
• Local discovery increasingly runs through the AI assistants embedded in Apple Maps, Google Maps, and Yelp, which are themselves doing AI-mediated retrieval from a curated corpus.
• Enterprise procurement increasingly runs through internal AI assistants deployed against proprietary feeds (G2, Gartner, custom enrichment). Your presence in the underlying syndication is what moves these.

The right mental model is not “four engines plus noise.” It is “four general-purpose engines plus a dozen vertical retrievals that matter for your specific buyer.” A GEO program built only against the four general engines will underperform for any brand whose buyers spend their decision time in vertical surfaces.

What this means for your stack

You will end up with multiple optimization tactics that look superficially redundant but serve different gatekeepers. A sitemap discipline that helps Google does not help ChatGPT directly (ChatGPT does not consult sitemaps); but if Google indexes you better, your URLs are more likely to surface as candidates the ChatGPT fetcher pulls. Structured data that helps Perplexity also helps Claude on retrieval but does little for ChatGPT’s ad-hoc fetch. Bot allowlists that make GPTBot happy do nothing for the Google AI Overview — that depends on Googlebot.

The discipline is to maintain a matrix in your head (or, better, in a spreadsheet) of tactic × engine × expected impact. We will give the version of that matrix we use with clients in Chapter 10. The principle: every tactic you ship should map to at least one engine’s retrieval mechanism and should not be defended on “best practice” grounds alone.

Why Google Wins the Default — and Why That Is Not Enough

Google retains structural advantages in AI search that no competitor can close on the relevant horizon. That is not the same as saying Google has won. Where users go when they care about quality, depth, or specificity, they are leaving Google — and they are not coming back.

The advantages that actually compound

Three of Google’s advantages compound rather than depreciate. First, data feedback loops: Search, YouTube, Maps, Android, Gmail, Chrome, and Workspace generate continuous user-behavior signal that no competitor can replicate. The cited DOJ estimate — that it would take Bing seventeen years to acquire thirteen months of Google query data — understates the moat because it counts only query data, not the dozen other behavioral signal streams Google owns.

Second, vertical silicon: TPU ownership compresses Google’s cost per inference and decouples its trajectory from NVIDIA’s supply schedule. As reasoning-heavy AI features multiply, the marginal cost of serving them inside Search becomes the deciding factor in feature velocity. Google can ship features its competitors can model on paper but cannot afford to serve at billion-user scale.

Third, distribution by default: AI Overviews appear in Google Search whether the user asked for them or not, in front of two billion monthly users. No competing AI search product can match that surface area. Perplexity Pro has a few million paying users; Claude has a smaller but more influential base; ChatGPT has hundreds of millions but no parallel to AI Overviews’ reach into casual queries.

Treat all three as durable. Any GEO strategy that bets on Google being displaced within the next three to five years is making a bet against the evidence.

What Google is losing despite winning the default

The harder claim — the one Mike King’s manual treats more dismissively than the data warrants — is that Google’s advantage is in the default surface and is bleeding share in the surfaces where users go when the default is unsatisfying. We see this everywhere now, including in our own internal traffic:

• Technical buyers are moving substantive product research to ChatGPT and Perplexity. The Google AI Overview is “good enough” for first-impression queries but loses to ChatGPT once the user wants depth.
• Researchers and analysts are moving to Perplexity Pro for the citation surface and to Claude for synthesis tasks. Google AI Mode citations are present but the user has to click through to verify; Perplexity puts the source-list up front.
• Lawyers, doctors, and other professionals with stakes are moving to Claude (with search) because they trust the conservatism and the source preference.
• Developers are moving to Cursor, Phind, and Claude inside the IDE. Google AI Mode never had this audience.

The phrase that captures it: Google wins the casual query, and the casual query is enormous in volume. Competitors win the stakes query, and the stakes query is enormous in value. A GEO program optimizing only for AI Overviews wins the volume game on Google’s terms; one that also optimizes for Perplexity, Claude, and ChatGPT wins the influence layer where high-consideration purchase decisions, professional recommendations, and brand-credibility formation increasingly happen.

The strategic implication for content

Google’s retrieval rewards the breadth of signals it has historically rewarded: domain authority, structured content, internal linking density, sitemap discipline, content freshness, schema.org coverage. The optimization vector is largely continuous with classic SEO, with an added emphasis on extractable passages and Knowledge Graph alignment. If you already invested in good SEO, you have a working baseline for Google’s AI surface.

The other engines reward different things. Perplexity rewards passage clarity and citation-worthy distinctive data. ChatGPT rewards instant retrievability and clean HTML over accumulated authority. Claude rewards primary sources and institutional credibility. None of these are well-served by “rank higher in Google.” They require their own tactical interventions, which is exactly why we frame GEO as a multi-engine discipline rather than as a Google-AI-Overview optimization.

What the Google triumphalism gets wrong

There is a stripe of GEO commentary that treats Google’s AI dominance as so total that competing engines are not worth optimizing for. This stance is a mistake on three counts.

First, it confuses volume with influence. ChatGPT users skew higher-income, higher-education, and higher-purchase-intent than the median search user. Citation in ChatGPT is worth more per occurrence than citation in AI Overviews for any brand whose buyer profile resembles the ChatGPT user base.

Second, it confuses present share with trajectory. The growth of AI-engine usage outside Google is now multi-year and consistent across consumer surveys, app-store rankings, browser-extension installs, and our own client analytics. Brands that wait until ChatGPT or Perplexity has “real share” will start their optimization with no presence and compete against incumbents who have spent the prior two years compounding.

Third, it ignores the cross-engine training feedback loop. Content that gets cited in Perplexity, ChatGPT, and Claude is more likely to be present in the corpora those models are retrained on. Skipping the smaller engines today is skipping the corpus weighting that will define the answers your customers see two years from now. The smartest GEO programs treat Perplexity citation in particular as a leading indicator for cross-engine durability.

Lexical to Neural: A Practitioner’s Map

Information retrieval went from matching tokens to comparing geometry. The shift is not technical trivia; it is the reason your content either lives in the right neighborhood of the model’s embedding space or does not, and why keyword density stopped paying years ago.

The lexical era, briefly

Classical IR — the system you would have studied in a graduate course twenty years ago — was about counting. The inverted index let a search engine find every document that contained a given token. TF-IDF (term frequency inverse document frequency) gave each occurrence a weight that fell with how common the term was across the corpus. BM25, the workhorse refinement, added length normalization and tunable saturation so that a single keyword appearing ten times did not get ten times the weight of appearing once.

This whole apparatus operated on the literal word. “Auto” and “car” were unrelated. “Bank” meaning a financial institution and “bank” meaning the edge of a river were the same token. Synonymy and polysemy were handled, if at all, by query expansion: explicit rules that said “if the user typed X, also retrieve Y.” The expansion tables were curated by humans, brittle, and obviously a hack.

SEO grew up inside this lexical era. The discipline of stuffing target keywords (and their synonyms) into a page, watching their density, and tuning anchor text was a rational response to how retrieval actually worked. None of this was wrong; it was simply a discipline shaped by the system it served.

The semantic interregnum

The 2000s and 2010s produced a series of incremental moves away from pure lexical matching. Latent Semantic Indexing (LSI) used matrix decomposition to find term-document patterns. Word2Vec (2013) gave us the first widely useful dense embeddings — the famous “king minus man plus woman is approximately queen” demonstration showed that semantic relationships could be represented as geometric operations on vectors. GloVe refined the approach. FastText extended it to subword units.

The crucial conceptual shift in this era was the move from token matching to vector similarity. Documents and queries could be represented as points in a high-dimensional space; relevance became a property of geometric proximity rather than literal overlap. The mathematics was specialist; the consequence was profound. A query about “dog ownership tax deductions” could now retrieve a document that never used the word “dog” if its embedding sat in the right neighborhood — close to canine, pet, animal, household, and the tax-deduction cluster.

SEO mostly missed this shift, or misread it. The phrase “semantic SEO” appeared and was largely co-opted to mean “use related keywords” — a lexical adaptation to a semantic system. The genuine implication, that content should be optimized for the neighborhood it occupies in vector space rather than the keywords it contains, took another decade to land.

The neural era and what changed

The 2017 Attention is All You Need paper from Google introduced the transformer architecture and made the neural era operational. BERT (2018) gave us bidirectional contextual embeddings: the word “bank” in “river bank” gets a different vector than in “investment bank,” because the model attends to surrounding context. Sentence-BERT and its successors made passage-level embeddings cheap. The whole stack of dense retrieval — encode your corpus into vectors once, embed each query at retrieval time, run an approximate nearest-neighbor search, return the top-k passages — became the standard architecture for modern retrieval.

What changed materially:

• Synonymy is automatic. The system understands that “car” and “automobile” are close in embedding space without you needing to write that down.
• Polysemy is contextual. The system disambiguates “bank” by looking at the surrounding tokens, automatically.
• Passage matters more than page. Retrieval is at the chunk level; a paragraph that lands in the right neighborhood beats a page whose overall embedding is muddled.
• Topical clustering is real. Pages that share an embedding neighborhood reinforce one another; internal linking matters as a topical-cluster signal in addition to as an authority-flow signal.
• Hybrid retrieval is the production reality. Most engines combine BM25 (lexical, fast, precise on rare terms) with dense vector search (semantic, recall-oriented), then rerank the merged candidates with a cross-encoder.

The four embedding granularities you should think about

Embeddings exist at multiple levels. A serious GEO practitioner needs to think about all four.

Token embeddings live inside the model. You do not optimize these directly; you optimize the input that produces them by choosing your words carefully — specifically, by using domain-canonical terminology rather than synonyms a model might map to a different cluster.

Passage embeddings are what most retrieval systems actually compare. Each paragraph (or paragraph-sized chunk, often 200–500 tokens) gets its own vector. A page can have a strong overall topic but contain passages that drift into adjacent topics; those drift passages have their own embeddings and will be retrieved for queries that match them. This is why “one page per intent” SEO advice never quite captured the dynamics; the modern equivalent is “one passage per assertion, structured cleanly enough to be lifted independently.”

Document embeddings are aggregated representations of full pages. Used in some reranking and topic-clustering layers. Less directly relevant to retrieval than passage embeddings, but they matter for whether the system recognizes your page as authoritatively about a given topic.

Domain and entity embeddings are the most under-discussed and most strategically important. Major search systems maintain embeddings for entire domains and for named entities (people, organizations, products) that exist across the web. Your domain’s embedding sits in a neighborhood defined by what you publish. Move your publishing into a new vertical, and your domain embedding drifts. Cite the right authoritative sources, and your domain embedding moves toward theirs.

What this means for content production

Three operational implications.

Stop optimizing for keyword density; start optimizing for topical neighborhood. The question is not “does my page have the target keyword ten times” but “does my page, read as a passage, embed near the queries I want to win.” The way you test this is by running synthetic queries against your own corpus through an embedding-based retrieval simulator. We will give the playbook in Chapter 15.

Treat passages, not pages, as the unit of optimization. Every important assertion gets its own paragraph. Every paragraph stands on its own when extracted in isolation — including any named entities, quantitative claims, and citation references it needs to be useful as a standalone fragment.

Cite authoritative sources to anchor your own domain embedding. When your content cites government data, peer-reviewed research, or canonical institutional sources, your domain embedding moves toward those sources’ neighborhood. This is a slow effect, but it compounds, and it is one of the few interventions that produces measurable shifts in cross-engine citation durability.

The neural era is not the last era

Models keep getting better at retrieval. Recent work on multi-vector representations (ColBERT and its descendants), efficient approximations (MUVERA from Google for compressed multivector retrieval), and learned sparse representations (SPLADE) are all incremental improvements to the same underlying picture: representing meaning as geometry, comparing geometries to find relevance. None of this changes the practitioner’s job, but it does mean the optimization surface is moving. The discipline is to stay tied to first principles — structure, clarity, distinctive content, accurate entity references — rather than to chase whichever technical refinement is fashionable this quarter.

Inside the Engines: Four Architectures, Four Levers

Every AI search engine follows the same retrieve-rerank-synthesize spine, but the levers that move citations are different enough that one-size-fits-all GEO produces wasted effort. This chapter is the teardown.

The shared spine

Across Google AI Mode, ChatGPT search, Perplexity, and Claude, the pipeline looks like this. The user’s typed query gets rewritten by an upstream LLM into one or more retrieval queries that better match the underlying retrieval index. Each rewritten query is dispatched against one or more retrieval back-ends: a lexical index (BM25 or equivalent), a dense vector index, sometimes an entity-graph traversal, sometimes a domain-restricted federated search. The candidate documents come back, get reranked by a cross-encoder model that scores each candidate against the rewritten query in context, and the top-K survivors are synthesized by the generative model into the answer the user sees. Citations are inserted at synthesis time, frequently with a separate citation-selection model deciding which sources to attribute.

The spine is consistent; the implementations diverge sharply.

Google AI Mode — the index you cannot beat

Google’s AI Mode is the only engine in this list that retrieves against a comprehensive, continuously updated index of the open web. The retrieval side is Google’s existing crawl + index pipeline, with AI Mode adding query-fan-out, passage extraction, and synthesis on top.

The optimization levers, in rough order of impact:

1. Be cleanly indexable by Googlebot. If classic Google does not have you, AI Mode does not have you. SEO hygiene is the entry condition.
2. Structured data and entity alignment. AI Mode appears materially more sensitive to schema.org type coverage, sameAs identifiers to canonical sources (Wikidata, Wikipedia, LinkedIn for people and organizations), and Knowledge Graph entries than classic Search.
3. Passage extractability near the top of body content. Passages that answer common questions in the first 200–300 words of the body are disproportionately surfaced.
4. Freshness for time-sensitive queries. AI Mode incorporates last-modified signals more aggressively than classic Search. Stale content that ranked well on authority alone is increasingly being passed over.
5. Authority signals. Domain authority, internal-link topical clustering, and link-graph centrality continue to matter, though the weights appear lower than in classic Search.

ChatGPT search — the just-in-time fetcher

ChatGPT does not maintain a persistent crawl of the open web. When the user’s query triggers search (which is most queries in GPT-5.x with the search tool enabled), the system runs a federated query against Bing’s index, plus its own internal scoring, identifies candidate URLs, and fetches them on demand. The retrieved page contents are inserted into the model’s context window for synthesis.

The optimization levers are different in character:

1. Allow OAI-SearchBot, GPTBot, and ChatGPT-User in robots.txt. If the fetcher cannot retrieve your URL, you are not cited. We see this routinely on enterprise sites whose CDN defaults block OpenAI’s crawlers.
2. Sub-second TTFB. The fetcher has a budget. Pages that take three seconds to first byte are often abandoned mid-fetch and never enter the synthesis context.
3. Render-free HTML. ChatGPT’s fetcher does not execute JavaScript in any reliable way. If your content appears only after client-side rendering, it is invisible.
4. Clean passage structure near the top of the body. Same as Google AI Mode, but more critical — ChatGPT’s context window is bounded and the synthesizer often pulls only the first chunk.
5. Bing-side ranking. Because the federated query runs through Bing, classical Bing SEO still moves ChatGPT citations. Bing Webmaster Tools, IndexNow integration, and structured-data alignment matter here in a way they do not for Google’s AI Mode.

Perplexity — the legible engine

Perplexity is the most observable engine in the set. It exposes its source list, often shows you the rewritten queries it ran, and tends to cite more sources per answer than any other engine. Architecturally, it runs hybrid retrieval (lexical + dense) against its own crawled index, supplemented by federated queries to specialized back-ends (academic, news, video). It also exposes a Sonar API that lets you probe its retrieval programmatically — the cheapest, most legible target for an instrumented GEO program.

Optimization levers:

1. Allow PerplexityBot and Perplexity-User. Their crawl is aggressive when allowed.
2. Passage clarity above all else. Perplexity is the most extractive engine in the set; clean, self-contained passages with explicit subject-predicate-object structure win.
3. Citation-worthy distinctive data. Perplexity systematically prefers sources with original data, named statistics, and quantified outcomes over sources that aggregate or rephrase.
4. Inline citations to authoritative sources within your own content. Perplexity weights pages that themselves cite primary sources more heavily.
5. Schema.org type coverage. Particularly Article, Dataset, ResearchArticle, and HowTo.

Claude (Anthropic) with search — the conservative reader

Claude’s retrieval, when enabled, draws from a federated set of sources weighted toward institutional credibility. The engine is more conservative than Perplexity, frequently choosing fewer but more authoritative citations, and is the engine most likely to refuse a synthesis if the retrieved sources do not agree.

Optimization levers:

1. Allow ClaudeBot, Claude-Web, Claude-User, Claude-SearchBot.
2. Institutional anchoring. Citations to .gov, .edu, peer-reviewed sources, and well-known publishers weight your content as more credible. Pages with no citation surface lose to pages with citations to canonical sources.
3. Named author attribution. Claude weights byline-attributed content with author schema higher than anonymous content.
4. Explicit dates and version metadata. Claude is more sensitive to freshness signals than ChatGPT and tends to mark stale content with caveats in synthesis.
5. Original research and data. Claude is the engine most likely to cite a small site with original data over a large site with aggregated content. This is the engine where the content-moat thesis (Chapter 30) pays off fastest.

A practical optimization matrix

Most teams that try to optimize for all four engines simultaneously end up doing nothing well. The discipline is to choose two as primary and two as secondary, based on where your buyer actually spends decision time.

Fan-Out and the Hidden Surface Area

The visible query is a fraction of the actual retrieval. Generative engines decompose user input into a branching tree of sub-queries and aggregate sources across the branches. The content that wins is present across the tree, not just optimized for the seed term — and the right metric for this is not coverage but survivability.

What fan-out actually looks like

Take a single user query: “best CRM for a 50-person services agency.” If you watched an engine like Perplexity process this, you would see something like the following unfold inside the system, only some of which surfaces to the user:

• A category clarification sub-query: what defines a CRM for a services agency vs. a product company
• A size-segmentation sub-query: CRM tools commonly used by 25–100 person agencies
• A capability fan-out: CRMs with project tracking, time billing, client portal, retainer management
• A peer-review fan-out: G2, Capterra, TrustRadius reviews for the candidate vendors
• A pricing fan-out: list pricing and tiered pricing for each candidate
• A community-voice fan-out: Reddit, agency communities, Slack groups discussing each candidate
• A recency check: any major launches, acquisitions, or controversies in the last six months

The user sees a synthesized answer with maybe five citations under it. The system retrieved against dozens of sub-queries to produce that synthesis. Your brand needs to be present across the fan-out tree — in the category content, in the size-specific content, in the capability content, in the peer-review surfaces, in the pricing-comparison surfaces, in the community discussions, and on the news surfaces — or the synthesis happens without you.

Why “coverage” is the wrong frame

The early fan-out conversation in the GEO industry borrowed the term Query Fan-Out Coverage (QFO_c) — the percentage of fan-out sub-queries for which your URL appears in the candidate set. Useful, but it understates what is actually happening.

Fan-out is not just a coverage problem; it is a competition problem. Each sub-query produces its own candidate set. Each candidate set is reranked. Top-K survivors from each sub-query feed the synthesis. Your URL has to survive the rerank gauntlet across multiple sub-queries to be cited. That is a different measurement than “showed up somewhere in the candidate pool.”

The metric that captures this is what we call QFS — Query Fan-Out Survivability: the percentage of background sub-queries on which your URL is cited (not merely retrieved) by the synthesis. Industry-standard target: QFS ≥ 50% means your content survives more than half the fan-out paths, which translates reliably to consistent citation. QFS < 15% means you are not really in the conversation.

Measuring fan-out you cannot directly see

Three of the four major engines (Google, ChatGPT, Claude) do not expose their fan-out branches. Perplexity exposes them partially. So how do you measure QFS for engines that hide the tree?

The technique is query perturbation: take your seed query, generate fifteen to thirty plausible reformulations and decompositions, run each through the engine, and observe which of the variations cite your URL. The reformulations should cover what we expect the engine’s own fan-out to produce — category variations, size variations, capability variations, pricing variations, peer-comparison variations, and so on. If your URL appears across twenty of thirty reformulations on Perplexity, your effective QFS on Perplexity is around 67%; if it appears on three of thirty, your QFS is around 10% and you need work.

The technique is mechanical, repeatable, and we run it for every client at quarter end. It gives you a defensible number, a per-engine breakdown, and a list of sub-queries where you currently lose — which becomes the content-production backlog for the next quarter.

Slots, not pages

Fan-out reframes the content-strategy question. Instead of asking “what pages should I build,” you ask “what sub-query slots am I currently losing on, and what content satisfies each?” The slots that show up in fan-out trees for any given category include:

• Definitional slots (“what is X”) — satisfied by clean glossary entries and Wikipedia-style first-paragraph definitions on your own pages.
• Comparative slots (“X vs Y”) — satisfied by genuine side-by-side comparison content, not vendor-spin take-downs.
• Capability slots (“can X do Y”) — satisfied by explicit feature documentation with named capabilities.
• Use-case slots (“X for use case Z”) — satisfied by case studies, customer stories, and use-case pages with named outcomes.
• Constraint slots (“X under condition Z”) — satisfied by content addressing the relevant constraint (budget, team size, regulation, geography).
• Quantitative slots (“how much / how fast / how many”) — satisfied by pages with explicit numbers and citation surfaces.
• Procedural slots (“how to”) — satisfied by HowTo-schema-marked instructional content.
• Recency slots (“latest”) — satisfied by genuinely updated content with explicit dates.

The right content roadmap is not a list of titles or keyword targets; it is a slot inventory. A serious GEO content brief now reads like an architecture document: which sub-query slot does this page satisfy, what content already exists on the property that satisfies it, where does that content sit on the property, and what schema makes the satisfaction legible to retrieval.

The multimodal fan-out

Fan-out is not text-only. Modern engines route some sub-queries to image, video, and structured-data back-ends. A query about “wiring a three-way switch” will fan out to YouTube transcripts as one branch; a query about “average rent in Phoenix neighborhoods” will fan out to tabular data sources; a query about “what does this plant look like” will fan out to image search.

This is one of the strongest arguments for content-format expansion. Brands that publish only HTML are competing for the text branches and ceding the image, video, and structured-data branches. We will return to this in Chapter 23 (video) and Chapter 30 (the content moat). For now: your fan-out coverage is bounded by your modality coverage. If you have no video, you lose every video branch by default.

The chunk-level mindset

The deeper conclusion is that the optimization unit has shifted from the page to the chunk — a passage of roughly 200–500 tokens that retrieval systems treat as the smallest extractable unit. The chunk-level question, applied to every important section of content you ship, is: which sub-query slot does this chunk satisfy, and is it self-sufficient when extracted in isolation?

Self-sufficient means three things. First, the chunk names its subject explicitly (no “it,” “this,” or “the company” that requires page-level context to resolve). Second, the chunk states its assertion in a form a model can extract as a triple (subject-predicate-object) without inference. Third, the chunk surfaces any qualifying conditions, sources, or dates inline rather than relying on the surrounding narrative.

The shift from page-level to chunk-level optimization is the most important practical implication of fan-out, and it is the principle that drives most of the content recommendations in Chapter 11.

Appearing in the Answer

There is a finite list of interventions that materially move whether your content appears in AI-generated answers. Most of them are unglamorous. Together they form the practice floor below which no optimization program is real.

The opening checklist

Before tactic-level optimization, your property has to clear a baseline checklist. Skip any of these and the rest of this chapter is academic.

1. Your robots.txt explicitly allows the AI bots that matter. GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-Web, Claude-User, Claude-SearchBot, anthropic-ai, PerplexityBot, Perplexity-User, Google-Extended, GoogleOther, Applebot, Applebot-Extended, Meta-ExternalAgent, Bytespider, Amazonbot, CCBot, cohere-ai, and the long tail of named AI crawlers. The default deny posture inherited from CDN templates is the single most common reason brands are invisible.
2. Your origin returns 200 to those bot UAs. Some CDNs allow the bot in robots.txt but block its actual fetches at the WAF layer. Test by running a real curl with each UA. We have seen Fortune 100 brands return 403 to GPTBot from behind an enterprise CDN whose default rule set treats unfamiliar UAs as suspicious.
3. Your sitemap is current and discoverable. sitemap.xml at the root, linked from robots.txt via the Sitemap: directive, with accurate <lastmod> timestamps. Stale lastmod is worse than no lastmod — it signals fresh content the engine then discovers is years old.
4. Your homepage and category templates render meaningful HTML on first response. Client-side-only rendering is a retrieval death sentence for ChatGPT and a partial penalty for others. If your framework requires JavaScript, server-render the meaningful content.
5. You ship the basic AI-facing files. llms.txt and llms-full.txt at the root, /.well-known/mcp.json if you have MCP-callable endpoints, and a clean JSON-LD payload on the homepage and key category templates.

Five items. Plenty of brands fail two or three of them. None of the more sophisticated tactics matter if these are not in place.

The structured-data layer that actually moves citations

Schema.org has been the SEO industry’s structured-data standard since 2011, and most properties ship some version of it. The bar for AI-search citation is higher than the bar for classic rich-result eligibility, because retrieval systems use structured data both for ranking and for synthesis. Three principles distinguish a useful structured-data implementation from a ceremonial one.

Type breadth, not single-type depth. A page about a product should carry Product schema, but the surrounding page often deserves additional schema: Article for the editorial content, FAQPage for the embedded Q&A, Review for the user-review block, BreadcrumbList for navigation context, and Organization for the publisher. Each additional type gives the retrieval system another semantic handle. Engines that select citations weight pages with rich type coverage more heavily, all else equal.

sameAs to canonical identifiers. Every Person, Organization, Place, and Product in your structured data should include sameAs values pointing to canonical identifiers — Wikidata, Wikipedia, official social profiles, official LinkedIn pages, registry IDs. This is the structural anchor that lets a retrieval system collapse your entity into the same entity referenced on a hundred other sites. Without sameAs, your entity is an island; with it, your entity sits in the connected graph.

citation and isBasedOn as first-class fields. Many serious GEO programs underuse the citation and isBasedOn properties on CreativeWork, Article, and Dataset schemas. These properties tell the retrieval system explicitly which other sources your content draws from. They also give your domain’s embedding a measurable nudge toward the embedding of the cited sources.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Quarterly Analysis: Citation Persistence Across Four Engines",
  "datePublished": "2026-04-15",
  "dateModified": "2026-04-22",
  "author": {
    "@type": "Person",
    "name": "Robert Maynard",
    "sameAs": [
      "https://www.wikidata.org/wiki/Q18157412",
      "https://www.linkedin.com/in/robertjmaynard/"
    ]
  },
  "publisher": {
    "@type": "Organization",
    "name": "AnswerShare",
    "sameAs": [
      "https://www.linkedin.com/company/answershare/"
    ]
  },
  "citation": [
    { "@type": "ScholarlyArticle", "name": "BM25 vs Dense Retrieval Evaluation",
      "url": "https://arxiv.org/abs/..." },
    { "@type": "Report", "name": "Pew AI Search Behavior Survey 2026",
      "url": "https://www.pewresearch.org/..." }
  ],
  "isBasedOn": [
    "https://datasets.example.org/citation-probe-results-2026q1"
  ]
}

The passage as the unit of optimization

Chapter 8 introduced the chunk-level mindset; here we operationalize it. Every important assertion on a property should sit in a self-sufficient passage of 80–200 words. Self-sufficient means three things.

First, the passage names its subject explicitly. No “it,” “they,” or “the platform” that requires the previous paragraph for resolution. Engines extract passages and discard surrounding context; the passage has to carry its own subject.

Second, the passage states the assertion in a form that maps cleanly to a subject-predicate-object triple. “AnswerShare clients see a median 47-point GEO improvement over six months” is extractable. “Our clients tend to see significant improvements” is not.

Third, the passage carries its qualifiers, dates, and source citations inline. A quantitative claim without a date is worse than no claim, because the engine cannot decide whether to weight it as fresh.

Internal linking as topical-cluster signaling

The internal-linking advice from the classic SEO era — flow PageRank to important pages with anchor text matched to the target page’s topic — remains directionally correct. Two refinements for the AI era.

The first is that anchor text now contributes to the target page’s topical neighborhood in embedding space, not just to its lexical match. Anchor text saying “CRM for services agencies” pointing to your page nudges the page’s embedding toward that neighborhood. Use specific, topical anchors; the generic “learn more” anchor is a wasted signal.

The second is that internal links function as a topical-cluster signal — pages that link to each other tightly inside a cluster reinforce one another’s authority on the cluster’s topic. The implication: build genuine content clusters with comprehensive interlinking, not isolated “pillar pages” with thin satellites.

Freshness signals you can actually defend

Freshness matters but is the most-gamed signal in GEO. Daily “last modified” bumps without content change are detectable and increasingly penalized. The right pattern: real content modifications produce real lastmod updates; pages that are genuinely stable can carry their original date.

What does count as a real modification: adding a new section, updating a quantitative claim, refreshing citations to current sources, incorporating a new development in the topic. What does not count: punctuation tweaks, image-alt-text updates, or template-driven changes that touch every page on the same day.

What does not move citations

Equally important: the things SEO practitioners habitually invest in that do not materially move AI-search citation.

• Keyword density. Already dead in classic SEO, deader in AI search. Stop counting.
• Meta-description hygiene. Meta descriptions remain useful for classic SERP CTR; they do not enter AI synthesis.
• Title-tag length optimization. Helps classic Google CTR; ignored by AI synthesizers, which use body content.
• Reciprocal-link networks. Already toxic in classic SEO, irrelevant in AI search where the link graph is one signal among many.
• “Search-intent optimization” that produces thin keyword variations. The fan-out tree is what you optimize for; producing 12 thin pages targeting close variants of the same query is a fan-out anti-pattern.

Engineering for Extraction

Relevance engineering is the practical discipline of shaping content so retrieval systems can extract, score, and cite the right passages. It is not a content-marketing discipline; it is closer to information architecture with a feedback loop.

The five operations that constitute relevance engineering

Across every relevance-engineering engagement we run, the work decomposes into five operations applied in a loop. Treat these as the canonical practice surface.

1. Audit the existing extraction surface. Walk each priority template (homepage, category, product, article, location, etc.) and ask: if a retrieval system fetched this page and lifted the first 300 words of body content as a candidate passage, does it have a coherent claim? Does it have the entity name? Does it have a date? Does it carry citations? Most templates fail this test because they lead with hero marketing copy and bury the substance.

2. Identify the slot inventory you need to satisfy. Apply the fan-out framework from Chapter 8 to your top fifteen seed queries. Run query perturbation. Identify which sub-query slots your content currently satisfies and which it does not. The output is a slot-coverage spreadsheet that drives the rest of the work.

3. Restructure passages for self-sufficient extractability. For each priority slot you currently lose, rewrite the relevant passages so they pass the chunk-level self-sufficiency tests: explicit subject, extractable triple, inline qualifiers and citations.

4. Ship the structural metadata. Add the structured-data types each priority slot benefits from. Add sameAs anchoring to canonical entity identifiers. Add citation and isBasedOn references that anchor your domain’s embedding toward authoritative neighborhoods.

5. Simulate before you publish. Run the rewritten passages through a local retrieval simulator (Chapter 15) plus a multi-engine probe against the actual public retrievals (Chapter 13). Iterate until the simulation shows lift; ship; measure post-publish; iterate again.

Topic clustering as a deliberate architecture

Topical authority is not declared; it is constructed through deliberate clustering. The pattern: pick a core topic on which the property aspires to be cited. Build the central definitional page that satisfies the “what is X” slot at high density. Build the comparative page that satisfies “X vs Y” for the relevant competitors. Build capability-specific pages for the top capabilities buyers ask about. Build use-case pages for the top use cases. Build a methodology page that lays out the framework. Build case-study pages with named outcomes. Interconnect them with topically anchored internal links.

Twelve well-structured, interlinked pages on a topic outperform forty thin pages every time. The thin-page pattern was a viable hack in the late SEO era; it is a structural disadvantage in the AI era because the engines weight cluster coherence in their domain-embedding signals.

The triple as the unit of fact

Retrieval systems do not parse prose; they parse passages and extract triples. The discipline of writing for extraction is the discipline of writing triples that survive parsing.

A triple is the smallest unit of factual content: subject + predicate + object. “AnswerShare maintains a 4-model median scoring methodology.” Subject: AnswerShare. Predicate: maintains. Object: 4-model median scoring methodology. Extractable; usable as a knowledge claim.

Compare: “We take a thoughtful, multi-perspective approach to ensure rigor in our analytical work.” Subject: implicit. Predicate: take. Object: an approach. Extractable, but as a piece of marketing-prose-shaped fog rather than a factual claim. The engine pulls nothing usable.

This is not a request to write robot-prose. It is a request to ensure that every important sentence in a passage can stand as a factual claim, even if the surrounding sentences are stylistically varied. The mix should be: declarative-factual claims for substance, varied sentence rhythm for readability, no sentence that is rhetorical filler.

Vector tuning — what it actually means

Mike King has called this “tuning vectors,” and the phrase is widely used but rarely operationalized. In practice, “tuning vectors” is shorthand for two operations.

The first is making sure your content occupies the embedding neighborhood you want it to occupy. You test this by encoding your content and your target queries with the same embedding model (most easily, OpenAI’s text-embedding-3-large or Google’s text-embedding-005), then computing cosine similarity. If similarity is high, your content is in the neighborhood; if it is low, you have a content problem — either your content is off-topic, or it is too jargon-distant from how users phrase queries.

The second is identifying the gap between your content’s embedding and the embedding of competitor content that wins citations you want. You take the competitor’s passage, encode it, encode yours, compute the difference vector. The difference vector tells you which semantic axes you are short on. It is not magic; it just systematizes the “what does the winning page do that mine does not” analysis.

Common engineering mistakes

• Optimizing the homepage for a citation surface. Homepages get few citations in AI search. Deep pages with specific topical content get the citations. Optimize the deep pages first; the homepage is the front door, not the citation surface.
• Building “pillar pages” without supporting cluster pages. The pillar-cluster model from late-stage SEO works only if the cluster is real. A pillar with no cluster is a thin page in disguise.
• Adding structured data without verifying it parses. Schema validators are free; broken JSON-LD is invisible to engines that fail silently. Validate every schema type you ship.
• Treating relevance engineering as a one-time project. The engines update, the fan-out shifts, competitors publish. Relevance engineering is a continuous discipline with quarterly cadence at minimum.

Content Strategy for a Machine Audience

Content strategy for AI search starts from the assumption that the primary reader is a machine. This is not a degradation of editorial quality; it is a clarification of audience that makes good editorial decisions easier, not harder.

Machine readers are demanding readers

The conventional reaction to “write for machines” is “great, so dumb-down to keyword-stuffed pap.” The conventional reaction is wrong. Machine readers are more demanding than human readers in several specific ways.

Humans tolerate ambiguity, repetition, and rhetorical filler because they can skim. A machine reader, especially one that will lift a 200-token chunk to feed into a synthesis, has no skim mode. It takes the chunk as the chunk. If the chunk is ambiguous, the synthesis inherits the ambiguity; if the chunk is rhetorical filler, the synthesis pulls nothing usable. Machines reward clarity in a way that human readers do not punish vagueness.

Humans tolerate undated claims. They assume current. A machine reader, encountering a quantitative claim without a date, has to decide whether to weight it as fresh or as stale, and increasingly weights undated claims down. Machines reward explicit dating.

Humans tolerate uncited claims. They trust the author. A machine reader, encountering a claim without citation, has to decide whether to trust the claim or seek corroboration elsewhere. Machines reward citation, and weight cited claims as candidates for direct synthesis.

Humans tolerate generic entity references (“the company”). A machine reader needs the explicit named entity in the passage to resolve the subject. Machines reward explicit naming.

Read together, these requirements describe high-quality editorial work, not degraded keyword-stuffed work. The discipline is reportorial: name your subjects, date your claims, cite your sources, write declaratively.

The R.E.A.L. tenets — with a sharper edge

Various GEO writers, Mike King included, have used the R.E.A.L. mnemonic (Resonant, Experiential, Actionable, Leveraged). The mnemonic is fine; we sharpen each tenet for the chunk-level reality of AI search.

Resonant. The chunk speaks to a real, named user concern with a real, named outcome. Generic concerns (“reach more customers”) lose to specific ones (“reduce sales-cycle length for enterprise pilots from 12 months to 9 months”).

Experiential. The content draws on first-hand operating data — what your team actually saw, measured, did, learned — rather than secondhand industry framing. AI engines increasingly weight first-hand experience signals (E-E-A-T’s Experience axis) and discount aggregated material.

Actionable. Every important chunk leads with a claim a reader (human or machine) can act on, then unpacks the supporting logic. The inverted pyramid was not invented for the AI era, but the AI era rewards it more than any prior era.

Leveraged. The content unlocks distribution beyond its own page. A case study with quantified outcomes becomes a press citation, a methodology page reference, a benchmark in a competitor’s comparison, a sub-claim in an AI synthesis. Leveraged content is content that other content cites, and that compounds.

Information gain — the metric that actually predicts citation

The most useful single concept in this whole chapter is information gain: the increment of new, citable claim that your content adds beyond what is already available in the corpus. The metric is not literal; it captures the underlying retrieval-system preference for sources that say something the model could not get elsewhere.

Information gain has three sources. Original data: surveys, telemetry, internal measurement, experiments your team ran. Original analysis: novel synthesis of existing data, named frameworks, defensible interpretations the corpus does not already contain. Operating receipts: specific case-study outcomes, named clients, quantified deltas, dated events.

Content with high information gain wins disproportionate citation because the retrieval system has no equivalent fragment to pull from a competitor. Content with low information gain — rephrased industry consensus, derivative explanations, generic best-practice lists — loses to the source the system already trusts on those topics, which is typically Wikipedia, an established publisher, or a competitor with more authority.

This is the single biggest argument for why an AI-era content program is shaped more like an original-research operation than a content-marketing operation. The R.O.I. case for publishing original survey data, telemetry, and case studies is dramatically stronger in the AI era than in the SEO era, because the citation premium for information gain is dramatically higher.

The llms.txt question, settled

There is debate in the GEO community about whether llms.txt is worth shipping. The skeptical view is that it is not a recognized standard, adoption among engines is uneven, and the time spent maintaining it could be spent on more proven conventions. The view we take, and have implemented across every client property: ship it anyway.

Three reasons. First, the cost of shipping llms.txt and llms-full.txt is near-zero — a generation script that runs at deploy time. Second, several engines have begun consulting it inconsistently but non-trivially, and that fraction is growing. Third, even if no engine consulted it, the discipline of maintaining a curated, machine-readable index of your most important content is editorially useful in itself — it forces you to decide what your priority pages are and what canonical descriptions of them look like.

The argument that llms.txt is “premature” treats AI search as if it has a settled feature set against which adoption can be measured. It does not. The conventions that win are the ones that early adopters ship and that engines then begin to consult; refusing to ship them ensures you have no presence in the convention layer when it consolidates.

What the “Google is indifferent to AI content” claim gets wrong

A cottage industry has grown around the claim that Google is indifferent to AI-generated content as long as it is “helpful.” The strict reading: surface coherence is enough. The implication some draw: scale your content production with AI, optimize for surface coherence, win.

We disagree based on direct measurement. Properties that scale AI-generated content production typically show one of two patterns: short-term ranking gains followed by helpful-content-update demotions; or steady underperformance on AI-search citation despite continued classical-SEO rankings. The first pattern is well-documented across the Helpful Content Update cycle; the second is what we see in our own client work when comparing AI-generated content to first-person-authored content side by side on the same property.

The likely mechanism is straightforward. AI-generated content is heavy on surface coherence and light on information gain. It produces fragments that retrieve well on lexical overlap but lose to fragments with distinctive data or first-person operating experience during cross-encoder reranking. The engine selects the fragment with the higher information-gain signature, and the AI-generated fragment loses by construction.

This is not a moral argument against AI-assisted content production. AI is fine as a drafting tool, fine as a research accelerator, fine as a rewrite-pass tool. It is a category error to treat AI as a publisher of authoritative content. The publisher has to be the human or team with the operating experience that produces information gain; the AI accelerates the work, it does not substitute for the source.

The Measurement Vacuum

There is no Search Console for AI search. The retrieval-and-synthesis layer is structurally invisible to traditional analytics, so the practitioner has to build measurement infrastructure rather than wait for platforms to expose it. The good news is that the infrastructure is buildable.

What you actually do not know without instrumentation

In the classic search world, Google Search Console gives you impressions, clicks, average position, and CTR per query per page. Bing Webmaster Tools gives you a thinner equivalent. You know, with reasonable precision, what users typed, which of your pages they saw, and which they clicked.

In the AI search world, you know none of that by default. You do not know which queries triggered which fan-out branches. You do not know which of your pages were retrieved. You do not know which were reranked into the candidate pool. You do not know which were cited in the synthesis. You do not know which fraction of users who saw the answer clicked through to your page (and your server logs will not tell you, because most AI engines do not pass useful referrers). You do not know whether the user was satisfied by the synthesis without clicking, or dissatisfied and walked away.

This is not a temporary gap that platforms will close. It is a structural property of the architecture. The retrieval layer happens in the engine’s infrastructure; the synthesis layer happens in the engine’s model; the user’s decision happens in the engine’s UI. None of these stages have any reason to expose their internals to the publishers whose content they ingest.

The three-tier measurement stack

The right response is to build proprietary measurement at three tiers. We use this structure for every client; it is also approximately what iPullRank and Profound have converged on independently.

Tier 1: Input measurement — what is happening to your content before it ever reaches a synthesis. Server-log analysis filtered by AI bot UA tells you which engines are crawling, which pages they fetch, how often, with what HTTP responses. Cross-referenced with engine bot identity, this gives you a per-engine fetch volume and pattern that is a leading indicator for citation.

Tier 2: Channel measurement — what is happening inside the synthesis layer. Active probing against the canonical queries you care about, across all four engines, repeated on a cadence (we use weekly), captures whether your URLs are surfacing as citations and at what position. The dashboard we build for clients tracks share-of-voice in AI panels, citation position, and source prominence over time.

Tier 3: Performance measurement — what is happening to your business as a function of the above. Segmenting your analytics by AI referrer where possible (Perplexity passes a referrer; others mostly do not, but ChatGPT users sometimes carry recognizable UTM patterns from copy-paste behavior), capturing AI-source-mention in customer onboarding (“how did you hear about us” surveys), and tracking inbound calls that reference AI-discovered information.

Why distributional metrics, not point estimates

The most under-appreciated property of AI-search measurement is that the answer is probabilistic. Two identical queries, run two minutes apart, may produce different citation sets. The same query run on the same engine on the same day, by two different users, may produce different citations — the engines personalize, the retrieval is stochastic, and the synthesis model has temperature.

The practical implication: any single measurement is unreliable. You need distributional metrics — the median citation across N probes, the variance, the persistence across time slices, the share of probes in which your URL appeared.

This is the load-bearing argument for the 4-model median + outlier-drop approach (Chapter 4 frame, Chapter 28 detail). A single probe against a single engine on a single day is anecdote. The median of four engines across four time slices over a month, with outliers dropped, is measurement.

Profound, Conductor, BrightEdge — the peer measurement vendors

A handful of commercial vendors now sell AI-search measurement as a category. We treat them as respected peers, not as competitors to beat on every axis.

Profound is the strongest pure-play AI-search-visibility measurement product. They ingest clickstream from a real user panel, correlate it with AI engine retrieval, and produce measurement that is genuinely difficult to replicate without their panel. We do not try to compete on panel-derived measurement; for clients who need that signal, Profound is a good answer.

Conductor and BrightEdge have bolted AI-search modules onto their enterprise SEO platforms. Useful if you are already on their platforms; not differentiating enough to switch onto, in our view.

Where AnswerShare’s measurement stack adds value beyond the pure-play vendors: the integration with our scoring rubric (Chapter 26), the cross-engine median methodology (Chapter 28), and the translation-layer-instrumented bot-traffic measurement that captures retrieval before it reaches synthesis. Different question, complementary answer.

Building Your Own Telemetry

The active probing layer of AI-search measurement is mechanical, cheap, and within reach of any team willing to write the code. This chapter is the operating manual.

The active-probe layer

Active probing means programmatically issuing queries against AI engines and capturing the responses for analysis. The mechanics differ per engine but the pattern is the same.

For Perplexity, the Sonar API gives you direct, billable access to the same retrieval and synthesis pipeline that serves Perplexity.ai users. Cost: roughly $0.005–$0.01 per query depending on tier. For OpenAI, the Responses API with web search enabled gives you ChatGPT-style retrieval. Cost: about $0.01 per query for gpt-4o-mini-search-preview, which is the model we recommend for high-volume probing. For Gemini, the Gemini API with Google Search grounding enabled gives access to Google’s retrieval signal. Cost: about $0.003 per query for gemini-2.5-flash with grounding. For Anthropic, the Messages API with the web_search tool enabled gives access to Claude’s search-augmented synthesis. Cost: about $0.01 per query for claude-haiku-4-5, which is the one place we use Haiku — citation retrieval is mechanical and the failure mode is observable.

A typical client probe set: 20 canonical queries per property, 4 engines, run weekly = 80 probes per week per engine = 320 probes per week per property. At average cost per probe of about $0.007, a year of measurement runs roughly $120 per property. The cost is not the bottleneck.

What to capture per probe

For every probe, capture:

• Engine identity and model version. Engines rotate models; capture the version string.
• The original query. Without this you cannot reproduce.
• The full response text. Synthesis quality drifts over time; you need the raw text.
• The full source list with URLs and titles. The citation list is the primary signal.
• The rewritten queries where the engine exposes them (Perplexity, sometimes others).
• The position of any of your URLs in the source list, if present.
• A timestamp, ISO 8601, UTC. No probe is useful without it.
• The prompt hash for reproducibility, if you have programmatic prompt construction.

Store these in a structured time-series store. Supabase, BigQuery, or a flat S3 bucket with parquet partitions all work. The query patterns you will run later are: per-engine trends over time, per-query citation persistence, share-of-voice movement across competitors.

The query inventory

The queries you probe matter more than the probing infrastructure. A good query inventory has three layers.

Brand queries — 10 queries that explicitly name your brand or its products. “Tell me about [brand],” “Is [brand] reputable,” “What are [brand]’s pricing tiers,” “Has [brand] been in any controversies recently,” etc. These measure λNPS directly (Chapter 25).

Category queries — 6 queries that name your category without your brand. “Best [category] for [use case],” “[Category] alternatives to [incumbent],” etc. These measure category citation share.

Long-tail queries — 4 queries that probe specific capabilities, niches, or use cases. These measure depth and slot-coverage; they are the most volatile but also the most diagnostic.

Pin the inventory once per quarter. Changing the query set between probes destroys comparability. Add to the inventory, do not rotate.

The passive-log layer

Active probes give you a view from outside. Passive log analysis gives you a view from inside: which AI engines actually fetched your content, when, against what URLs, at what frequency.

Pull your CDN or origin logs filtered by known AI bot user-agent patterns. The list to filter on is the same one your robots.txt allows: GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-Web, Claude-User, Claude-SearchBot, anthropic-ai, PerplexityBot, Perplexity-User, Google-Extended, GoogleOther, Applebot, Applebot-Extended, Meta-ExternalAgent, Bytespider, Amazonbot, CCBot, cohere-ai.

For each fetch, capture: bot identity, URL fetched, HTTP response code, response size, response time, timestamp. Aggregate by week, by engine, by URL. The picture that emerges: which engines are crawling you most aggressively, which pages they prioritize, how their crawl pattern is shifting over time.

Cross-reference with the active-probe data and you can begin to see the relationship between retrieval volume and citation outcome. Pages with high AI fetch volume and low citation are pages the engines are retrieving but failing to lift — usually a parsing or passage-clarity problem. Pages with low AI fetch volume and any citation are pages the engines have decided are worth pulling on every relevant query — high-value, defend at all costs.

The cadence

Active probes weekly. Passive logs reviewed weekly, aggregated monthly. Client-facing report monthly with quarterly comparisons. Year-over-year movement reported at quarter-end with the full 4-model median dataset attached.

Weekly is high enough to catch movement; quarterly comparisons stabilize the trend against short-term noise. Resist the urge to react to single-week movement; one week of variance is almost never a signal, no matter how dramatic it looks.

Attribution Without a Referrer

The AI synthesis layer breaks the referrer-based attribution model that powered a quarter-century of web analytics. The replacement is a graph of co-citation and entity co-occurrence, reconstructed from the data you can collect, not the data the engine sends you.

The referrer is dead, mostly

Web analytics has always depended on the Referer header (yes, misspelled, since 1996) to attribute traffic. The user clicked from somewhere; the browser tells you where; analytics decomposes the traffic by source. The model works because the browser is honest about the prior page.

AI search breaks this in two ways. The first is that most engines do not pass meaningful referrers. ChatGPT’s click-through traffic often arrives with a generic chat.openai.com referrer that loses the query context. Claude’s click-through is similar. Google AI Mode click-throughs sometimes arrive with the standard Google referrer pattern, but the underlying AI-search session is hidden.

The second is that most AI-influenced sessions never click through at all. The user gets the synthesis, accepts the answer, and never visits your site. The session is invisible to your analytics in the way a SERP impression with no click is invisible — except that under SEO you had Search Console, and under AI search you do not.

The conclusion is not that attribution is impossible. The conclusion is that referrer-based attribution captures a vanishing fraction of AI-influenced sessions, and the right model is co-citation and entity co-occurrence rather than click-source.

Query perturbation, revisited as attribution

Chapter 8 introduced query perturbation as a fan-out-measurement technique. The same technique doubles as an attribution technique. Take your priority queries, generate the perturbation set, run them through the engines, and observe which of your URLs appear in which sub-queries. The pattern that emerges is a co-citation graph: which competitor URLs frequently appear alongside yours, which authoritative sources you are co-cited with, which sub-query branches you reliably win and which you reliably lose.

The graph is not a referrer report; it is a competitive intelligence report. It tells you which competitors are in the synthesis with you, which queries are owned by an incumbent you cannot displace, which queries are contested and worth investing in, and which entity co-occurrences are driving cross-query retrieval eligibility.

Entity-query co-occurrence as the strategic surface

The deeper attribution model: entities, not keywords, determine cross-query retrieval eligibility. If your brand is well-aligned in entity space with “CRM,” you become eligible to surface across hundreds of CRM-adjacent queries. If your brand is poorly aligned in entity space — for instance, your knowledge-graph entry is sparse, your sameAs anchors point nowhere useful, your category positioning is muddled — you are eligible for fewer queries.

The actionable construction: an entity-query co-occurrence matrix. Pick the 50 most important queries in your category. Identify the named entities (people, organizations, products, categories, locations) that appear in either the queries or the typical synthesis answers. Probe each query, capture which entities the engine retrieves alongside, and assemble the matrix.

The matrix tells you which entities are driving citation eligibility across which queries. If your category’s eligibility is driven by 12 named-entity anchors and your structured data only references 4 of them, you are leaving citation surface on the table.

Bridge entities and multi-hop reasoning

Some entities appear in many queries; others appear in few. The interesting ones are bridge entities — entities that connect otherwise-disconnected query clusters. A bridge entity that links your category to a high-volume adjacent category is a lever you can use to expand citation eligibility across the bridge.

Example: in the CRM category, “HIPAA compliance” is a bridge entity that connects general-CRM queries to healthcare-vertical queries. A CRM vendor that explicitly names HIPAA compliance with structured data and citation surface becomes eligible to surface in both clusters. The vendor that does not is competing only in the general CRM cluster.

Bridge entities are the single highest-leverage strategic decision in entity architecture. Identify them, document them, ensure your content addresses them with proper structure, and you expand your citation eligibility surface by a multiple.

Storing it — flat tables and graph databases

For most teams, the practical storage shape is flat: a wide time-series table of (probe_id, engine, query, timestamp, cited_url, position, co_cited_urls, named_entities). Query it with whatever your team already uses; the analysis patterns are not exotic.

For teams that want to take the entity-graph work further, a graph database (Neo4j, ArangoDB, or a managed equivalent) lets you traverse co-citation relationships at scale. The discipline is real and the operational overhead is real; we typically recommend it only for clients who are running multi-brand portfolios or competitive intelligence as a primary use case.

The takeaway for client reporting

Stop pretending you can do referrer attribution on AI traffic. The honest client report names what you can and cannot measure, and reports the co-citation and entity-occurrence picture instead. The picture is more useful than the referrer would have been, because it captures competitive positioning, eligibility, and slot ownership directly. The referrer told you who clicked. The co-citation graph tells you who you are competing with for influence.

Simulating Retrieval Before You Publish

Waiting for live engines to tell you whether your content works is a slow, expensive feedback loop. Local retrieval simulation compresses the loop from weeks to hours and becomes a genuine competitive advantage for any team that builds it.

The case for simulation

The default publishing loop in AI search is: write content, ship it, wait for engines to crawl, wait for engines to index, wait for fan-out to surface the content in synthesis, run probes, measure citation. The loop runs four to eight weeks for any single piece of content. If you find out at the end that the content underperforms, you have spent a quarter to learn something simulation could have told you in an afternoon.

Simulation does not predict citation perfectly. It predicts retrieval-system behavior under controlled conditions: given a corpus, given a query, given an embedding model, which chunks does a retrieval system surface? Given a candidate passage, does it survive cross-encoder reranking against the query? Given a synthesized answer, does the model cite the passage you wanted cited?

None of these answers are guaranteed to transfer to a production engine, because production engines layer additional retrieval signals, business logic, and personalization on top. But the directional signal is reliable enough to function as a publishing gate: content that fails simulation rarely succeeds in production.

The minimal simulation stack

You can build a working simulation environment in a week.

Corpus. Either your own site, indexed and chunked, or a corpus of competitor and authoritative-source pages on your topic. Chunking strategy: 200–500 tokens per chunk, with 50-token overlap, respecting passage boundaries (paragraph or heading breaks) where possible.

Embedding model. OpenAI text-embedding-3-large (or text-embedding-3-small for cost reasons), Cohere embed-v3, or Google text-embedding-005 are all reasonable. Use the same model for chunks and queries.

Vector store. A managed vector DB (Pinecone, Weaviate, Qdrant Cloud) or a local FAISS / pgvector instance. The choice is operational, not architectural.

Reranker. A cross-encoder (Cohere rerank-v3, BGE-reranker-large, or Voyage rerank-2) applied to the top-K retrieved candidates. This step is what brings simulation closer to production behavior.

Synthesis model. Any of the major LLMs with a basic RAG prompt. The synthesis model is mostly there to expose how a generation layer would assemble the retrieved passages; it does not need to be the same model the production engines use.

Query set. Your canonical 20-query probe inventory from Chapter 13, plus synthetic perturbations for each.

What simulation tells you

The output of running a piece of candidate content through simulation:

• Did your passage retrieve? Either it appeared in the top-K for the relevant query, or it did not. If it did not, the content is in the wrong embedding neighborhood.
• Did your passage survive reranking? Top-K retrieval is not citation; the cross-encoder rescores the candidates. A passage that retrieves but fails to rerank is a passage with relevant tokens but unclear claim structure.
• Was your passage selected by the synthesizer? Even when the passage survives reranking, the synthesizer may choose a competitor passage. Diagnose by comparing your passage to the chosen passage on the standard dimensions: clarity, named subjects, citation surface, quantitative claims, freshness.
• Where in the synthesized answer did your content land? First paragraph citation is much more valuable than a footnote in the source list.

Synthetic query fan-out for pre-publication

Before publishing a piece of content, generate the likely fan-out tree it should win. The technique: take the seed query the content is built for, prompt an LLM to generate 20–30 sub-queries that a retrieval system might plausibly fan out into. Run each sub-query through your simulator. For each, check whether your candidate content surfaces.

The output is a fan-out coverage map for your content: which sub-queries it wins, which it loses, and which competitor content wins the ones it loses. The losing sub-queries are the content gaps; the winning competitor content tells you what the gap looks like.

This is the discipline that separates good GEO content production from speculative GEO content production. Every piece of content ships with a defensible expectation about which sub-queries it should win, and a measurement plan for verifying.

Hallucination testing

The other use of simulation is hallucination testing. Run the same query through multiple LLMs (without retrieval), capture the answers, and check whether the un-grounded synthesis is consistent with what the engines produce in production. Discrepancies are diagnostic: where the un-grounded synthesis disagrees with production, the engines are correcting via retrieval; where they agree, the engines may be relying on training data rather than retrieval.

For your own brand, this surfaces the λNPS / µNPS gap (Chapter 25): the engines are saying things about your brand that the corpus does or does not justify. Either way, the information is actionable.

What simulation cannot do

Simulation does not predict the personalization layer in production engines. It does not capture the engine-specific reranking that uses signals (user history, query history, geographic context) you cannot observe. It does not capture the citation-selection model that decides which retrieved sources to attribute in the synthesis.

It does not need to. The use of simulation is to filter out content that has no chance of working in production, and to identify content gaps before publishing. Used that way, it pays for itself within the first quarter of any serious GEO program.

The Team You Need Now

GEO is an engineering discipline that uses content as its primary artifact. The team you need looks more like an internal information-retrieval team than a content-marketing team, and very little like a classical SEO team.

What the classical SEO team is missing

Classical SEO teams are built around a content-and-link practice with technical hygiene support. The skills inventory: keyword research, content brief authoring, copy editing, technical SEO (sitemap, robots, schema, internal linking), link acquisition, ranking-tracking analytics. The shape works for SEO because the discipline is fundamentally about identifying queries and producing content that ranks for them.

GEO is not that discipline. The skill gaps that classical SEO teams hit, in order of frequency:

• Retrieval architecture literacy. Most SEOs cannot reason about embedding space, retrieval-reranker pipelines, or chunk-level extraction without conceptual support. The shift from “rank” to “retrieve and synthesize” lands as a meaningful re-education, not a vocabulary update.
• Telemetry construction. Building active-probe pipelines, parsing CDN logs for AI bot UAs, constructing co-citation graphs, querying time-series stores — these are engineering skills that classical SEO teams do not have on staff and have not historically needed.
• Simulation operations. Standing up a vector store, running retrieval-simulation gates against candidate content, debugging when simulation results contradict production results — these are ML-engineering-adjacent skills.
• Structured-data craft beyond rich-result eligibility. Schema for citation is a different discipline than schema for SERP enhancements. Many SEOs treat schema as a checkbox; GEO needs schema as a deliberate semantic anchoring strategy.
• Multi-engine measurement discipline. Four engines, four methodologies, distributional metrics, outlier-drop logic. Most SEO teams have not had to think distributively because Search Console gave them point estimates.

The skill mix that does work

The team shape we see succeeding looks like this. (Sizes scale with the property; we are describing roles, not headcount targets.)

A relevance engineer who owns the simulation stack, the embedding analyses, the chunk-level rewriting work, and the structured-data architecture. This is a hybrid role: half technical SEO, half ML-engineering-adjacent. Often hired out of technical SEO and trained up; sometimes hired out of ML engineering and trained down on the SEO context.

An editorial lead who owns the information-gain agenda — what original research, primary data, and operating receipts are produced per quarter. This role is closer to a senior journalist or a research-program manager than to a content marketer. Their KPI is not content volume; it is information-gain density per published unit.

A measurement engineer who owns the telemetry — active probes, passive logs, co-citation graphs, the dashboards. In smaller teams this collapses into the relevance engineer; in larger teams it is a discrete role with a data-engineering toolkit.

An entity / structured-data specialist in larger teams — someone who owns the entity model, the sameAs anchoring, the Knowledge Graph alignment work, and the citation-property maintenance. Smaller teams collapse this into the relevance engineer.

Cross-functional touch points with brand, PR, product, and engineering — because the off-property signals (digital PR, Wikipedia presence, primary research citation) require partnership outside the GEO team itself.

The transition path from SEO team to GEO team

For teams transitioning rather than hiring net new, the order of operations:

1. Re-educate on retrieval fundamentals. The whole team needs working literacy in retrieval architecture, embeddings, and the fan-out model. A one-week curriculum suffices for the conceptual layer; the operational layer compounds over months of practice.
2. Hire or train a relevance engineer. This role is the keystone. Without it, the team continues to operate as an SEO team with new vocabulary.
3. Stand up the measurement stack. Active probes, passive logs, basic dashboards. Six weeks of focused engineering.
4. Restructure the content pipeline. Information-gain agenda, slot-coverage briefs, simulation gating. This is mostly a process change, not a tooling change.
5. Audit and rebuild structured-data architecture. Schema type breadth, sameAs anchoring, citation properties.

The checklist culture has to end

Classical SEO accumulated, over twenty years, a folk-wisdom corpus of “best practices” that operated as a checklist: title-tag length, H1 uniqueness, meta description presence, breadcrumb schema, image alt text, sitemap freshness, canonical-tag consistency, page-speed targets, mobile-responsive layout, and so on. Most of these were correct directionally; many were over-stated in importance; some were cargo-cult from a prior era of search.

GEO is too early to have accumulated a credible folk-wisdom corpus. Anyone telling you they have a 47-item GEO checklist is selling certainty they have not earned. The discipline is to run experiments, measure the outcomes, and iterate — not to ship a checklist and call it done.

Choosing Vendors in a Category That Did Not Exist

The vendor selection criteria for AI search are the inverse of the criteria you used for classical SEO. The vendors who pitched you on ranking guarantees are the wrong vendors; the vendors who pitch you on measurement infrastructure and engineering depth are the right ones.

What disqualifies a vendor immediately

Three things should end the vendor conversation in the first meeting.

Ranking guarantees. No serious AI-search vendor can guarantee citation outcomes. Engines update, fan-out shifts, the synthesis layer is probabilistic. A vendor offering a guarantee is either misunderstanding the discipline or knowingly selling a guarantee they cannot deliver. Either is disqualifying.

Single-engine focus. A vendor whose pitch is “optimize for ChatGPT” or “rank in Google AI Overviews” is selling a single-engine tactic. The clients who buy this end up with measurement infrastructure they cannot extend, blind spots on the engines the vendor does not measure, and a competitive position that depends on a single engine’s product roadmap.

Content production at scale without retrieval discipline. A vendor pitching “100 AI-generated articles per month optimized for GEO” is pitching content scaling as a GEO play. The math on information gain (Chapter 11) tells you this does not work. The clients who buy this end up with a content liability, not a content asset.

What qualifies a vendor

A few things mark a vendor as worth a real conversation.

Multi-engine measurement. Can they show you, on a real client property, what their measurement output looks like across at least four engines? Do they use distributional metrics? Is the cross-engine methodology defensible?

Retrieval-architecture literacy. Can they explain, in technical detail, how each engine’s retrieval pipeline works and how their interventions interact with each? If the vendor cannot distinguish between Perplexity’s hybrid retrieval and ChatGPT’s on-demand fetcher, they are not the vendor.

Original measurement methodology. Have they published, somewhere, their methodology for measuring the things they claim to improve? If their methodology is proprietary and unverifiable, treat it as marketing rather than measurement.

Engineering depth. Can they ship the infrastructure (translation layer, telemetry, simulation gates) themselves, or are they reselling tooling and adding interpretation? Resellers are sometimes the right choice for small properties; for any property where the infrastructure becomes load-bearing, you want the team that ships the infrastructure.

A defensible position on the controversies. Do they have a view on llms.txt? On Google-Extended? On AI-generated content? On Profound vs. their own measurement stack? Vendors without strong positions are vendors who have not thought carefully about the discipline.

The category landscape

The vendor map is small but real. We treat these as peers, not as competitors-to-beat-on-every-axis.

iPullRank — Mike King’s shop, the most substantive technical-SEO-and-LLM-retrieval agency in the category. The reference name for serious GEO work in the agency tier. We disagree with them on a few specifics (llms.txt, Google indifference to AI content, the optimistic read on agent scaling), but they have earned the seat at the table.

Profound — pure-play AI-search-visibility measurement. Strongest panel-derived data in the category. Not full-service; you still need an agency or in-house team to act on what they measure.

Conductor, BrightEdge — enterprise SEO platforms with AI-search modules bolted on. Useful if you are already on their platforms; not category-defining.

Brafton, Seer, iCrossing, Jellyfish, Wpromote, Croud, Searchmetrics, and the other enterprise SEO shops — have mostly rebranded with GEO positioning. Credible at SEO; the actual GEO deliverables vary widely, and the published positioning frequently outruns the engineering depth.

Contracting structure

The retainer-based, ranking-driven contracts that financed classical SEO do not translate well to GEO. Three contracting patterns we see working.

Quarterly outcome targets against defensible metrics — ASQ™ movement, λNPS trajectory, QFS on priority slots — with the methodology and data publicly attached to every report. Replaces the “rank in the top three” target with something measurable in the new regime.

Infrastructure project pricing for the translation-layer cutover, telemetry stand-up, simulation gating, structured-data overhaul — treated as one-time engineering projects with deliverables and acceptance criteria, not as ongoing retainers.

Ongoing measurement-and-iteration retainers for the quarterly rebound work — running probes, updating slot inventories, shipping content fixes against gaps, refreshing the dashboards. Smaller than the legacy SEO retainer; more defensible per dollar.

Slop, Authority, and the Information-Gain Premium

Machine-generated content is poisoning the public corpus at scale. The right response is not detection; detection does not scale. The right response is to publish content with such high information-gain density that the systems have no plausible substitute.

The slop reality

Across every category we measure, the volume of AI-generated content published per quarter is rising faster than the volume of human-authored content. In most categories, the AI-generated content is now the majority of newly indexed material. The pattern is not subtle; it is observable in any sustained corpus analysis.

The quality of the AI-generated content is, on average, surface-coherent and substance-thin. It rephrases existing material rather than introducing new material. It cites either nothing or other AI-generated material. It rarely contains original data, named outcomes, or first-person operating receipts. As a result, it generates a lot of corpus volume without adding much corpus information.

The signal-to-noise ratio of the public web is degrading. The cited statistic — AI Overviews cutting CTR from 15% to 8%, with citation clicks down to 1% — is part of a larger pattern in which publishers are losing the click economy at the same time the corpus they relied on is filling with derivative AI material.

Detection does not scale

One response to the slop problem has been detection: build classifiers that identify AI-generated content and filter it out. The classifiers exist, they work imperfectly, and the arms race is asymmetric. A page that runs through one rewrite-by-AI pass typically slips past detection; pages that are AI-drafted and human-edited slip past trivially. Detection is in a position similar to spam detection in 2005 — useful as a filter for the egregious cases, useless as a structural defense against the well-resourced.

The asymmetry is the strategically important part. The cost of producing slop is near-zero. The cost of detecting it is non-trivial. The cost of human-authored, information-gain-rich content is the highest of the three. The economics structurally favor slop production, which is why the corpus pollution gets worse rather than better.

The information-gain premium

The right response, and the only response that compounds in your favor, is to publish content that is structurally distinct from slop — content with information gain that the slop economy cannot replicate.

What that looks like, operationally:

• Original data. Internal telemetry, surveys you ran, experiments you executed, measurements you took. Slop cannot produce this; slop can only rephrase what already exists.
• Named outcomes. Specific client results, specific revenue movements, specific quantitative deltas with dates. Slop produces generic outcomes; named outcomes mark the content as first-hand.
• Operating receipts. The specific decisions you made, the specific tradeoffs you faced, the specific things that went wrong. Slop produces clean narratives; operating receipts contain the friction that marks authentic expertise.
• Defensible methodology. Named frameworks, explicit measurement protocols, reproducible processes. Slop produces taxonomies; methodology is what people can run.
• Primary-source citations. Links to government data, peer-reviewed papers, regulatory filings, named datasets. Slop links to other slop or links to nothing.

Content with these properties is expensive to produce and impossible to substitute. The retrieval systems weight it high; the synthesis layer cites it preferentially because it has no equivalent to lift from elsewhere; the engine’s training data eventually incorporates it because the alternative is to incorporate the slop.

The E-E-A-T frame, sharpened

Google’s E-E-A-T framework — Experience, Expertise, Authoritativeness, Trustworthiness — was developed for the Quality Rater program in classical search and has been repurposed for AI-search citation guidance. The framework remains useful, with a sharpened emphasis on the first letter.

Experience is the single hardest property for AI-generated content to fake. Expertise can be performed (write knowledgeably about a topic). Authoritativeness can be borrowed (cite credentialed sources). Trustworthiness can be signaled (clean design, transparent authorship). Experience — first-person operating contact with the thing you are writing about — cannot be faked by a model that has never had that contact.

This is why the content-marketing instinct to “cover every angle on every topic” is a losing strategy in the AI-search era. The angles you can cover first-hand are the angles that compound; the angles you can only cover by paraphrasing are the angles that lose to slop.

What this implies for content investment

Stop measuring content production by volume. Start measuring it by information-gain density per published unit and by the count of named outcomes per quarter. A property that ships four deeply researched original pieces per quarter outperforms a property that ships forty rephrased pieces. The math compounds because the four pieces become cited references; the forty pieces become slop the engines route around.

The corollary is that content budgets should shift from production volume to research investment. Surveys, experiments, telemetry, case-study production, primary-source partnerships. The classical SEO ROI math (cost per article, articles per ranking, rankings per traffic) does not survive the transition. The new math is cost per piece of information-gain-rich content, citations per piece, durability of citations over time.

Truth Under Probabilistic Citation

AI engines cite probabilistically and synthesize confidently. The combination produces a class of failure — confident citation of inaccurate representation — that is structurally invisible to the user and structurally damaging to the brand being misrepresented.

Hallucination is a category, not a glitch

The conventional framing treats hallucination as an occasional model glitch — the system fabricated a citation, attributed a quote to the wrong author, invented a statistic. Treating it as a glitch implies the fix is iterative improvement on a known class of error.

The honest framing is that hallucination is a structural property of generative architectures, not a bug being eliminated. The hallucination rate of frontier models has not monotonically improved with model scale; some published benchmarks show the rate increasing with reasoning-tuned models that perform more inference per output token. The point is not to celebrate the problem; the point is that hallucination is the operating environment, not the deviation.

For a brand, the relevant failure mode is not the spectacular hallucination (the made-up quote, the fabricated statistic). It is the quieter pattern: the engine cites your page but synthesizes a claim about your brand that your page does not support. The user accepts the synthesis confidently because the citation is present. The brand is misrepresented to a user who has no easy way to verify.

Citation without accuracy — the named failure mode

We call this citation without accuracy, and it is the failure mode every monitoring program should foreground. The engine cites a source; the synthesis claims something the source does not say; the user reads the citation as endorsement of the claim. Three patterns we see routinely.

Old data presented as current. The engine retrieves a page from 2021, cites it accurately, and synthesizes a claim presented in present tense. The user has no signal that the data is four years stale.

Decontextualized quotes. The engine pulls a phrase from a source where the surrounding paragraph qualified or reversed it. The synthesis carries the phrase without the qualifier. The cited source “said” something it did not actually claim.

Adjacent-source attribution. The engine knows a fact from training data and cites a source that is topically adjacent but does not actually contain the fact. The user verifies the source exists, sees it is relevant-looking, and trusts the synthesis.

Each of these is structurally hard to catch from outside the engine. The user does not run the verification; the analytics do not log the misrepresentation; the brand does not know it happened.

Defensive content engineering

The defenses against citation-without-accuracy are mostly content-engineering interventions on your own side.

Inline dates on every quantitative claim. “In Q1 2026, AnswerShare clients saw a median 47-point GEO improvement” resists being presented as a current claim in 2029. Undated quantitative claims age silently.

Explicit qualifiers attached to the claim itself. “In sites with existing TTFB below 200ms, the additional 30ms latency of the Translation Layer™ is imperceptible” resists decontextualization in a way that “the latency is imperceptible” does not.

Source citations adjacent to claims, not in a separate references section. The engine extracts passages; if the citation is across the page, it does not always survive extraction.

Author bio and structured-data authorship. Pages with named authors and proper authorship schema get cited with more attribution. The author becomes part of the citation surface and gets weighted as a credibility signal.

Transparency hubs. Pages that explicitly document your methodology, your data sources, your update cadence, and your factual claims provide a citation surface the engines reach for when synthesizing factual claims about your brand.

The brand-monitoring program

Every serious brand should run a citation-accuracy monitoring program. The mechanics:

• A canonical query set of brand-explicit queries (Chapter 13’s brand-query layer).
• Probes across four engines, weekly, with full response capture.
• A human review on a sample (we recommend 20% sampling rate, or full review for high-stakes brands) checking the synthesis for factual accuracy against the brand’s own canonical claims.
• An escalation path for material misrepresentations — either content corrections on your own property (to surface the canonical answer) or, for severe cases, direct contact with the engine’s feedback channels.

This is not litigation; it is operational hygiene. The engines update their training data, refresh their indices, and respond (slowly, imperfectly) to feedback. Brands that monitor see misrepresentations get corrected over quarters; brands that do not monitor watch the misrepresentations compound.

The Next Five Years of Discovery

The shape of AI search five years out will be more multimodal, more agentic, more memory-bearing, and more deeply integrated into productivity surfaces than search has ever been. The optimization discipline that compounds is the one that builds toward all four trends simultaneously rather than betting on one.

Four trajectories that are already in motion

Multimodality. Discovery surfaces are absorbing image, video, audio, and structured-data inputs as first-class query modes. Google Lens has been the leading wedge for years; Apple’s Visual Intelligence, Meta’s Ray-Ban camera assistants, ChatGPT’s vision tier, and Gemini Live are all building toward a world where the user points a device at something and asks about it. The implication for content: brands whose content is text-only are competing in a narrowing fraction of the discovery surface.

Agentic execution. The next product layer is not “the assistant answers your question” but “the assistant does the thing.” OpenAI’s Operator, Google’s Project Mariner, Anthropic’s computer-use Claude, and the dozen smaller agentic frameworks are converging on a model where the user describes an outcome and the agent executes the steps. The implication for content: your content needs to expose structured affordances (canonical pricing, canonical booking endpoints, canonical product specifications) that an agent can act on without human disambiguation.

Persistent memory. ChatGPT’s memory, Claude’s Projects, Gemini’s memory, and Perplexity’s Spaces are all building user-level memory that compounds across sessions. The implication for content: your brand needs to be present consistently enough that the assistant remembers you correctly. A brand that is cited inconsistently is a brand the memory layer records inconsistently.

Ambient integration. Microsoft Copilot in Microsoft 365 is the largest single example: AI assistance embedded in the productivity surfaces 450 million users already live in. Google’s Workspace integrations are similar. The implication for content: discovery is increasingly happening inside applications where there is no traditional “search” surface to optimize for; your content needs to be present in the corpora those embedded assistants consult.

What does not change

The temptation in the “future of search” chapter is to predict things that change everything. The honest reading: most of the discipline does not change as much as the headlines suggest.

Retrieval still happens; the engines still need to find your content. Structured data still anchors entity identity; sameAs still connects entities to canonical references. Information gain still wins citations; slop still loses to operating receipts. The 9-Dimension GEO Rubric (Chapter 26) is still a usable diagnostic in 2030 because the dimensions describe properties of the content itself, not properties of any particular engine’s 2026 retrieval pipeline.

The dimensions whose weights shift over the next five years: more emphasis on multimodal coverage, more emphasis on structured affordances for agentic execution, more emphasis on entity-graph alignment for memory-layer consistency, more emphasis on AI-discoverable freshness signals as ambient assistants pull more often than crawl-based engines. The framework holds; the weights move.

Bets that are likely to pay off

Video-content unlock. Video remains opaque to retrieval by default. Brands that systematically transcribe, structure, and surface their video content (Chapter 23) capture a content surface that competitors are leaving unindexed.

Agent-callable endpoints. Brands that expose structured product, pricing, and booking endpoints via well-formed MCP servers (Chapter 21) become eligible for agentic-commerce surfaces in a way that competitors with HTML-only product pages do not.

Entity-graph cleanup. Brands that invest in Wikidata presence, Wikipedia stewardship, and aggressive sameAs anchoring see compounding returns as memory layers consult these canonical sources more heavily.

Multi-engine measurement infrastructure. Brands that own their measurement stack are positioned to adapt as engines change weights; brands that depend on platform-supplied analytics are at the mercy of whatever the platform decides to expose.

Bets that are likely to disappoint

Voice search optimization as a discrete discipline. “Voice search” was a discipline for half a decade and never quite materialized as distinct from regular search. The same is likely true for “agent optimization” as a discrete discipline; what works for agents is largely what works for retrieval generally, plus structured affordances for action.

AR / glasses-based search as a near-term volume channel. The hardware will ship; the volume will lag. Optimizing for an interface that has not crossed adoption thresholds is premature for most brands.

Speculative bets on which engine will win. The honest reading is that the four major engines all persist five years out, that none of them dominate the way Google dominated SEO, and that the right strategy is multi-engine coverage rather than single-engine betting. Brands that pick a winner early and optimize narrowly will look smart in some quarters and stupid in others.

Agentic Commerce

Commerce is transitioning from human-mediated discovery to agent-mediated transaction. The product content that wins is the content that exposes structured affordances an agent can act on without disambiguation.

The shape of the shift

For most of the e-commerce era, the user discovered a product through search or browse, evaluated it on a product detail page, and transacted on a checkout flow that was tightly controlled by the merchant. Each step gave the merchant control: SEO into the discovery step, content into the evaluation step, conversion design into the checkout step.

Agentic commerce dissolves the steps. The user describes an outcome (“buy me a four-person tent under $400 with a waterproof rating above 3000mm, ships by Friday”). The agent runs the discovery, evaluates against the constraints, selects a product, and executes the purchase. The merchant’s control surface shrinks from three steps to one input: the structured data the agent reads when evaluating.

Two protocols have emerged as the early infrastructure. Google’s Universal Commerce Protocol (UCP) and OpenAI / Anthropic’s Model Context Protocol (MCP) extensions for commerce, plus OpenAI’s Agentic Commerce Protocol (ACP). They are not interoperable in spirit; they describe overlapping but not identical merchant integrations.

What the agent actually needs from your content

An agent evaluating a product needs structured answers to roughly twelve questions: what is the product, what are its quantitative specifications, what is the current price, what is the availability, what are the shipping options, what are the return policies, what are the relevant compatibility constraints, what are the warranty terms, what are the typical use cases, what are the reviewer-reported strengths, what are the reviewer-reported weaknesses, and what are the alternatives in the same category.

Pages that answer all twelve questions in structured form — either through schema.org Product / Offer / AggregateRating / Review properties, through MCP-callable endpoints, through ACP feed entries, or through some combination — are pages the agent can evaluate. Pages that answer some in structured form and require human inference for the rest are pages the agent treats as half-evaluable and frequently passes over.

Feed resonance — the marketing dimension that survives

Agents do not respond to brand voice the way humans do, but they do respond to structured signals that capture brand position. The concept of feed resonance — structured product descriptions that explain the why, not just the spec — is the form of brand voice that survives the transition. A product feed that says “designed for ultralight backpackers prioritizing weight over durability” gives the agent a position it can match against the user’s implied criteria. A feed that says “the best tent on the market” gives the agent nothing.

This is one of the few places where editorial discipline directly drives commercial outcome in the agentic-commerce era. The merchants that invest in defensible feed copy — specific positioning, named tradeoffs, explicit constraints — capture agent selections that less disciplined competitors lose.

The UCP / ACP / MCP landscape

The protocol layer is consolidating but is not consolidated. A pragmatic posture:

• Maintain a clean Schema.org Product / Offer / AggregateRating stack as the floor. This serves every retrieval system, all protocol layers, and the classical SEO surface simultaneously.
• Adopt UCP for the Google surface as the dominant commerce-discovery layer matures.
• Adopt MCP server endpoints for product, pricing, availability, and order placement where your engineering bandwidth supports it. MCP is the cross-platform protocol most likely to compound; Anthropic, OpenAI, and Google have all converged on it as the standard for tool-callable interfaces.
• Adopt ACP for the OpenAI surface as the agentic-commerce volume there crosses thresholds that justify the integration work.
• Do not pick a single protocol and bet exclusively on it. The merchants that lock into one protocol either spend years explaining why their products do not appear elsewhere or rebuild integrations under deadline pressure.

The merchant-of-record question

UCP centers the merchant of record — the brand whose payment processor, returns policy, and customer relationship govern the transaction. ACP, in the OpenAI implementation, allows for arrangements where OpenAI mediates the transaction and the brand becomes a fulfillment partner. The strategic implication is significant: in the UCP model, the merchant retains the customer relationship; in the ACP model, OpenAI does.

Different merchants will make different calls here. Premium brands with strong customer loyalty will fight to retain the relationship; commodity products will accept disintermediation in exchange for the volume. We do not have a single recommendation; we recommend that every merchant decide explicitly rather than accept the default of whichever protocol they integrate with first.

Quantifying the shift

The trailing data is consistent with rapid mainstreaming. Consumer surveys put AI-assisted shopping engagement above 50% of US shoppers using AI at least once a week for purchase research. Google’s commerce API token usage has scaled an order of magnitude year over year. ChatGPT’s shopping-mode usage has materially exceeded what its product team forecast. The transition is not theoretical.

What is still uncertain: how the transaction economics split between merchants, agents, and the platforms hosting the agents. The historical equivalent is the marketplace-versus-brand-direct tension that shaped e-commerce since 2010; the agentic-commerce version of that tension is starting to play out now and will define the commerce economics of the late 2020s.

Local Search After Proximity

Local search has stopped being about proximity and started being about trust-weighted, multi-source citation aggregation. The business that wins is the one whose presence corroborates across review, directory, map, and owned-content surfaces.

The proximity assumption is gone

Classical local SEO ran on three pillars: Google Business Profile completeness, on-page local signals (NAP consistency, locally relevant content), and review volume. Distance from the user’s location was the dominant ranking factor; everything else was a tiebreaker.

AI-mediated local search reweights this dramatically. The user asks for “the best vegan brunch near me with good outdoor seating and reasonable wait times.” The engine fans out: vegan brunch in the metro, outdoor seating filters from review surfaces, wait-time signals from review text mining, ambient personalization based on prior preferences. The geographically closest option may not appear at all if its reviews are mediocre, its photo set is thin, or its hours are not current. A restaurant fifteen minutes farther away wins on the strength of corroborating signals across multiple source categories.

The four-source corroboration model

The most useful framing we have found for local AI-search optimization is the four-source corroboration model. Each source category does a different job; the business that wins is corroborated across all four.

Review surfaces (Yelp, Google Reviews, TripAdvisor, OpenTable, niche category review sites). Job: provide subjective qualifiers — "great service," "kid-friendly," "fast delivery," "good for vegetarians." AI engines mine review text aggressively for these qualifiers and use them in filtering. Optimization: encourage reviews that name specific qualifiers, not generic ratings; respond to reviews in a way that names the qualifier in your reply.

Directory surfaces (Yellow Pages, Yelp business, Bing Places, niche directories). Job: provide category placement and canonical NAP. AI engines use directories as cross-reference for entity-level identity. Optimization: ensure category placement across the major directories is consistent and that NAP matches exactly.

Map and location surfaces (Google Maps, Apple Maps, Yelp map view, Foursquare for vertical apps). Job: provide the location anchor, hours, and visual context (photos, street view). AI engines weight maps surfaces as the authoritative source for location facts. Optimization: claim and complete every relevant maps entry, keep hours current, upload regular photo updates.

Business website (your own property). Job: provide objective facts and structured data — menu, pricing, services, owners, certifications. AI engines pull from owned content for the structured-data layer that maps does not provide. Optimization: clean LocalBusiness schema with full property completion, named services with pricing where appropriate, FAQ schema for common questions, citation surface for any claims (awards, certifications, regulatory approvals).

Probabilistic relevance — the four-factor model

For any given local query, four factors determine whether your business surfaces in the AI synthesis: the question (what the user is asking), the context (what conversation state preceded the question), the location (still a factor, just not the dominant one), and the model (which engine, which retrieval pipeline). Each factor weights differently per engine; the discipline is to optimize for the cross-engine average rather than for any single engine’s configuration.

Blocking AI bots kills local visibility

A surprisingly common pattern in local-business sites: robots.txt blocks all unfamiliar user agents, which now includes most AI search bots. The owner believes they are protecting their site from scraping; what they are actually doing is removing themselves from the conversation. AI engines that cannot fetch the site cannot synthesize from it, and the business loses to competitors whose sites are accessible.

The defensive instinct is understandable. Several engines have had bad press around scraping behavior, training-data sourcing, and copyright lawsuits. The pragmatic answer remains: for any local business whose customers are increasingly discovering via AI, the visibility cost of blocking exceeds the speculative protection. Allow the bots; control what is published (the Translation Layer™ bot view, if the client wants it); monitor what gets synthesized.

The contextual-filtering effect

The dimension of local AI search that surprises clients most: contextual filtering kills businesses that fail the filter regardless of how close they are. A user with dietary restrictions in their conversation history will not be recommended a restaurant whose menu schema does not address those restrictions, even if it is the closest option. A user with a stated budget constraint will not be recommended an option whose pricing does not surface in structured data, even if the unstructured pricing on the website would have satisfied the constraint.

The practical implication: every meaningful filter axis (dietary, accessibility, price range, hours flexibility, family-friendliness, dress code, payment options, language support) that buyers in your category use should be addressable through your structured data. The schema work is mechanical; the strategic work is identifying which filters matter in your category.

Video as the Default Source

Video has stopped being an adjacent channel and become central to AI search. YouTube alone produces a disproportionate share of AI Overview citations and the only retrieval-eligible video corpus that matters at scale. Brands without video are losing a slot they do not see.

The structural fact

Across the major engines that consult video, YouTube is the overwhelmingly dominant source — in our measurements, two orders of magnitude ahead of every other video platform combined. Vimeo, Wistia, Brightcove, and the rest are functionally absent from AI synthesis when video is consulted. The reasons are infrastructure (YouTube transcripts are accessible, embedded, and machine-readable at scale) and behavior (the engines have learned that YouTube has the highest signal-to-noise ratio for retrieval).

The implication is unambiguous: if you produce video content and care about AI-search citation, it lives on YouTube. Multi-platform syndication is a separate question for audience reach; for retrieval eligibility, YouTube is the single point of presence.

Transcript optimization is the lever

For video to compete in AI-search citation, the transcript is what the retrieval system reads. Almost everything else (titles, descriptions, thumbnails, tags) matters for in-platform YouTube discovery but is downstream of transcript content for cross-platform retrieval. Three operations make the transcript work.

Auto-generated transcripts are not enough. YouTube’s auto-transcription is decent but routinely mistakes proper nouns, brand names, and technical terms. Every published video should have an uploaded transcript that corrects the auto-transcript’s errors, especially for brand-name and product-name accuracy. The cost of correction is hours; the cost of having your CEO’s name systematically mistranscribed across your video catalog is invisible and compounding.

The first 30 seconds carries disproportionate weight. Retrieval systems treat the opening of the transcript as the dominant signal for what the video is about. Build for it: name the topic explicitly, name the conclusion or central claim, name any quantitative outcomes, name the speakers and their affiliations. The narrative-arc videos that build to a payoff at the end lose to videos that lead with the payoff and unpack the rationale afterward.

Cosine alignment between title, description, and transcript matters. When the title and description embed in a different neighborhood than the transcript, the retrieval system treats the video as having ambiguous topic alignment and downweights it. Coherence across the three surfaces is a free win.

VideoObject schema and the transcript property

Beyond YouTube, the videos you embed on your own site can compete in AI-search if you publish them with proper VideoObject schema and the transcript property populated. Most CMS-driven implementations of VideoObject ship the schema with name, thumbnailUrl, duration, and uploadDate. They almost never ship the transcript. Adding the transcript property to embedded VideoObject schema typically doubles the indexable content of video-heavy pages and is one of the highest-leverage single interventions we ship.

{
  "@context": "https://schema.org",
  "@type": "VideoObject",
  "name": "How the Translation Layer Routes Bot Traffic",
  "description": "A four-minute walkthrough of the edge-routing logic that distinguishes AI bots from search bots and human users.",
  "thumbnailUrl": "https://example.com/thumb.jpg",
  "uploadDate": "2026-04-12",
  "duration": "PT4M18S",
  "contentUrl": "https://example.com/videos/translation-layer-walkthrough.mp4",
  "embedUrl": "https://www.youtube.com/embed/...",
  "transcript": "Today I want to walk through how the Translation Layer routes traffic. When a request arrives at the edge worker..."
}

Which video content wins which retrieval

Not all video query types resolve through video sources. The pattern we observe across engines:

• Tutorials, how-to, demos, walkthroughs. Heavy video consultation. Build video content for these.
• Product reviews, comparisons, unboxings. Heavy video consultation. Build video content for these.
• Long-form interviews, podcasts, panels. Moderate video consultation; the transcript is what drives the citation, and the same content in text form would frequently win the citation if it existed.
• Abstract concepts, strategy, high-level frameworks. Low video consultation; text content wins these.
• Career advice, general professional development. Mixed; depends on the specific query.

Plan the video content investment by the categories that actually consult video, not by what the marketing team is most comfortable producing.

The case for a video roadmap, not a video budget

Most brands that respond to “video matters in AI search” respond with a content budget — commission a dozen videos, post them, see what happens. The better response is a roadmap that aligns video production with the fan-out slots video actually wins.

The roadmap: identify the priority slots in your category that resolve through video consultation (tutorials, comparisons, demos, reviews). For each slot, identify whether your existing content covers it. For each gap, plan video production with the transcript-first discipline above. Measure the resulting citation in the relevant engines after a six-week index lag.

This is a content-roadmap exercise, not a video-budget exercise. Done well, fewer videos with better targeting outperform more videos with diffuse targeting.

From Answers to Actions

The next product layer after AI search is AI action. The discipline of optimizing for retrieval and citation extends into the discipline of being callable, structured, and trustworthy enough that an agent will choose your service to execute the user’s intent.

What is changing

Search systems answer questions. Agentic systems execute tasks. The boundary between them is blurring as the major engines roll out task-execution layers: ChatGPT’s Operator, Gemini’s Project Mariner, Claude’s computer-use mode, Apple’s Intelligence with action chains, Microsoft Copilot’s agent mode in M365.

The user behavior is shifting in parallel. A query like “book me a haircut for Tuesday afternoon at a barbershop with good reviews near work” is no longer a search query expecting a result list; it is an action request expecting an executed outcome. The agent has to discover the candidate set, evaluate against constraints, select, and execute the booking. The merchant whose booking interface is structured, callable, and trustworthy gets the action; the merchant whose interface requires human navigation does not.

The MCP-callable surface

The Model Context Protocol has emerged as the dominant standard for agent-callable interfaces. An MCP server exposes a structured set of tools (functions the agent can invoke), resources (read-only data the agent can consult), and prompts (templates the agent can use to reason about the domain). The protocol is supported by Anthropic, OpenAI, Google, and a growing ecosystem of agent frameworks.

For service brands, the strategic question is whether to expose an MCP server. The answer for most B2B SaaS, professional services, and any business with bookable or transactable interfaces: yes, and the engineering cost is lower than the integration cost of any prior agentic standard.

A minimal MCP server exposes:

• Resources — canonical product catalog, current pricing, current availability, service descriptions. Read-only, agent-consumable.
• Tools — booking, pricing inquiry, availability check, contact, quote request. Action-executable, scoped to safe operations.
• Prompts — canonical descriptions of how to use the resources and tools effectively. Helps the agent reason about when to call what.

The /.well-known/mcp.json file at your root points to the MCP server endpoint. The agent discovers it through the well-known path or through pre-configured integrations.

Automation logic — what belongs to agents, what does not

Not every business process belongs in an agent-callable surface. The pragmatic filter has three questions.

Complexity: does the task require genuine reasoning, or just if-then logic? If just if-then, traditional RPA or an API integration is cheaper and more reliable. Agents earn their cost on tasks that require reasoning across messy inputs.

Data-source diversity: does the task require pulling from multiple structured and unstructured sources? If yes, agents are the right tool. If no, a simpler integration suffices.

Process type: is the process branchy and variable, or is it the same steps every time? Variable processes benefit from agents; deterministic ones rarely do.

For most service businesses, the agent-relevant surface is the discovery-and-evaluation step (which is variable, multi-source, reasoning-heavy) and the booking-or-execution step (which can be either, depending on how complex the booking constraints are). The downstream fulfillment, billing, and customer-service workflows are typically not the right place to put an agent — not yet.

Trust as the new differentiator

When agents have to choose between two equally callable services to execute a user’s task, they choose on trust signals. The trust signals are mostly things classical SEO and trust-and-safety practices have been refining for years: clear identity, transparent pricing, accessible terms, named operators, citation surface, dispute history. The agentic-commerce era reweights them: trust signals matter more than they did when humans were doing the evaluation, because humans had heuristics agents do not.

Brands that invest in canonical trust-surface pages (clearly identified company information, transparent pricing pages, accessible terms-of-service, customer-service contact paths, dispute resolution policies, third-party trust validators like BBB or industry-specific bodies) become preferred candidates in agent evaluation. Brands that obscure these surfaces — in pursuit of conversion optimization or contractual ambiguity — lose agent selections to clearer competitors.

What is overhyped

The “agents at 10 or 10,000 scale without proportional friction” framing oversells. Compute cost is real, governance overhead scales with risk surface, and the reliability of multi-step agent execution remains uneven enough that production agentic systems still require human-in-the-loop checkpoints for most high-stakes tasks. Plan for the agent-callable surface as a meaningful and growing channel; do not plan for it as a friction-free order-of-magnitude business transformation in 2027.

µNPS, λNPS, ΔNPS

How AI engines talk about your brand is now a measurable property of the brand itself. µNPS captures what the public corpus says; λNPS captures what the engines say; ΔNPS captures the diagnostic gap between the two. The optimization target is ΔNPS convergence over time.

The framework, set out cleanly

Three letters, three definitions.

Each is expressed on a standard NPS-like scale (-100 to +100) and is intended to be interpreted the way an NPS practitioner would interpret an NPS score: positive is favorable, negative is unfavorable, mid-zero is neutral.

Why this framework exists

The conventional brand-monitoring stack measures media sentiment, social sentiment, and review sentiment as proxies for what people think about a brand. The proxies were always imperfect, but they worked because the relevant audience — humans — was the same audience producing the corpus.

AI search interposes a transformation layer between the corpus and the audience. The engines read the corpus, train on it, retrieve from it, synthesize over it, and produce outputs that humans then consume. The output is what shapes the audience’s impression of the brand — not the underlying corpus. A brand whose corpus is favorable but whose machine outputs are stale or unfavorable is a brand whose effective reputation has drifted from its actual reputation, in a direction the brand cannot see without paired measurement.

ΔNPS is the diagnostic that captures this. It tells you, in a single number per quarter, whether the engines are amplifying or suppressing your corpus reputation, and by how much.

How µNPS is computed

µNPS ingests the observable corpus signals and aggregates them into a single sentiment value with NPS conventions. The pipeline:

1. Corpus collection. Pull brand mentions from review platforms (Yelp, Google, G2, TrustRadius, Capterra), social platforms (X / Twitter, LinkedIn, Reddit, Hacker News, Threads), press coverage (Google News surface, niche industry outlets), and the long tail of indexed web mentions. Time-bound to a defined window (we use rolling 90 days for the headline number, with longer windows available).
2. Sentiment scoring. Each mention is scored on a sentiment axis (-1.0 to +1.0) using an ensemble of LLM-based sentiment classifiers. Multi-model scoring (consistent with the median + outlier-drop methodology) reduces single-model bias.
3. Weighting. Mentions are weighted by source authority and recency. A Reddit thread three days old weights differently than a press citation eighteen months old.
4. Aggregation. Weighted sentiment values are aggregated to a single number on the -100 to +100 scale.

How λNPS is computed

λNPS runs a controlled probe set against the four major engines and aggregates the engine outputs into the same scale.

1. Probe set. A pinned set of brand-explicit prompts — five prompts probing different facets of the brand (overall reputation, product quality, customer service, leadership, controversies), each phrased in a way that elicits a substantive response.
2. Engine coverage. Five prompts × four engines = 20 LLM responses per brand per measurement cycle.
3. Response scoring. Each response is scored on the same sentiment axis as µNPS mentions, using the same multi-model classifier ensemble.
4. Aggregation. Weighted by recency (within the measurement cycle) and aggregated to the -100 to +100 scale.
5. Time decay across cycles. The published λNPS is a quarter-end value computed from weekly probes with exponential time decay, so a single bad week does not dominate the quarter and so the most recent measurements weight appropriately.

Interpreting ΔNPS

Once you have both µNPS and λNPS, ΔNPS is the diagnostic.

The secondary diagnostic vocabulary

Beyond the headline three metrics, four secondary terms make the diagnostic richer.

• λ-drift — engine sentiment changing over time. Quantified by quarter-over-quarter movement in λNPS. Useful for detecting newly-emerging signal (an acquisition, a product launch, a controversy) that is propagating through engines.
• λ-suppression — engine output weaker than corpus (negative ΔNPS). The state in which the corpus has favorable material the engines are not surfacing.
• λ-amplification — engine output stronger than corpus (positive ΔNPS). Engines surface favorable material at or above corpus baseline — the GEO win.
• λ-divergence — inter-engine disagreement. Quantified by the variance across the four engines’ individual λNPS values. High λ-divergence indicates that the engines do not agree about the brand — usually because they are retrieving from different corpora or training cutoffs. Often actionable as a content-coverage diagnostic (one engine is missing the content the others have).

What this looks like as a client report

The quarterly λNPS / µNPS / ΔNPS report for a representative client carries: the headline ΔNPS with current quarter and prior-quarter values, the µNPS and λNPS component values with engine-level breakdown, the λ-drift trajectory plotted weekly across the quarter, the highest-impact corpus mentions driving µNPS, the engine responses driving λNPS, an interpretation of any ΔNPS movement, and an action list for the next quarter.

The report is published with the required λ disclaimer on every page. It is not surveyed; it is reconstructed from observable signals. The discipline of the framework is in the consistency of the methodology across measurements and across clients.

The 9-Dimension GEO Rubric

A property’s readiness for AI search citation can be scored along nine weighted dimensions totaling 100 points. The target is 85; the floor is 70% on every individual dimension. The rubric is what we score every property against on intake and at every quarterly review.

Why nine, why weighted

The natural temptation in any scoring rubric is to make every dimension equally weighted, which has the virtue of simplicity and the cost of misrepresenting the underlying mechanics. AI retrieval does not weight bot access and freshness signals equally; bot access is binary-with-graceful-degradation, and freshness is a continuous lift signal. The nine-dimension weighting reflects what we observe across hundreds of audits about which infrastructure attributes actually move citation outcomes.

The rubric is internal-canonical across every Aryah-property project (Geogroup, Lavidge, Top10Lists, Geoai) and is used as the scoring scaffold for every client audit. It superseded the earlier 8-pillar equal-weighted rubric in April 2026.

The nine dimensions

The 70% floor — North Star SEV-0

The composite-85 target is the headline. The harder rule operationally: any individual dimension scoring below 70% of its maximum halts other work until it is remediated. A property at 86/100 with one dimension at 4/15 (27% of max) is not actually performing at 86; it has a load-bearing failure in one infrastructure category that drags the entire AI-search readiness.

The pattern we see most often: properties at 80–85 composite with Bot Access at 7/15 because the CDN’s default WAF blocks half the AI bots. The composite looks healthy; the bot-access failure means half the engines cannot retrieve the content. Composite hides the load-bearing failure mode that the per-dimension floor catches.

Treat any sub-70% dimension as a SEV-0 issue. Other GEO work pauses until it is addressed.

How dimensions are scored, briefly

Each dimension has a deterministic scoring rule documented in the methodology. The summaries:

Bot Access (15): 1 point per allowed AI bot pattern in robots.txt, up to 10; 5 points for confirmed origin-level accessibility to the top five bot UAs via curl-based probe. Composite scaled to /15.

Structured Data (12): count of distinct schema.org @type values on the homepage and top three templates, with type validation. Scaled.

AI Files (10): average of (llms.txt present + freshness), (mcp.json present + valid), (ai-plugin.json if applicable + valid). Scaled.

Sitemap (8): presence (4), valid lastmod accuracy (2), robots Sitemap directive (1), shard discovery (1).

Content Density (15): median word count band on priority templates, mapped to a 0–15 scale. Bands defined per category (B2B SaaS targets differ from local-business targets).

Citation Data (12): count of JSON-LD citation / isBasedOn / sameAs references on priority templates, plus inline quantitative-claim density.

Tech Perf (5): TTFB sub-200ms after baseline subtraction (3), HTTP/3 via alt-svc (1), render-free HTML (1).

Freshness (8): percentage of sitemap URLs with lastmod within 90 days, scaled to /8.

Authority (15): composite of Wikipedia presence, .gov/.edu citations, domain age (RDAP), and SERP brand strength.

How the rubric ties to ASQ™

The 9-Dimension GEO Rubric is one of the inputs to ASQ™ (Chapter 27), the composite quotient that integrates GEO infrastructure scores with SEO positioning, λNPS trajectory, and translation-receipt metrics. The 9-dim rubric is the deepest infrastructure diagnostic in the ASQ™ composite; ASQ™ is the headline number a client sees on a dashboard.

Why this rubric does not get gamed easily

Most scoring rubrics in marketing get gamed within a year of publication. The 9-dim rubric is harder to game for three reasons. First, the content dimensions (5, 6, 8) reward substantive work — original data, citation surface, real freshness — that is expensive to fake at scale. Second, the authority dimension (9) is anchored in third-party signals (Wikipedia presence, .gov / .edu citations, domain age) that you cannot fake. Third, the per-dimension floor catches the cosmetic-composite gaming pattern that would otherwise be the most obvious exploit.

The dimension a determined adversary can game is bot access (1) — just allow more bots. We see this happening across enterprise sites that have heard the rubric is published. Good. Bot access is one of the cheapest dimensions to move and one of the most valuable; the “gaming” here is the optimization we want clients doing.

ASQ™ — The AnswerShare Quotient

ASQ™ — the AnswerShare Quotient — is the composite number that captures a property’s overall AI-search positioning in a single value. It is a quotient, not a score, because it expresses a ratio of realized AI-search performance to attainable AI-search performance.

Why a quotient, not a score

The naming choice is deliberate. A score is a count of points accumulated against an absolute rubric; a quotient is a ratio of one quantity to another. ASQ™ expresses the ratio of a property’s realized performance across all measurable AI-search dimensions to the attainable performance against the same dimensions. The form is a percentage on the 0–100 scale, with 100 being a hypothetical property that maxes every input.

The naming also produces a brand-safe abbreviation. “AnswerShare Score” would have abbreviated to ASS, which is a meme rather than a metric. ASQ™ reads cleanly, abbreviates cleanly, and signals the ratio character of the measurement.

What goes into ASQ™

ASQ™ is intentionally broader than any single sub-metric. Its inputs are the comprehensive measurement surface across infrastructure, content, citation, and outcome.

• The 9-Dimension GEO Rubric composite (Chapter 26). The deepest infrastructure-and-content readiness diagnostic.
• Translation-receipt metrics from the Translation Layer™ (Chapter 29). AC (anti-cloak / human coverage), HR (headroom ratio), AUE (AI utilization efficiency) — the receipts that show the cutover delivered the parallel surface as designed.
• Bot crawl statistics. 30-day fetch count, consumer-triggered percentage, bot-type distribution. The actual demand the engines are placing on the property.
• Cross-engine citation metric. The QFS-aligned measurement of citation persistence across the four engines for the property’s priority slots.
• Site-metrics tile family. TTFB (median, compensated), TTLB (median, compensated), RTC (retrieval time-to-cite), RPS (requests per second sustained), SCHEMA (structured-data coverage), CITE (citation-property density), SGR (synthetic ground rate), RR (relevance recall), LMR (last-modified ratio).
• SEO positioning signals. SERP rankings on canonical category queries, link metrics (domain rating, referring domains, link velocity), traditional SEO signals that contribute to classical retrieval as the entry condition.
• λNPS / ΔNPS trajectory. The brand-reputation movement signal (Chapter 25).

Why ASQ™ is not just the 9-Dim Rubric

The 9-Dim Rubric is the deepest GEO infrastructure diagnostic in the stack. ASQ™ is broader: it folds in the actual measured demand on the property (crawl stats), the actual measured outcomes (citation, λNPS), and the SEO positioning that determines whether the GEO infrastructure is reaching the right candidate pool in the first place.

A property could in principle score 95 on the 9-Dim Rubric while ASQ™ remains at 70 because the SEO positioning is weak (the engines are not finding the property despite its readiness) or because the λNPS trajectory is poor (the engines are surfacing the property but synthesizing unfavorably). ASQ™ catches the discrepancies the rubric alone would miss.

The compute, simplified

ASQ™ is a weighted aggregation of normalized inputs:

ASQ = w_geo  · normalize(GEO_9dim)
    + w_tl   · normalize(translation_receipts)
    + w_botd · normalize(bot_crawl_metrics)
    + w_cit  · normalize(cross_engine_citation)
    + w_site · normalize(site_metrics_tile)
    + w_seo  · normalize(seo_positioning)
    + w_lam  · normalize(lambda_NPS_trajectory)

Weights are tuned by category (B2B SaaS, local business, e-commerce, professional services each carry slightly different optimal weights based on what predicts business outcome in that category) and re-tuned quarterly against client outcome data. The methodology page publishes the current weights and the prior-quarter weights so the movement is auditable.

Comparing ASQ™ across properties

ASQ™ is comparable within a category and across an industry; it is less informative as a cross-category comparison because the category-specific weights make a 70 in B2B SaaS not directly equivalent to a 70 in local hospitality. The published comparison reports always specify the category context and use the category-specific weighting.

The ASQ™ bench

We publish an industry bench at quarter-end across the major categories. The bench shows the median ASQ™ in each category, the top-decile threshold, and the distribution shape. Most categories cluster between 50 and 65 ASQ™ with a long tail in the 30s and 40s and a top-decile threshold around 80. The bench gives clients a defensible point of reference for “is my number good” without requiring them to share their data competitively.

AIFS — Measured, Probe, Proxy

AI citation outcomes are measurable, but the right measurement method depends on data access. The AIFS methodology defines three co-equal variants — Measured, Probe, and Proxy — that answer the same outcome question through different access regimes.

Why three variants

The naive position is to publish a single methodology and apply it to every measurement situation. The naive position is wrong because the data access required to measure AI citation outcomes differs dramatically across situations. A site whose owner has full internal telemetry has different measurement options than an external observer scoring a competitor; an internal observer with a large probe budget has different options than an internal observer with a tight budget.

The three AIFS variants are co-equal — not v1 / v2 / v3, not better / worse. They answer the same outcome question (“is AI actually citing this site when users ask”) through different data-access regimes. The right variant is the one that fits the situation.

Variant A — Measured AIFS

Measured AIFS is the authoritative variant when internal telemetry is available. The composite is SERP Visibility (60 points) plus Internal Data (40 points). Internal data decomposes into AI retrieval volume (15), citation probe rate (15), and content freshness signal (10).

Measured AIFS requires that the site owner has:

• Server or CDN logs with AI bot UA segmentation enabled and accessible.
• A probe-result store where outbound probe results can be correlated with retrieval volume.
• Content freshness telemetry that can be aggregated to a per-site signal.

When the requirements are met, Measured AIFS is the most accurate score because it correlates real retrieval activity (the bots fetched these URLs) with real citation outcomes (the probes saw the URL appear) and a real freshness baseline.

Top10Lists.us is the canonical case where Measured AIFS applies. Internal logs, internal probe store, internal freshness telemetry. Score in that situation: 43.5. The same site scored against Proxy AIFS returned 24 — the under-scoring is systematic on new sites with earned AI citations because Proxy AIFS leans on Brand Authority signals (Wikipedia, .gov/.edu citations) that take years to develop.

Variant B — Probe AIFS

Probe AIFS is the reproducible, mid-cost variant we use for client engagements. The composite is SERP Visibility (60 points) plus External AI Citation Probes (40 points). The 40 probe points decompose into per-platform contributions: each of Perplexity, OpenAI, Anthropic, and Gemini contribute up to 10 points based on the fraction of a 20-query pinned probe set on which the URL is cited.

Probe AIFS does not require internal telemetry. It requires:

• A pinned 20-query probe set per site (10 brand, 6 category, 4 long-tail).
• Access to the four engines via their respective APIs.
• Roughly $1.40 per site in API cost using the cost-optimized model choices, or about $1.60 per site at pay-per-call rates.

The result is a reproducible external citation score that any independent third party could compute against the same site with the same probe set. This is the variant we publish in client reports and competitive benchmarks; it is the variant the public methodology page describes in full.

Variant C — Proxy AIFS

Proxy AIFS is the cheap fallback variant for situations where Probe AIFS budget is unavailable or API keys are inaccessible. The composite is SERP Visibility (60 points) plus Brand Authority (40 points). Brand Authority decomposes into Wikipedia + .gov/.edu citations (20), domain age from RDAP (10), and brand strength signal from SERP behavior (10).

Proxy AIFS costs about $0.02 per site. It is the only variant that scales economically to 100-site cohort audits or to broad-survey scoring.

The systematic limitation: Proxy AIFS under-scores new domains with earned AI citations because the brand-authority proxy lags actual citation outcomes by years. A 12-month-old site with strong organic AI citation will score lower under Proxy than under Probe; a 20-year-old site with mediocre AI citation will score higher under Proxy than under Probe. The methodology page documents the bias explicitly.

Which variant when

What never varies across variants

The 60 / 40 split between SERP Visibility and the AI-citation component is constant across all three. SERP Visibility is computed identically across variants. The AI-citation component differs in its data source: internal telemetry for Measured, external probes for Probe, brand-authority proxy for Proxy.

The 60 / 40 weighting itself is empirical — it reflects the observed correlation between SERP visibility and AI citation across the audit cohort. As that correlation shifts (which we monitor quarterly), the weighting will be revisited. The current correlation makes 60 / 40 the right split; if AI citation begins to decouple further from SERP, the split moves toward 50 / 50.

The Translation Layer™

The Translation Layer™ is an edge-deployed parallel surface that serves machine readers a content-perfect, presentation-stripped version of a client’s site, while leaving the human-facing site unchanged. It ships in a single CF Worker drop and is the engineering core of every AnswerShare engagement.

The architecture, in one diagram’s worth of words

The Translation Layer™ is a Cloudflare Worker deployed in the client’s own Cloudflare zone. The worker binds to the client’s domain (or a designated path under it) and intercepts every incoming request at the edge. For each request, the worker inspects the user agent and routing context:

• AI bot UAs (GPTBot, ClaudeBot, PerplexityBot, Google-Extended, Applebot-Extended, and the rest of the named list) are routed to the bot-view surface, served from our edge-cached bot HTML.
• Search bot UAs (Googlebot, Bingbot, Yandex, Baidu) pass through to the client’s origin unchanged. SEO is not affected.
• Human UAs pass through to the client’s origin unchanged. The human site is unaffected.
• AI-facing static files (llms.txt, llms-full.txt, /.well-known/mcp.json) are served from the worker, with content generated from the same source as the bot HTML.

The worker also exposes a small instrumentation surface that captures bot identity, fetch URL, response timing, and TLS fingerprint for every routed request. That stream feeds the measurement layer described in Chapters 12 and 13.

Why this architecture, and why this is not cloaking

The architecture is the one shape that satisfies the constraints we care about. The client retains DNS, origin, certificate, and CMS control — we never touch their Umbraco / WordPress / Webflow. Our IP (the worker logic and the bot HTML generation pipeline) ships as compiled worker code with a limited inspection surface. Rollback is one worker-route deletion; the client’s human site is unaffected throughout. Client CF zone access is required only at the final cutover, not during the build phase.

Critically, this is not cloaking in the Google sense. Cloaking, as Google defines it, is the practice of showing search engines different content than human users see. The Translation Layer™ explicitly does not route Googlebot or Bingbot to the bot view — only the named AI bots, which Google itself separated from Google Search via the Google-Extended token in 2023 precisely so site owners could route AI training opt-out separately from search indexing. We ride that line, we did not invent it.

The client-facing answer to “does this affect my SEO” is verbatim: Googlebot still crawls the main site for typical SEO. We never route Googlebot to the translation layer — doing so would risk Google’s cloaking penalties and could damage organic search rankings. Use it verbatim.

The mirror rule — playbook rule #1

The bot view is a content-perfect mirror of the client’s human content, with presentation stripped. The discipline:

• Mirror every piece of content from the human page: every heading, every paragraph, every list item, every alt text, every footer disclaimer, every callout. The bot view’s word-count delta against the human page’s visible text should be near zero, never negative.
• Strip presentation: remove JavaScript, CSS, inline styles, presentation-only containers. Keep semantic tags (h1–h6, p, ul, a href, blockquote).
• Bring alt text and citations along: inline image alt text as <p><em>[image: {alt}]</em></p>; preserve every citation anchor in the original.
• Never use content extractors: Mozilla Readability, boilerpipe, dragnet, and similar tools heuristically drop content. They will drop hero taglines, footer disclaimers, sidebar callouts — content the client wrote that the engines need.
• Append an AI-instruction block: a small, consistent block at the end of each mirrored page that names the canonical URL, the citation string, the do-not-hallucinate marker, and the mirror timestamp.

The bot view is machines-only

No human ever visits the bot view in normal use. The only humans who do are us (during QA and audit) and the client (during the acceptance demo). The implication: every design decision should optimize for machine parseability, not human aesthetics.

Verbose JSON-LD is better than terse JSON-LD because the cost of additional fields is near-zero and the benefit to machine cross-referencing is real. Flat declarative prose beats stylistic prose because retrieval systems extract triples and lose anything that requires inference. Raw URLs as anchor labels are fine because machines tokenize structure, not rhetorical voice. Every important assertion lives in a heading, list, or table row that a parser can extract.

The engagement flow

1. Build phase. We crawl the client’s public site, score against the 9-Dimension GEO Rubric, build the clean-room bot HTML, generate the llms.txt, llms-full.txt, mcp.json, RSS feeds, and sitemap shards. The output is hosted on our staging infrastructure (a per-client preview URL) for client review.
2. Acceptance phase. The client formally reviews and signs off on what the bots will see. This is the contractual gate before any worker drop.
3. Deploy phase. The client grants a scoped CF API token (Workers + the specific zone). We deploy the worker, bind the worker route, run smoke tests against bot UAs (each returning the bot view) and human UAs (each passing through to origin). We hand over the kill-switch procedure and the runbook.
4. Operate phase. The worker runs in the client’s zone. We monitor through the instrumentation stream; the client retains full control of their origin and DNS. Material content changes on the client’s site trigger a translation refresh on a cadence the client controls.

The translation receipts

Every Translation Layer™ deploy produces a set of receipts that show the cutover delivered the parallel surface as designed. Three matter most.

AC (anti-cloak / human coverage) — the ratio of human-page content present in the bot view. Target: ~1.0. Lower means the mirror dropped content; higher means the bot view added content the human page does not contain (which is also a problem, because then the engine is citing a fragment that does not exist on the canonical page).

HR (headroom ratio) — the ratio of additional indexable content in the bot view versus the human page after presentation stripping. For video-heavy clients this is well above 1.0 (transcripts unlock content the human page does not surface as text). For text-only clients this is near 1.0 (the bot view is a presentation-stripped mirror).

AUE (AI utilization efficiency) — the ratio of bot-view fetches that result in downstream citation activity (per the measurement layer) versus the total bot-view fetches. A measure of whether the engines are doing useful work with what we serve them.

What the Translation Layer™ is not

It is not a CMS replacement. It does not give the client a new place to author content; the canonical content stays in the client’s CMS. It is not a CDN; it routes bots, it does not handle global traffic delivery. It is not a service the client can self-build in an afternoon; the architecture is simple, but the operational discipline (mirror correctly, ship the right schema, instrument correctly, kill-switch correctly) compounds across clients in a way that one-off implementations do not.

And it is not the moat. The Translation Layer™ is the infrastructure that enables the moat; the moat itself is the content the layer unlocks (Chapter 30).

The Content Moat

The Translation Layer™ is reimplementable in an afternoon by any competent AI engineering team. The moat is unlocking content trapped in formats AI search cannot read — video transcripts first, then PDFs, slides, images, FAQs, and case-study decomposition. Each unlock extends the moat without re-architecting the pipeline.

The infrastructure is not the moat

Be honest with yourself about this. The 200-line CF Worker that routes bot UAs to a clean bot view is reimplementable in a sprint by any team with the engineers. So is publishing llms.txt, llms-full.txt, and /.well-known/mcp.json. So is shipping JSON-LD with broad type coverage and sameAs anchoring. The methodology is public; the patterns are widely known; the engineering is straightforward.

Anyone can match the GEO infrastructure score within a sprint. That fact is not negotiable, and the right strategic posture is to assume it.

The corollary: if your competitive position depends on the infrastructure being uncopyable, you do not have a competitive position. You have a temporary advantage that disappears on the schedule of your competitor’s next sprint.

What is not reimplementable in a sprint

A robust video-ingestion pipeline that detects every embed type (<video>, iframe, YouTube, Vimeo, custom players), extracts audio reliably, transcribes with brand-name accuracy from a maintained glossary, cleans up the transcript with an LLM pass, injects VideoObject schema with the transcript property, and maintains a freshness lifecycle that re-transcribes when source URLs change — that is not a one-sprint project. It is a multi-quarter operational accumulation.

A brand-name disambiguation glossary built across servicing ten or more agency-class clients — not reimplementable in a sprint. The glossary entries that mark “UNVAPE” as a campaign name, “Heitz” as the CEO, and “ESOP” as the corporate structure for a specific Arizona agency are operational accumulations.

The transcription-correction workflows, the multi-format ingest reliability patterns, the freshness-lifecycle alerting, the schema-injection automation, the brand-glossary maintenance — all of these are operational accumulations that grow with each client onboarded and that compound non-linearly.

That is the moat. Engineering plus operational accumulation. The infrastructure is the floor; the operational machinery is what makes the next client onboard at quarter the cost and twice the quality.

The math on a typical agency client

The compound math is straightforward and we observe it on every client.

• Pre-translation: ~1,000–2,000 useful characters per page in marketing copy. Most of the page is presentation.
• Post-translation: ~3,000 useful characters per page after presentation stripping, citation injection, and structured-data exposure. The bot view surfaces content that was on the page but not extractable by retrieval.
• Post-transcription: ~6,000 useful characters per page on video-heavy templates (case studies, leadership profiles, methodology pages). Spoken content that was completely opaque to retrieval becomes the highest-information-gain content on the page.

Net effect: 2–3x indexable content per client without adding a single page to the property. The lift is multiplicative against the per-page citation probability the engines compute.

The quality of the added content matters more than the volume. Marketing copy: ungrounded claims like “our award-winning campaign.” Video transcripts: spoken outcomes with implied or explicit sources, like “UNVAPE drove a 45% reduction in youth e-cigarette use over 18 months, validated by Arizona Department of Health Services survey data.”

SGR (synthetic ground rate) moves from T5 (self-attributed marketing) to T2–T3 (verifiable outcome data) at the same time as content density doubles. Both lift AI citation probability simultaneously. The math compounds rather than adds.

The format roadmap, priority-ordered

Six formats matter, in rough priority order by content-unlock leverage.

Start with video. Build the pipeline once. Extend the same operational patterns — ingest detection, audio/visual extraction, LLM cleanup, structured-data injection, freshness lifecycle — to subsequent formats. Each format extension reuses the operational chassis; each extension compounds the moat across the client portfolio.

The strategic framing for sales

The sales conversation we run for agency-class clients leads with “we unlock content AI search cannot currently read on your site,” not “we optimize your AI-facing infrastructure.” The infrastructure work is table stakes — we ship it, but it is not the differentiation. The content unlock is the differentiation, and it is the lever that moves AIFS citation outcomes without requiring SEO and authority years to develop.

The corollary on the methodology side: the 9-Dimension GEO Rubric is the price of entry; AIFS (citation reality) is the outcome metric; content unlock is the lever that moves AIFS without requiring SEO and authority to compound first. Properties at 85+ GEO with weak content unlock plateau on citation outcomes; properties at 80 GEO with strong content unlock keep moving.

What this implies for client selection

The clients who get the most value from this approach are clients with deep content already produced in formats AI cannot read. Agencies with video case studies; consultancies with podcast libraries; education brands with lecture archives; B2B SaaS with technical-talk recordings; professional services with conference panels. The translation layer makes their existing content indexable; the content moat is what they already have, exposed.

The clients who get less value: brands whose primary content is the marketing copy on the home page. The pipeline can run; the AC ratio (anti-cloak coverage) will be near 1.0; the HR (headroom ratio) will be near 1.0. The infrastructure ships; the content unlock has no headroom to capture.

This is the right place to draw the line. Clients with content depth become competitive citation properties; clients without content depth become correctly-instrumented marketing sites. Both are honest outcomes; only the first is the long-form story.

Measurement

AI engines form opinions of brands and express them at scale. μNPS, λNPS, and ΔNPS are the measurement instruments that make that opinion legible, reproducible, and actionable.

Notation

Three symbols, three definitions, all derived from the AnswerShare measurement whitepaper.

ΔNPS State Interpretation

Secondary analytical terminology

• λ-drift — machine sentiment changing over time. Quantified by quarter-over-quarter movement in λNPS. Useful for detecting emerging signals (an acquisition, a product launch, a controversy) propagating through engines.
• λ-suppression — machine output weaker than corpus (negative ΔNPS). The state in which favorable corpus material is not being surfaced by engines.
• λ-amplification — machine output stronger than corpus (positive ΔNPS). Engines surface favorable material at or above corpus baseline — the GEO win.
• λ-divergence — inter-engine disagreement. High λ-divergence indicates engines do not agree about the brand — usually because they are retrieving from different corpora, different training cutoffs, or different weighting of live retrieval vs. pretrained signal.

Research foundations

The following studies are cited in the λNPS whitepaper as load-bearing evidence for why corpus-versus-machine paired measurement is needed, and why the specific methodology choices (controlled prompting, exponential decay weighting, multi-engine coverage) are made the way they are.

Ghost citations and corpus influence without attribution

Kevin Indig (Growth Memo, April 2026) examined 3,981 domains across 115 prompts in 14 countries and found that 61.7% of citations are ghost citations: the AI drew on a domain’s content without naming the brand. Three out of every five times a brand’s content shaped an AI answer, its name did not appear. This finding grounds the μNPS framework’s focus on corpus-level influence rather than explicit citation counts: if most corpus influence is invisible in outputs, you need a measurement that reads the corpus independently of what the machine names.

Indig also found that Gemini names brands in 83.7% of appearances but cites them only 21.4% of the time; ChatGPT inverts the pattern, citing 87.0% but naming 20.7%. The engines show roughly 22% disagreement on whether a brand was mentioned at all for the same query. This grounds the λNPS four-engine coverage design: a single-engine reading misses the inter-engine variance that is itself a diagnostic signal (λ-divergence).

Brand mentions, corpus presence, and recommendation correlation

Surfer SEO (Kohli, 2026), drawing on a 289,000-URL dataset, found a Spearman correlation of 0.41 between brand-mention frequency and AI recommendation rate. Pages with ten or more discrete facts get cited at roughly twice the rate of fact-thin pages. This grounds the μNPS corpus-weighting design: signals are weighted by substance proxies (length, specificity, named entities) because the engines themselves appear to prefer longer, fact-denser content.

Ahrefs, Brand Mentions and AI Recommendation Correlation Study, 2025 reported YouTube mention correlation with AI recommendation at roughly 0.737 Spearman — substantially higher than the all-channel 0.41 number. This is consistent with the μNPS weight design giving video testimonials the highest weight among signal types: the machine appears to treat video as the highest-credibility signal.

Branded share of voice as a measurement discipline

Aleyda Solís (Humans of Martech, January 2026) argued that AI search “must be treated as a branding channel, not only a performance channel. Inclusion, share of voice, and sentiment in answers matter even when they generate no direct click or referral traffic.” Her published 10 Steps AI Search Content Optimization Checklist specifies: “Monitor your brand mentions, sentiment, and links separately for each major AI search platform.” The four-engine λNPS breakdown is the operational implementation of that recommendation.

AI grounding, retrieval trust, and source attribution

Frontier AI systems increasingly rely on grounded retrieval and trust-aware generation to reduce hallucinations. Three sources cited in the whitepaper ground the trust-priors framework that underlies λNPS:

• Google Cloud: How Vertex AI Grounding helps build more reliable models — establishes that grounding is foundational to modern AI system behavior and citation quality.
• Anthropic: Introducing Contextual Retrieval — documents how retrieval systems use context to improve grounding and citation confidence.
• Song et al., arXiv:2409.11242 (2024) — “Measuring and Enhancing Trustworthiness of LLMs in RAG through Grounded Attributions and Learning to Refuse.” Core finding: trust-aware generation and grounded attributions materially reduce hallucination rates in RAG systems, establishing that trustworthiness is a real, measurable property of AI source-handling.

These three sources ground the claim that AI systems do not retrieve sources equally — they apply probabilistic trust priors to domains. λNPS is the measurement expression of that differential trust as it surfaces in brand sentiment outputs.

Corpus sentiment and the NPS framing

Britney Muller (AI SEO Show, November 2025) and Elumynt UpArrow podcast (2025) characterized the pretrained LLM layer as “your mediocre generating engine” — the statistical average of everything the model has read about a brand. “Brand mentions are the new backlinks.” This framing grounds the μNPS corpus-reading approach: if the model averages what it has read, measuring what it has read is measuring the input to that average.

Industry Synopses: iPullRank AI Search Manual

Practitioner notes extracted from Mike King’s AI Search Manual. Each entry captures core thesis, named frameworks introduced, and claims worth flagging — written for execution, not summary. Where AnswerShare agrees, the alignment is noted; where we diverge, the divergence is flagged inline.