Technical GEO — the technical layer of Generative Engine Optimization — is the work that makes your site machine-readable for AI engines: crawler access for the user-agents they actually send, a server response that contains your content rather than an empty shell, a JSON-LD graph that says who you are in a form a model can parse, identifiers that agree with the rest of the open web, and an llms.txt that states plainly what your company is and what it is not.
It is unglamorous and it is first. Entity work on a site a crawler cannot read is invisible. Citation work on a brand a model cannot verify does not hold — the name appears in an answer, then drops out. The order is fixed: readable, then verifiable, then quotable.
what actually breaks, and how often
These are the five failures from our published dataset of 100 audits (April–July 2026). Not opinions about best practice — counted frequencies across a hundred real companies of every size and budget.
| failure | found in | what it costs you |
|---|---|---|
| no entity anchor | ~100% | Nothing lets a model confirm you are a specific, real company. You are a string, not an entity. |
| no JSON-LD markup | 94% | No machine-readable passport. The model has to guess what you do from prose, and often guesses another company. |
| anonymous content | 89% | No named author, no dates, no sources. Exactly the profile a model discounts when choosing whom to quote. |
| no llms.txt | 87% | Missing or returning 404. Where it existed it was usually a link dump of the blog rather than a map. |
| unreadable to AI crawlers | 50% | Client-side rendering, blocked bots or outright 403s. In a third of those it was a full blackout: the engine sees nothing at all. |
The market average health score across those hundred sites was 35 out of 100, 58% scored 35 or below, and not one cleared 60. That is the uncomfortable half of the finding. The useful half is that almost every category is still winnable from a standing start, because the neighbours are broken in the same five ways.
green in Lighthouse, empty for the engine
The single most expensive assumption we meet is “our site is fast and the SEO tools are green, so the bots are fine.”
One site in the report scored 100/100 for SEO in Lighthouse. Requested with the GPTBot user-agent, the same URL returned 1,133 bytes of empty shell — a container, a script tag, and nothing a model could read. Both facts were true at the same moment on the same address. Lighthouse executes JavaScript; several AI crawlers do not.
A second pattern is blunter: a licensed operator with real regulatory standing served 403 to every AI crawler. The licence existed, the compliance was real, and none of it was reachable — so the models answered questions about the brand using review aggregators and complaint threads instead. Blocking a crawler does not remove you from AI answers. It removes your version of the story and leaves the rest.
the three layers, in the order they have to be done
1 · readable
Can an engine fetch your pages and get your content back? We request the site as GPTBot, ClaudeBot, PerplexityBot and the rest, compare the response against what a browser sees, and find the gap. Then: unblock the crawlers that are blocked (often by a managed rule nobody on your team knows about), fix rendering so the server returns content, clean the redirect chains and the duplicate hosts, and publish an llms.txt that is a genuine map of the site — including a disambiguation paragraph naming what you are not, if something else shares your name.
2 · verifiable
Can a model confirm you are real and specific? This is the JSON-LD graph — Organization, WebSite, Article, FAQPage, Breadcrumbs, tied together with stable identifiers instead of floating as disconnected blocks. It is a sameAs array that points at profiles that actually exist. It is the same company name, the same founding year and the same description everywhere a machine can read them, because a model that finds three versions of you trusts none of them. And it is named humans on the content, with real dates and real sources.
3 · quotable
Is there anything on the page shaped like an answer? Definitions a model can lift in one paragraph, comparisons, pricing signals, FAQ blocks whose markup matches the visible text word for word. The technical half of this is markup discipline; the rest belongs to content strategy and is not this page.
what you actually receive
Files, not advice. Every item below arrives as something a developer applies without having to interpret it:
- llms.txt — written for your site, with the disambiguation paragraph and the page map, ready to upload.
- JSON-LD blocks — the full graph with identifiers already wired, validated, ready to paste.
- Server config — redirects, canonical host, security headers, cache policy, as a config fragment for your stack.
- Crawler rules — robots.txt and, where the block lives on the CDN edge rather than in your repo, the exact setting to change.
- Rendering findings — which routes come back empty to which agent, with the request we used, so your team can reproduce it in one command.
- Core Web Vitals — the render chain that explains the numbers, not just the numbers.
Then we re-check the same things after the work lands, because a fix nobody verified is a claim.
how we check, in the open
The whole readability question is settled by requesting your page the way an engine does and reading what comes back. There is no proprietary tool involved and we are happy for you to run it yourself:
curl -A "GPTBot/1.0" https://your-site.com/
If what returns is a shell, a redirect loop or a 403, no amount of content strategy above it matters. That command is also why our audits disagree with tool reports so often: tools render like browsers, engines frequently do not.
the four checks that settle most arguments
Before any opinion about strategy, four requests tell you whether the technical layer is working. All four are things you can run yourself in a few minutes, and we run them on every audit.
| check | what you do | what a failure looks like |
|---|---|---|
| crawler fetch | Request your key pages with each AI user-agent and read the response body. | A shell, a redirect loop, a 403, or a body far shorter than the page a browser shows. |
| rendered vs raw | Compare the raw HTML against what the browser paints. | The text your buyers read exists only after JavaScript runs. |
| entity resolution | Ask an engine to describe your company, then check every fact it states. | It confuses you with a similarly-named company, or hedges because it cannot verify you. |
| markup parity | Validate your JSON-LD, then compare it against the visible page. | Schema claims things the page does not say — ratings without reviews, FAQ answers that differ from the text. |
The last one matters more than it sounds. Markup that contradicts the page is worse than no markup: it is the fastest way to have your structured data discounted entirely, and we have found it on sites whose SEO reports were clean.
llms.txt, without the hype
It is a small file and it attracts big claims, so here is the sober version. There is no evidence it acts as a ranking lever. What it reliably does is give you one place, in your own words, to state what your company is, which pages matter, and which of the things sharing your name are not you.
That last part is why we treat it as mandatory rather than optional. Name collisions are the most common entity failure we see, and they are invisible to every SEO tool. A file that says plainly “we are X, we are not Y, Z or W” is the only cheap, machine-readable correction available.
Ours contains a disambiguation section for exactly this reason: our own domain carries a history that engines were quoting back at us. We wrote the correction, published it, and it is the section we point to most often.
What makes a bad llms.txt: a dump of every blog URL, no description, no disambiguation, and a stale page list. In our dataset that was the usual state of the file where it existed at all.
the entity graph, in plain terms
Structured data is not a checklist of types to add. It is one graph describing one company, and the value comes from the connections rather than the volume.
Three rules cover most of it. One organisation node, with a stable identifier, referenced by everything else instead of re-described on each page. Real external references in sameAs, pointing at profiles that actually exist — an empty array is honest, a fabricated one is worse than nothing. And agreement across the machine-readable surface: the same company name, the same founding year, the same description in the markup, in the llms.txt and on the profiles.
The failure we see most is not missing markup but disconnected markup: an Organization on the homepage and a separate publisher on the blog, unlinked, describing the same company slightly differently. To a parser that is two weak entities instead of one strong one.
rendering: what to change and what not to
The instinct after a bad crawler check is to rebuild the site. That is almost never the answer.
What matters is that the routes buyers ask about return their content in the initial HTML response. On most stacks that is a rendering setting, not an architecture: server-side rendering or prerendering on the pages that carry the claims, and leave the app-like interior alone. Documentation, pricing, comparison and trust pages first — those are the pages engines quote.
Two things not to do. Do not serve crawlers different content from users; it is fragile and it is the kind of trick that gets a domain discounted. And do not block a crawler to save bandwidth without deciding, out loud, that you are also giving up your version of the story in AI answers.
where this sits in the work
Technical GEO is the first sprint of the full-cycle program, and it is scoped by the audit that precedes it — there is no useful way to quote or plan this work without seeing what is broken first. The audit is manual, it is complimentary, and it ends with a dated plan in priority order.