What LLM SEO means, and why the name is unhelpful
LLM SEO is the practice of making a site retrievable and quotable by large language models and the agents built on them. The name is unhelpful because it suggests the same work pointed at a new engine, and the most important part of it is not content work at all: it is what your server returns when an assistant fetches a URL mid-conversation.
That is the shift worth internalising before anything else. Classic SEO optimises for a crawler that visits on its own schedule and a ranking that resolves over weeks. LLM SEO optimises for a fetch that happens because a user asked a question thirty seconds ago, under a token budget, with no rendering and no patience. The feedback loop is one HTTP request long.
What transfers, what stops counting, what is new
Three columns, and the middle one is where experienced practitioners lose time by continuing to do work that used to pay.
| Transfers unchanged | Stops counting | Newly load-bearing |
|---|---|---|
| Crawlability and fast, stable responses | Keyword density and heading stuffing | Answering Accept: text/markdown |
| Titles that state the page’s subject | Layout, visual hierarchy, above the fold | Response size, measured in tokens |
| Internal linking that reaches every page | Word-count targets | How deep the first core fact sits |
| Accurate structured data where a spec exists | Anything that appears only after JavaScript | Bot rules in the CDN and the WAF |
| Topical authority and real citations | Interstitials, carousels, modals | A curated index at /llms.txt |
The middle column is not neutral, it is expensive. Every kilobyte of layout markup is context the assistant spends before reaching your facts, and anything rendered client-side is simply absent from what a fetch returns. A page that looks perfect in a browser and scores badly here is the normal case, not an anomaly.
Four things to stop doing
- Stop shipping facts client-side. A price, an opening-hours table, or a fee list that only appears after JavaScript runs does not exist in the response an agent reads. This single item explains more bad scores than the other three combined.
- Stop treating llms.txt as the deliverable. A mid-2026 study across 300k domains found no measurable citation lift from llms.txt alone, against roughly 4.2x for content negotiation. Ship the file; do not bill it as the strategy.
- Stop inheriting bot rules. A
robots.txtline or CDN filter added years ago against scrapers now blocks the assistants your client’s customers are asking. Audit the rules as a deliberate decision rather than a legacy. - Stop reporting the fetch half from page-view analytics. Agent fetches run no JavaScript and fire no beacon, so a page-view script structurally cannot contain the results of this work; reporting that half from one is how a successful project gets cancelled. The script-visible half, AI-referred visitors and browser-driving agents, is what the free Rebilder Tag counts, labelled as the half it is.
An LLM SEO audit, step by step
Half a day on a mid-size site. The order is cheapest-first, and each step either finds the problem or rules it out.
- Reachability. Fetch a representative page of each template from a plain terminal, with no browser headers. Note anything that challenges, redirects to a login, or answers differently to a non-browser user agent. This is the failure that makes every later measurement meaningless.
- Negotiation. Repeat each fetch with
Accept: text/markdown. Record whether the response differs at all. For most sites it does not, and that is the headline finding of the audit. - Cost. Measure the byte size of each template’s response and estimate tokens. You are looking for the ratio of chrome to substance, not an absolute number.
- Fact position. For each template, find the character offset of the first fact a user would ask an assistant about. Price, hours, fees, eligibility, contact. An offset in the tens of thousands is a finding, even when the fact is technically present.
- Structured data agreement. Check that the JSON-LD says the same thing the text says and covers the same fields. A page whose structured data describes hours but omits fees produces a confidently incomplete answer, which is worse for the client than no answer.
- Index and discovery.
/llms.txt,/sitemap.xml, canonical tags, and whether the index is generated or hand-maintained. A hand-maintained one disagrees with the site within a quarter. - Score the baseline. Run a readability score against a published spec on each template and keep the number. Taking it after the work is the most common way a team ends up unable to prove the change was worth doing.
What you can honestly promise a client
This is where the discipline earns or loses its reputation over the next two years. Three tiers, and they should appear in a proposal in this order.
| Tier | Examples | What to say |
|---|---|---|
| Measurable and controllable | Response size, whether the fetch is answered, fact position, readability score | Commit to it. These are properties of your own server and they move the week you ship |
| Measurable, not controllable | Agent visits by platform, answer rate, the miss log, AI-referred sessions | Report it, and set the baseline before you start |
| Neither | Being named in a given assistant’s answer to a given prompt | Never promise it. Assistants are not deterministic and no vendor controls the output |
The most valuable artifact you can hand a client sits in the middle tier: the list of URLs agents asked for that the site could not answer. It needs no vendor index and no other client’s data to be useful, it names the next fix in the order the market is asking for it, and it makes the work legible to someone who does not care about HTTP headers.
- Conversion lift, AI-referred visitors vs search
- ~38%
- Cyber Week 2025 retail data
- Content negotiation vs llms.txt, accurate retrieval
- ~4.2x
- 300k-domain study, mid-2026
What the fix is worth, measured
Two reference captures, both deterministic and rebuilt from committed fixtures on every build. They are quoted separately because a product page and a services page carry different amounts of chrome, and averaging them would produce a figure neither one supports.
| Capture | Before | After | First fact |
|---|---|---|---|
| Commerce product page | 91,226 bytes | 1,315 (−98.6%) | Character 23,185 → line 4 |
| Clinic services page | 13,581 bytes | 1,412 (−89.6%) | Character 10,152 → line 8 |
Roughly 69× less context on the commerce capture and 9.7× fewer tokens on the document one, for the same facts. Use the capture that matches your client’s site rather than the more impressive number: a services page quoting a PDP figure is the kind of overclaim that gets the whole discipline distrusted.