We scored our own site 50 out of 100.

We scored our own website for AI-search citability. It came back 50 out of 100. The five levers in the table below account for the whole of that score.

The number is not the interesting part. The distribution is. Four of the five levers behaved roughly as we expected, and the two that dragged the score down were the two we had never thought of as marketing work at all.

One disclaimer belongs above the number rather than buried under it. These are heuristics from marketing judgement. They are not measured performance, and they are not any engine's ranking data. No engine publishes its citation criteria, so every score in that table is inference from observed behaviour. Treat it as a way to rank what to fix first, not as a measurement of anything.

What does a citability score actually measure?

Five things, weighted by how much each one appears to gate the others.

Extractability, 25 percent. Whether an answer can be lifted off the page without being rewritten first. A model summarising a page is doing retrieval, not appreciation. A heading that states a position survives the lift. A paragraph that reaches its fact in the third clause does not.

Specificity and evidence, 25 percent. Whether the page carries figures, dates and named sources rather than adjectives. "Fast" is unquotable. "Four to eight weeks" is quotable.

Entity clarity, 20 percent. Whether a name resolves to one organisation. This is the lever nobody on a web team owns, because it is not a page property. It lives in schema markup and in third-party profiles — anywhere the same description of you has to appear twice before it counts.

Corroboration, 20 percent. Whether anyone other than you describes you on the open web.

Machine access, 10 percent. Whether a crawler can read the page at all.

The weights matter less than the interaction between them, which is where our score actually came from.

Why did our two lowest scores make the other three unspendable?

Corroboration scored 22, entity clarity 34. Together they carry 40 percent of the weight. The real cost is not arithmetic.

Our working model is that resolution and corroboration gate everything downstream: a system that cannot work out who you are, and finds no independent source describing you, has little reason to cite you regardless of page quality. That is an inference from observed behaviour, not a documented mechanism. Extractability at 62 and evidence at 58 are both improvable. Improving them first would have bought us nothing, because the constraint sits upstream of both.

This is the finding we would repeat to any engineer scoring their own site. The lever with the lowest score is not automatically the one to fix. The lever that gates the others is. In our case those happened to be the same two, which made the sequencing easy and the work unglamorous.

The work we shipped went into schema and entity signals, not into rewriting headlines. Getting described accurately elsewhere is still ahead of us.

Who actually gets cited when someone asks a commercial question?

We queried the questions our buyers would type. Every commercial question came back answered from listicles.

Not from studio homepages. Not from service pages. The citation set for "best studio for X" style questions was, almost uniformly, blog posts sitting on other agencies' domains — roundups, comparison posts, "top 15" pages written by companies who also sell the service.

That has a consequence worth sitting with. The set of pages competing for a citation is not the set of companies competing for the client. Our SEO competitive set is a list of studios. Our citation competitive set is a list of articles, several of them published by those same studios. Optimising a homepage against a competitor's homepage is fighting a battle that the answer engine is not holding.

For a services business the practical read is that a large share of citation opportunity lives off your own domain entirely. That is uncomfortable, because it is the part you cannot ship on a Friday.

Does any controlled research support this, or is it all folklore?

Most published GEO advice is untested. One study is worth citing: the Princeton GEO paper, presented at KDD 2024, arxiv.org/abs/2311.09735. It measured per-tactic visibility change inside generative engines rather than guessing at it.

Two caveats. The figures are directional, and engine behaviour has moved considerably since the paper ran. What has held is the ordering: evidence density beats keyword tactics, and the tactic classical SEO leaned on hardest measured nothing at all in generative retrieval.

The ordering is also the useful part for an engineer, because it converts into instructions. A quotation is a string a model can lift with attribution intact. A statistic is a string that survives summarisation, because a number cannot be paraphrased into vagueness. Keyword density produces neither. The paper is not telling you to write better prose, it is telling you to put liftable objects on the page.

Why did machine access score 88 when nothing else did?

Because the engineering was already done, and none of it was done for this reason.

The site was statically prerendered before we ever thought about answer engines. It serves clean HTML with no JavaScript gating on content, which means a crawler that does not execute scripts still gets the full text. The robots.txt allows GPTBot, PerplexityBot and ClaudeBot rather than blocking them by default. An llms.txt was already being served.

Most sites score far worse on this lever, and the reason is usually a client-rendered marketing page behind a framework that needs a browser to produce text. If your site is a modern SPA with content assembled at runtime, this is where your cheapest points are, and it is a build change rather than a copy change.

Our 88 had one real defect, and it is the most instructive thing we found all week.

The llms.txt was generated from the same structured content that drives the site. The capabilities array it read from held abstract category labels — "Frontend Systems", "Backend and APIs", "Data Layer" — which read perfectly well to a human scanning an about page. Emitted into a file whose only reader is a language model, they are close to worthless. Nobody asks an engine for a studio that does Frontend Systems. They ask for a Next.js agency, or a Postgres developer, or someone who has shipped on Vercel.

We were serving an abstraction where the retrieval value sat entirely in the concrete nouns underneath it. The fix was to map each label to its actual technologies and emit those, so the file now names Next.js, TypeScript, Tailwind, Node.js and PostgreSQL rather than the categories that contain them.

The general form of that bug: any content model with a presentation layer above it will tend to leak the presentation layer into machine-readable output. The abstraction that helps a human skim is the abstraction that destroys the match. Check what your llms.txt and your JSON-LD actually contain, not what the template intends them to contain.

What would a competent engineer check on their own site?

In roughly this order, because the order is the point.

1. Fetch your own pages with JavaScript disabled. curl the URL and read what comes back. If the content is not in the response body, your machine access score is near zero and nothing else on this list matters yet.
2. Read your robots.txt as a policy document. Decide deliberately whether GPTBot, PerplexityBot and ClaudeBot are allowed. Either answer is defensible, drifting into a default is not.
3. Read your generated machine-readable files as a stranger. llms.txt, JSON-LD, meta descriptions. Look specifically for category labels standing in for concrete nouns.
4. Search your own company name and your founder's name. If either collides with other organisations or other people, entity clarity is your binding constraint, and page-level work will not move it.
5. Query the five questions your buyers actually type, and record the domains cited. Not the ranking. The domains. That list is your real competitive set.
6. Count the liftable objects on your highest-intent page. A number, or a quotation with its attribution still attached. If a paragraph contains no extractable object, it is unlikely to be quoted from.

The first three are engineering and take an afternoon. The fourth and fifth are diagnosis. The sixth is where evidence density stops being a concept and becomes an editing task.

What has actually changed since the scan?

Nothing measurable. Saying otherwise would be the exact error this post is about.

The schema and the llms.txt changed in the same week as the scan. Schema changes, an llms.txt carrying real technology names, case studies reframed as technical write-ups with question-shaped headings. None of it has had time to move anything in any answer engine, and citation behaviour is non-deterministic enough that a single observation would not tell us if it had.

That last point deserves emphasis, because it is the most commonly broken rule in this field. Asking an engine a question once and seeing your name is not evidence. Asking it once and not seeing your name is also not evidence. Citation varies run to run, across engines and across sessions, so any claim built on one query is a claim built on noise. We plan to re-run the same questions several times per engine at the 30-day re-measurement, and record brand mentions separately from domain citations, because those are two different events.

We are not promising citation. Nobody can. What this work buys is narrower and defensible: text a model can lift, and an identity it can resolve. Whether an engine chooses to cite any of it remains that engine's decision, made by criteria it does not publish.

What is still unresolved?

Several things, and the honest list is longer than the fixed list.

The corroboration problem is not solved, it is only diagnosed. We know the score is 22 and we know why. Getting independently described on domains we do not control is slow work with no ship date, and it is the single largest remaining component of the gap.

We have not verified the score against engine behaviour. The scan is a heuristic model of what engines reward. It could be wrong in its weights, or wrong in the direction of a specific lever, and we would not currently be able to tell.

The re-measurement has not happened. Until it does, everything above is a description of what we found and what we changed. Not a result.

We do not know how much of this survives the next model release. The mechanism arguments — extractable text, resolvable identity, corroborating sources — should be durable, because they describe how retrieval works rather than how one product behaves. The specific tactics may not be.

The scan was worth running for one reason that had nothing to do with the number it produced. It made us read our own machine-readable output as a stranger. The llms.txt is the file we caught. The JSON-LD, the sitemap and the meta descriptions came out of the same templates and have not had the same reading. That was not a scoring artefact. That was a real defect, sitting in production, invisible to every human who had ever looked at the page.