Can ChatGPT read your website? What the AI crawlers fetch, what they render, and the eleven-word test

ChatGPT, Claude and Perplexity read the HTML their crawlers fetch, and they do not run your JavaScript. Google renders it, so Google's AI Overviews see what Google sees, and Bing's crawler renders too, which is what Copilot reads. If the words on your page only appear after a script runs, the assistants that do not render see a page with a title and almost nothing else. The test takes a minute: view the page source and count the words. We did it on a client's site in September and counted eleven.

Who renders, and who does not

The measurement worth knowing is the one Vercel and MERJ published after instrumenting their own edge network: 569 million fetches by GPTBot and 370 million by ClaudeBot, and neither executed a single script. The crawlers fetched the JavaScript files, which looked like rendering in a server log and was not. Google's own documentation says the opposite for Googlebot, and says in the same page that server-side rendering or pre-rendering is still a great idea. Both are true at once: your site can rank perfectly in Google and be blank to everyone else.

The eleven-word test

1. Open the page in a browser and press Ctrl+U, or put view-source: in front of the address. This is the HTML as fetched, before any script runs.
2. Search the source for a sentence you can see on the page. If it is there, the words are in the HTML. If it is not, they arrive by script.
3. Count the words in the body. A service page should carry hundreds. A page with a title, a few navigation labels and an empty root element is the fault.
4. Repeat for the home page, one service page and one guide, because sites built on a framework often render the home page on the server and the rest in the browser.

A removals and transport firm we look after had a React site built elsewhere. On 2 September 2026 the home page carried eleven words of HTML: the title, the navigation and a footer line. Google ranked it at position 6.8 for its main search, because Googlebot rendered the page and read the eight hundred words that followed. ChatGPT, asked about the firm, had the eleven. The content went into the HTML on 3 September; on 19 September we counted 1,123 words in the source. The clicks moved in the following month, and the case study beside this guide says what did and did not cause that.

The faults that hide the words, even on a rendered site

• A root loading file. On one framework a loading component at the root streams every page inside a hidden container until the script runs. The HTML has the words, inside an element marked hidden, and a crawler that does not render reads them as hidden. We found this on a tuning client's site on 2 October 2026 and it had been live for five weeks.
• Tabs and accordions that mount on click. The first tab is in the HTML; the others are not until someone taps.
• Content fetched after load. A page that asks an API for its own text has nothing in the source but the request.
• A cookie wall rendered in front of the content. The crawler sees the wall's words, not yours, if the wall replaces the page instead of overlaying it.

The fix, by how the site is built

A static site or a server-rendered framework already puts the words in the HTML and needs nothing. A single-page application needs pre-rendering at build time or server-side rendering, so that the first response carries the page. A site builder that renders in the browser has no fix short of moving. The transport firm's fix was a pre-render step in its build, which is why the change took a day and the site stayed where it was.

Google says plainly what not to spend money on: a special llms.txt file, chunking the content, rewriting it for AI, and over-focusing on structured data. The eleven-word test is the thing to do instead, because it is the one most sites fail.

What to put in the HTML, once it is there

Getting the words into the source is the gate; what the words say decides whether an assistant quotes them. Three things do most of the work. An opening paragraph that answers the page's question on its own, with the fact in it, because an assistant lifts a passage rather than a page, and a price page whose first paragraph has no price gives it nothing to lift. A question-and-answer block with the real questions customers ask, in their words. And one page per subject, because a page that covers four services in one scroll is quoted for none of them. None of that is rewriting for AI; it is the same writing that earns a featured snippet, and Google says plainly that unique, useful content moves AI visibility more than anything else on its list.

The test for that, once the eleven-word test is passed, is to read the opening paragraph alone, out of context, and ask whether it answers the question a stranger typed. If it needs the heading above it to make sense, it is not a passage an assistant can use.

robots.txt, and the crawlers that ignore it

Once the words are in the HTML, decide who may read them. GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot and Google-Extended each have a user agent you can allow or block in robots.txt. Three fetchers ignore it because a person triggered them: ChatGPT-User, Google's agent and NotebookLM fetch a page when a user pastes the address, and no file stops that. On our own sites we allow all of them, the training crawlers included, and the file says why: a site that wants to be cited has no reason to hide from the crawler that answers the question. A publisher whose words are the product can reasonably decide the other way.

The AI-readiness pass on our service page runs this test first, because every other item on it is noise if the words are not in the HTML. The free check reads it too. If your source view shows a title and an empty root, that is the finding, and it is a build change rather than a content one.