Making your site legible to AI search
A meaningful share of research now happens inside an assistant rather than a results page. The good news is that almost everything that makes a site legible to those systems is something you should have been doing anyway.
What changes, and what does not
It is tempting to treat AI search as a new discipline requiring new tactics. Mostly it is not. The systems that answer questions in ChatGPT, Gemini, Claude and Perplexity are reading ordinary web pages, and they reward the same things a well-built site has always been rewarded for: clear structure, text that exists as text, accurate metadata, and pages that load.
What does change is emphasis. A traditional crawler is patient and thorough. An assistant answering a question is extracting a specific claim from a page it has partially retrieved, under a token budget, alongside three other sources. Pages that state things plainly and early do measurably better than pages that build to a point.
Put the answer next to the question
The single highest-leverage change is structural. If a heading poses a question, the paragraph immediately beneath it should answer that question in one or two sentences, before any elaboration.
This is how featured snippets have worked for years, and retrieval systems behave similarly — they pull a chunk of text around a matched heading. If that chunk contains the answer, you get cited. If it contains preamble, the system moves to a source that was more direct.
It is also simply better writing, which is a useful property of most real SEO advice.
Make the text actually be text
Content rendered only by client-side JavaScript is a real risk. Google renders JavaScript, if inconsistently and on a delay. Many AI crawlers do not render at all — they fetch the HTML and read what is there.
The test is straightforward: fetch your page with JavaScript disabled and read what comes back. If your services, your prices, your location and your differentiators are missing, then to a meaningful set of systems your site is close to blank. The same applies to text baked into images and to key claims that exist only inside a video.
Describe yourself in structured data
JSON-LD is the one place on a website where you get to state facts about your organisation unambiguously, in a format designed for machines. Who you are, where you operate, what you offer, who founded you, how to reach you, which social profiles are genuinely yours.
Connect the nodes rather than scattering them. A single graph in which your service references your organisation, which references its founder and its location, resolves in one pass. A dozen detached snippets do not describe a coherent entity.
And keep it honest. Marking up reviews you do not have or ratings nobody gave you is a spam-policy violation with a manual-action risk attached, and the systems reading it are increasingly good at cross-checking.
Be specific enough to be worth citing
Generic content has always been weak, but assistants punish it more sharply. When a system is choosing between four sources that all say "we deliver bespoke solutions tailored to your needs", it has no reason to prefer any of them, so it synthesises a generic answer and cites nobody.
Specifics are what make a page citable: an actual timeline, an actual constraint, an actual trade-off, an actual number. This is why the most boring pages on a site — the ones that plainly state what something costs, how long it takes and what it does not include — often turn out to be the most cited.
The unglamorous checklist
One H1 per page that says what the page is. Headings in an order that reflects structure rather than font size. Descriptive link text instead of "click here". Alt text that describes the image rather than repeating a keyword. A canonical on every page. A sitemap that is actually current. Metadata that matches the content beneath it.
None of this is new advice. It is the same advice, made more consequential by readers that are less forgiving of ambiguity than a human skimming a page.