Can AI crawlers read your site?
the rendering problem, measured

Do AI crawlers execute JavaScript?

No. On every public measurement available, the crawlers that build AI answer surfaces fetch HTML, do not run scripts, and read only what arrived in the initial response.

The evidence base is thinner than the confidence with which people repeat it, so here is exactly what it consists of. Vercel and MERJ published a server log study on 17 December 2024, run against nextjs.org and cross validated on two unrelated stacks, one on Next.js and one on a custom framework. They found no JavaScript execution by any major AI crawler. ChatGPT's agents fetched JavaScript files in 11.50% of requests and Claude's in 23.84%, then did nothing with them. The study's stated conclusion was that the crawlers cannot read client side rendered content. Microsoft Copilot was excluded from the study because it does not use a unique user agent.

Since then, every 2026 source that claims to have retested reports the same result, and no credible measurement contradicts it. The weakness worth naming is that most of those 2026 sources are re-citing the December 2024 work instead of re-running it. We label this strong and not confirmed for exactly that reason. It is the right assumption to build on and it is worth re-testing yourself instead of trusting the field's collective memory. We intend to re-run it on our own properties and publish what we get.

None of the three vendors documents rendering behaviour. OpenAI, Anthropic and Perplexity all publish crawler pages describing purpose, user agent strings, IP ranges and robots.txt handling, and all three are silent on rendering. That silence is why the answer has to come from server logs rather than documentation.

Which surfaces render JavaScript and which do not?

Two groups, and the split does not follow company lines. It follows whether the fetcher is a search index crawler or an answer time fetcher.

Read the table with the pipeline in mind rather than the brand. Bing renders and can therefore hand ChatGPT a candidate URL. OAI-SearchBot then fetches that URL itself to pull the sentence it will quote, and it does not render. Being findable and being quotable run through two different fetchers with two different capabilities.

What does an AI crawler actually receive from a single page app?

A shell. Typically a head with your title, meta description and any JSON-LD you injected server side, then a body containing one empty element and a script bundle reference. Every word of your positioning, your proof, your headings and your FAQ lives inside JavaScript that never runs.

That is why this failure is so hard to notice from the inside. Your browser renders it. Your team sees the page. Your screenshot tool sees the page. Lighthouse renders it. Search Console reports on Googlebot, which renders it. Nothing in a normal marketing workflow shows you the crawler's view, and the one tool that would, a raw fetch with a bot user agent, is not in most marketers' hands.

There is also a size tell. Compare the byte count of a route you know is empty against a route you know is full. If they are within a few hundred bytes of each other, the second route is not really there.

What did we measure on our own site?

On 6 August 2026 we fetched every route type on outboundpros.io with the documented GPTBot user agent and recorded what came back. We published the failing rows because a case study with no failures in it is not a measurement, it is an advertisement.

Three things are worth pulling out of that table.

The empty baseline is about 5,179 bytes. Everything in the head, none of the body. That means the 5,519 byte tools route and the 5,669 byte service route each contained roughly 300 to 500 bytes of real content, which is a heading and a sentence. If you are auditing your own site, establish your baseline first, then read every route against it.

Methodology. One curl fetch per route type against the live site on 6 August 2026, using the documented GPTBot user agent string, byte count taken from the raw response body, no JavaScript execution, no cache warming. It measures the first response to a non rendering crawler. It does not measure whether those URLs were subsequently cited anywhere, it does not describe Googlebot's view, and it is one site at one moment. When the parent's prerender coverage is extended, both the before and the after rows stay on this page, because the delta is the more citable asset.

Do you need server side rendering to show up in AI search?

You need real HTML in the first response. Server side rendering is one way to get there and it is usually not the cheapest one.

For most B2B marketing sites the answer is prerender at build, because the content changes when you deploy and not when a user arrives. It is a script, a build hook and an afternoon. The reason so many teams reach for a full server side rendering migration instead is that the problem gets framed as an architecture problem when it is really a delivery problem.

One deployment detail that is easy to miss and expensive to get wrong. Some hosting products serve the client rendered bundle regardless of what your build produced, which means you can add a perfect prerender step and change nothing about what the crawler sees. Verify at the edge, on the live domain, not in your build output.

How do you test your own site with one command?

Fetch your own homepage with the documented GPTBot user agent string and look for your body copy in the response. If what comes back is an empty root element, that is your answer and you are done, because nothing else on a GEO roadmap matters until it changes. The three steps after it exist only to tell you how bad the problem is and which routes carry it, and the whole sequence takes about five minutes.

curl -s -A "GPTBot" https://yourdomain.com/ | head -50

Step 2. Look for your actual words. Not your title tag, not your meta description, not your JSON-LD. Your H1, your subhead, a sentence from the middle of the page. If what you see is an empty root div followed by a script tag, your homepage is blank to every non rendering AI crawler.

for u in "/" "/pricing" "/blog" "/blog/some-post" "/product"; do
  printf "%s " "$u"; curl -s -A "GPTBot" "https://yourdomain.com$u" | wc -c
done

Routes clustered within a few hundred bytes of your smallest result are empty. Routes several times larger are real. Partial coverage shows up immediately in this list and almost never shows up any other way.

Step 4. Repeat with the other documented agents: OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot and Perplexity-User. You are checking two things per agent: a 200 response, and body copy in the payload. A 403 or a challenge page means the block is at your CDN and not in your code, which is a different fix and a common one.

What does extractability not fix?

Passing gate one gets you read. It does not get you quoted, and conflating the two is the most common mistake made by teams who have just fixed their rendering and expect a result.

The 2026 measurement framework published as arXiv 2604.25707, built on 602 controlled prompts and 21,143 search layer citations across ChatGPT, Google and Perplexity, found that the citations with the most influence over an answer were "longer, more structured, semantically aligned, and richer in extractable evidence such as definitions, numerical facts, comparisons, and procedural steps". A perfectly prerendered page of adjectives has nothing in it to lift. Fixing rendering moves you from invisible to eligible, which is a large move and not a finished one.