What makes a website readable by AI assistants, not just by Google
An assistant cannot quote a page it has to run JavaScript to read. Most of this is build decisions, not writing.
An AI-readable site serves its content in the HTML rather than assembling it in the browser, uses headings that match the questions people ask, keeps each passage self-contained, and states the same facts consistently everywhere. Most of that is decided when the site is built rather than when it is written.
Key takeaways
- If content only appears after JavaScript runs, assume some crawlers will not see it.
- Self-contained passages get quoted; passages that depend on the paragraph above them do not.
- Facts stated differently on different pages make a site a weaker source than one that repeats itself.
- Structured data describes what a page is, and it must match what the page visibly says.
- This is mostly build work, which is why it belongs in the website brief rather than in a content plan.
The difference between being crawled and being usable
A search engine indexes a page so it can rank it. An assistant retrieves a passage so it can answer with it. Those are different jobs and they reward slightly different things, which is why a site can rank reasonably and still never be quoted.
Ranking rewards the page as a whole. Being quoted rewards the paragraph: a self-contained chunk that makes sense lifted out of its surroundings, attached to a heading that matches the question. A page can be excellent and still be built in a way that produces no cleanly extractable passage anywhere.
We have written about the content side of this in answer engine optimisation and writing RAG-friendly content. This piece is about the other half, which is how the site is built, because no amount of good writing survives a page that cannot be read without running a browser.
There is a second difference worth understanding. A ranked link sends a visitor to your page, where your design, your proof and your call to action all get a chance to work. A quoted passage answers the question where the person is standing, and they may never arrive. That is an uncomfortable trade and it is not optional: the alternative to being quoted is a competitor being quoted instead. What it does change is what a page should contain, because a passage that answers completely and names who answered it is doing more for you than one that withholds the answer to earn a click.
Serve the content, do not assemble it in the browser
This is the single biggest build decision. If the words only exist after JavaScript has run, then whether they are seen depends entirely on whether the thing fetching the page executes JavaScript, and many do not.
Google renders JavaScript, with a delay and a cost. Several other crawlers do considerably less. OpenAI documents its crawlers and Perplexity documents its own, and the safe assumption for anything outside Google is that what is in the initial HTML is what exists.
The practical rule is simple and it is a framework decision rather than a preference: the text a reader sees should be in the HTML that arrives from the server. Interactivity on top of that is fine. Content that only exists after a fetch in the browser is content you are gambling on.
A practical way to check your own site without any tooling: fetch a page the way a simple crawler would, without running scripts, and read what comes back. If the main content of the page is in that response, you are in good shape. If what comes back is a shell with a loading message, the content is being assembled in the browser and anything that does not run a browser sees the shell. That check takes a minute and settles the question more reliably than a discussion with whoever built it.
Structure the page so passages can be lifted out
Once the content is in the HTML, the question becomes whether any part of it stands alone. This is where most sites lose, and it is a structural habit rather than a technical one.
One habit makes most of this automatic: write each section as though it were the only thing a reader would see. That single constraint produces headings that match questions, answers that arrive early, and subjects that are named rather than implied, because a section written to stand alone cannot rely on anything around it. It also produces a better page for a human skimming on a phone, which is the usual sign that an optimisation is sound rather than a trick.
- A heading that matches how someone would ask the question, rather than a clever label.
- The answer in the first sentence or two under that heading, not after three paragraphs of preamble.
- No dependence on the previous section for the subject: say what is being discussed rather than "it".
- One idea per paragraph, so the paragraph is a complete unit.
- Specifics named in full the first time in each section, including places, products and standards.
- A real heading element rather than a styled bold line, so the structure exists in the markup.
Say the same thing everywhere
Consistency is the quietest of these and matters more than it looks. An assistant assembling an answer about a business is drawing on several pages, and sometimes on sources elsewhere. Where those disagree, the result is lower confidence and a weaker chance of being used.
So the plain facts should be stated identically wherever they appear: the company name in one form, the address in one format, the phone number written the same way, the service names consistent between the navigation, the page headings and any structured data. A business that calls the same service three things across three pages has made itself harder to describe.
This is unglamorous work and it is one of the few things fully within your control. It also helps ordinary search, which is the general theme: almost nothing here is a trick, and Google's own position is that its AI features run on the same core systems rather than on separate rules.
The same applies beyond your own site. Where your business appears in a directory, a professional listing or a partner's page, those entries are part of what an assistant draws on. An address that differs between your site and a listing is the kind of small inconsistency that makes a description less certain, and tidying the handful of listings that exist is cheap work with a disproportionate effect on how confidently anything can describe you.
Structured data, and the rule about matching
Structured data describes what a page is in a form a machine reads without interpretation: this is an article, this is an organisation, this is a list of questions and answers. Schema.org is the vocabulary.
The rule that matters is that it must describe what the page visibly says. Marking up questions that do not appear on the page, or an address that differs from the footer, is worse than not marking up at all, because an inconsistency between the markup and the page is exactly the kind of signal that makes a source less trustworthy.
What is worth adding for most business sites is modest: the organisation, the pages themselves, articles where they exist, breadcrumbs, and questions and answers where the page genuinely has them. Beyond that the returns fall away quickly, and the temptation to mark up things that are not really there grows.
A note on what not to mark up. Review and rating markup is the most requested and the most abused, and it should only ever describe reviews that genuinely exist and are visible on the page. Marking up ratings a business has invented is both a policy violation and the kind of thing that is checked. If the reviews are not there, the honest answer is to go and earn some rather than to describe some.
Let the crawlers in, and say where things are
None of this matters if the crawlers are blocked. Robots files accumulate rules over the years, and a rule added during a staging phase has a way of surviving into production.
Worth checking explicitly: that the assistants' crawlers are allowed, that the sitemap is listed, and that nothing broad is disallowed by accident. Each operator documents its own crawler, which is why the robots file should be reviewed against those documents rather than against a template copied from elsewhere. We covered the detail of this, including what llms.txt is and is not, in llms.txt and AI crawlers.
There is a decision to make rather than a default to accept. Allowing these crawlers is what makes citation possible; blocking them prevents training and citation together. Either is defensible, and the mistake is making the choice accidentally through a rule nobody remembers adding.
Two mechanical checks are worth doing at the same time. Confirm the sitemap is current and actually lists the pages you care about, since an outdated sitemap quietly stops new pages being discovered. And confirm that pages return the status code they should: a page that is gone should say so rather than returning a soft error page that looks like content, because a crawler cannot tell the difference between an empty page and a page that is simply thin.
Why this belongs in the build, not the content plan
Almost everything above is decided when a site is built. Whether content is server-rendered is a framework choice. Whether headings are real headings is a template decision. Whether structured data exists and matches is built into how pages are generated. Whether the same facts appear consistently depends on whether they come from one place or are typed again on every page.
That is why asking for it after launch is expensive and asking for it in the brief is nearly free. It is also why the people writing the content usually cannot fix it on their own, however good the writing is.
The wider positioning side of this, including why being mentioned elsewhere matters more than your own pages, is covered in generative engine optimisation. If you are commissioning a site, the custom website development page sets out how we build, and get in touch if you want an existing site checked against the points above.
If you are not commissioning anything and want to know where an existing site stands, the order to check is: does the content arrive in the HTML, are the crawlers allowed, do the headings match real questions, and do the plain facts agree across pages. Those four take an afternoon between them and they identify whether the problem is fixable in content or whether it is structural, which is the only question that actually changes what you do next.
The ownership side of commissioning any of this is covered in what handing over the code should mean.
Frequently asked questions
No. The requirement is that the content arrives in the HTML from the server, not that the page is static. Interactivity layered on top of content that is already there is fine. What causes problems is a page that arrives essentially empty and fills itself in the browser, because anything that does not run JavaScript sees nothing.
No, and anyone selling one is mistaken. Google states that its AI features run on the same core ranking and quality systems as ordinary search, so the levers are the familiar ones: helpful content, clean indexability and clear structure. Structured data helps a machine understand a page, but it is not a switch that produces citations.
Short enough to be lifted whole and long enough to be complete on its own, which in practice is a couple of sentences directly under the heading. The test is whether the passage still makes sense with everything around it removed. If it starts with "it" or "this", it fails that test and needs its subject named.
It costs little and it is not required by anyone. Treat it as an optional extra rather than a priority, and make sure the basics are right first: content in the HTML, crawlers allowed, sitemap listed, facts consistent. A site that gets those wrong is not helped by an additional file describing it.
No, and that is rather the point. Everything described here is ordinary good practice: content the crawler can read, clear headings, consistent facts, accurate structured data. There is no version of this that helps assistants and harms search, which is a useful sign that it is worth doing.
Often partly. Headings, passage structure, consistent facts and the robots file can all be improved on an existing site. Whether content is server-rendered usually cannot, because it is a property of how the site was built. That is the one to establish before committing to a rebuild or deciding to live with it.
Written by Srinivasan Ramachandran, Founder, Listonics · Published Oct 11, 2026 · Last reviewed October 11, 2026 · 2,064 words
