Site readability
The cheapest work in GEO, and the most commonly skipped.
Your own site is the only source you fully control. If a model cannot fetch it, cannot read it without running JavaScript, or finds it contradicting itself, every other piece of GEO work is discounted when the model comes back to verify.
This stage is mostly small fixes with disproportionate effect. It is also the one that stalls most often, because the changes need an engineer and the engineer has other priorities. Budget the coordination, not just the work.
What is actually handed over.
Everything listed here is a thing you can look at, not a status update.
Crawler access test
Actual requests sent with each AI crawler user agent, with the status codes recorded. Reading robots.txt is not a test.
Rendering check
What remains on each key page with JavaScript disabled.
Structured data plan
Organization, Article, FAQPage and BreadcrumbList, marked only on content that is actually visible.
Fact consistency audit
Company name, founding year, scope, address and phone, compared across every channel they appear on.
An llms.txt
A site index for models: what the organisation is, which pages matter, and what you do not do.
Four steps, in this order.
Order matters — each step produces what the next one needs.
Questions teams ask before they start
Our site was just redesigned. Do we still need this?
Recent redesigns are where we find the most problems, not the fewest. Modern builds frequently render content only through JavaScript and frequently return 200 with the home page for unknown paths — both invisible in a browser and both damaging.
Who implements the fixes?
By default your team, working from the specification we provide. Where you would rather we implement them, that is agreed separately along with the minimum access required.
How long does this stage take?
The audit takes days; implementation depends on your engineering queue. In practice the queue is the constraint, which is why it is worth raising before the engagement starts rather than in week three.
Can this be done on a site we do not control?
The audit can; the fixes cannot. Where the site is run by a third party, we deliver the findings and specification in a form that party can implement, and re-test afterwards to confirm what actually shipped.
Is a redesign needed?
Usually not. Most findings are configuration and markup rather than design: crawler access, server-rendered content, heading structure, structured data, fact consistency. Visual design is out of scope unless it blocks readability.
How do we know the fixes worked?
The same tests are re-run after implementation: crawler requests with recorded status codes, rendering with JavaScript disabled, unknown-path behaviour, and a fact comparison across channels. The before and after results are delivered together.
The other stages
Find out where your brand actually stands in AI answers.
An AI visibility diagnosis across the platforms your customers use, on your real questions. No charge for the first look.