# GEO and LLM attribution

Status: draft. Owner: Andrew Flett. Last reviewed: 2026-08-27.
Canonical: https://agentic.madebymany.com/positions/geo-and-llm-attribution

Generative engine optimisation is where SEO was in 2003: a real phenomenon surrounded by people selling certainty they do not have. Almost everything sold as an AI-specific technique is unmeasured. The things that demonstrably work are the things that already worked, applied properly.

We say what the evidence supports and decline to promise the rest. That is a competitive position, not a cautious one, because clients have usually already been pitched the certainty version and found it thin.

## What the evidence supports

| Measure | Status | Why |
|---|---|---|
| Crawl access and server-rendered HTML | Established | Server-log analysis and retrieval testing agree this is what the assistants consume |
| Conventional ranking strength | Established | The assistants retrieve from search indexes. Google states its generative features run on core Search ranking, and roughly three quarters of AI citations come from top-ten organic results |
| Content at stable, addressable URLs | Established as a precondition | Content with no address cannot be cited by anything |
| Visible provenance on the page | Established as a precondition | Answer-engines extract visible HTML. Metadata they ignore does not travel |
| JSON-LD | Indirect | A 1,885-page controlled study against matched controls found no direct citation lift. The value is upstream, in the indexes that drive rankings. Emit it, claim nothing for it |
| llms.txt | Weak | No provider has committed to consuming it, and Google says it is not used. Five minutes of work, and no outcome depends on it |
| Guaranteed citation or placement | Not achievable | No supplier can promise this. Anyone who does is guessing |

> The work is the same work. Structured content, clean rendering, real URLs and strong conventional SEO serve readers, assistive technology, search engines and answer-engines at once.

That line is the strongest one available, and it is also why this is not a separate workstream from [accessibility](/positions/accessibility) or performance. Clients who have been quoted for a standalone AI-readiness engagement tend to find it clarifying.

## One source of truth, as many representations as needed

There is never a second source, because two versions of the same claim drift apart and the drifted one is the one a machine quotes. That is not a rule against machine-facing surfaces. A sitemap, a feed and a markdown alternative are all representations generated from the one source, and serving a format at the canonical URL under content negotiation is better still, because then there is only ever one address to keep right. This site works that way: the markdown twin of every page is derived from the same data the page renders and served at the same URL under an Accept header, so there is nothing to fall behind.

```callout What cloaking is, and is not
[Google's spam policies](https://developers.google.com/search/docs/essentials/spam-policies) define cloaking as different content to different requesters at the same address, with intent to manipulate. They do not mention AI surfaces and do not address alternative formats. We neither hide behind that distinction nor invent a prohibition that is not there.
```

## The build decisions that follow

Everything above resolves into decisions taken at the start of a build, not fixes retrofitted after one.

- **Server-render editorial content.** No major AI crawler executes JavaScript, so anything that appears only after hydration does not exist as far as they are concerned. A rendering-strategy decision per page type, taken up front.
- **Give everything an address.** Listings, filtered views and paginated results need real URLs, with the filter and the page number in the path or query rather than held in client state. The common failure is a listing that fetches results client-side and never changes the URL, so nothing past the first screen can be reached, linked or cited.
- **Return real status codes.** Roughly a third of assistant fetches land on 404s, against Googlebot's eight per cent, and an app shell that answers 200 to everything teaches a crawler that every wrong guess is a real page.
- **Anchor down to section and table level**, so the citable unit is the claim and not the whole document.
- **Render a tabular equivalent behind every chart**, so figures exist in markup rather than only inside an image or a canvas element.
- **Model provenance as structured fields, and render them visibly.** Institution, authorship, date, version, revision status, relationships to other content: structured in the content model so it is consistent across the estate without depending on author diligence, and rendered in the text the assistants read rather than only in metadata they skip.
- **Get claims out of PDFs and onto pages.** A figure in a PDF gets scraped or remembered. A figure at a URL can be cited and corrected.
- **Build the machine-facing surfaces as part of the site**, not as an afterthought: segmented sitemaps regenerated on publish, feeds for time-ordered content, and where the content warrants it a documented data endpoint with filtering and paging expressed in the URL.
- **Set cache directives per page type.** Framework defaults often emit headers that stop any downstream cache holding a page, which quietly makes every request an origin request. Worth checking on any inherited estate.

## The argument that usually lands

Content without addresses is expensive and uncitable at the same time. If a listing is client-rendered with no URL per page, anything that wants the data has to enumerate it through the interface, which is the costliest possible path, and nothing it finds can be cited back. Fixing addressability fixes both. When a client is worried about machine traffic costs and worried about AI visibility, they are usually looking at the same defect from two ends.

## Scores and scanners

Agent-readiness scoring arrived in 2026, and it earns the same treatment as structured data: worth running, worth claiming nothing for, because nothing yet connects a score to an outcome.

```callout This site, scored
This site scores 71 out of 100 on Ora's 118-check scan, and two of its failures are the useful ones. The scanner resolved our identity from the deployment domain and went looking for the wrong brand entirely, which is a fact about hosting on a subdomain of somebody else's, not about the content. A score is a description of what a scanner could reach, not evidence that reaching it changed anything.
```

## What can be measured

Nobody can tell a client how often an assistant cites them, because the providers mostly do not report it. Some free first-party data exists and is worth having; the commercial tools measure something narrower than they imply.

| Source | What it shows | Worth knowing |
|---|---|---|
| Bing Webmaster Tools | Citation counts in Copilot and Bing's AI answers, page by page, with the grounding queries that triggered them | The only query-level AI data any provider publishes. Bing's index also powers ChatGPT search, so it is a partial proxy. Verify every client site here; it takes minutes |
| Google Search Console | The Generative AI report separates AI Overviews and AI Mode impressions by page, country and device | Impressions only. No queries, no clicks |
| Analytics referrals | Assistant referrals in GA4's AI Assistant channel, or an Adobe segment | A floor, not a count: a lot of assistant traffic arrives with no referrer and lands in Direct |
| OpenAI, Anthropic, Perplexity | Nothing for site owners | Crawler documentation only |

The commercial tools work by generating both halves of the dataset: prompts executed at scale against the assistants, and prompt volume estimated from bought clickstream panels, largely browser extensions. That is the same method and the same error bars as SEO keyword volume estimation, which is not a criticism, just worth understanding before quoting the numbers as fact. Profound is the enterprise option, and its headless browser sessions against the consumer products sit closer to what users see than API calls do. Semrush's AI Visibility Index makes sense where the client already holds Semrush, Otterly and Peec are the lighter end, and AthenaHQ has a free tier worth using for a trial.

What none of them do is check whether the answer is correct. They measure share of voice, because their buyers are marketers. Where a client's content carries authority, accuracy and currency matter more than presence, and nothing on the market covers that. Testing it directly is not hard, since it is the same synthetic-prompt method the paid tools use, applied to a question set with known correct answers.

One caveat travels with all of it: API-with-search and the consumer products are not identical surfaces, so anything measured this way reflects how the systems retrieve rather than exactly what a given user sees. Fine for trends, not a per-user truth.

## Sources

- [Google Search Central: AI optimisation guide](https://developers.google.com/search/docs/fundamentals/ai-optimization-guide), May 2026. Google's own statement that its generative features run on core Search ranking.
- [Ahrefs: schema markup and AI citations](https://ahrefs.com/blog/schema-ai-citations/), May 2026. The 1,885-page controlled study behind the JSON-LD row.
- [searchVIU: AI crawlers and JavaScript rendering](https://www.searchviu.com/en/ai-crawlers-javascript-rendering/), December 2025. Retrieval experiments behind the server-rendering row.
- [Vercel and MERJ: the rise of the AI crawler](https://vercel.com/blog/the-rise-of-the-ai-crawler), December 2024. Server-log analysis behind the crawl-access and status-code figures.

## Related agentic skills

- [mxa-discoverability](https://agentic.madebymany.com/playbook/skill/mxa-discoverability)
- [mxa-audit-discoverability](https://agentic.madebymany.com/playbook/skill/mxa-audit-discoverability)
- [mxa-frontend](https://agentic.madebymany.com/playbook/skill/mxa-frontend)