Why AI Search Engines Cannot Read Your JavaScript Website

What it means for a page to render in JavaScript

A server can send finished HTML containing your words, or it can send a near-empty shell plus a program that builds the words once it arrives. The first is server rendering. The second is client-side rendering. Both look identical in a browser, and only one of them is readable by something that does not run programs.

Open any page on your site and use view source rather than inspect. View source shows the raw HTML your server delivered. Inspect shows the document after your browser executed the JavaScript, which is a different thing and the source of most confusion on this topic. Google draws the same line in its own documentation, separating the crawled HTML from the rendered HTML as distinct phases³. If your headline, body copy and navigation are absent from view source and present in the inspector, your content is client-rendered.

This is a normal consequence of how modern sites are built. A framework such as React or Vue is designed to construct the interface in the browser, which produces an application-like experience. That was a reasonable tradeoff when the only machine reading your site was Googlebot, because Google invested in rendering. It became a liability when a new category of readers arrived that had not made the same investment.

The distinction to hold onto is that this is not a content problem or a quality problem. You can have the best page on the internet about your subject and still deliver it as an empty shell. The work is already done; it is simply being handed over at the wrong moment, to an audience that has already left.

Why Googlebot copes with JavaScript and the AI crawlers may not

Google documents that Googlebot renders JavaScript in headless Chromium as a separate queued phase after crawling. OpenAI, Anthropic and Perplexity publish crawler documentation that does not mention JavaScript execution in either direction. That asymmetry, not a vendor announcement, is the real state of the evidence.

Google is explicit about its own process. Googlebot crawls, then places pages returning a 200 status into a rendering queue where headless Chromium executes the JavaScript, then indexes the rendered result³. Google notes that pages may remain in that queue for seconds or longer, which is why client-rendered sites often index slowly even on Google. On the same page Google gives advice that reads differently in 2026 than when it was written: server-side or pre-rendering is still a good idea, because it makes the site faster for users and crawlers, and not all bots can run JavaScript³.

Now the other side. OpenAI documents GPTBot, OAI-SearchBot and ChatGPT-User with their user agents and purposes, and says nothing about JavaScript rendering⁴. Anthropic documents ClaudeBot, Claude-User and Claude-SearchBot in the same way, with no mention of rendering⁵. Perplexity documents PerplexityBot and Perplexity-User, again with no mention⁶. We checked all three in August 2026 rather than taking anyone's summary for it.

The measurement everyone cites comes from a joint study by Vercel and MERJ published on 17 December 2024, which monitored crawler traffic across several months and found no evidence of JavaScript execution by the major AI crawlers, while noting that some downloaded JavaScript files without running them, in 11.50 percent of ChatGPT requests and 23.84 percent of Claude requests⁷. AppleBot and Gemini were the exceptions, both executing JavaScript⁷.

That study is the entire evidentiary basis for a claim now repeated as though it were current. It is more than eighteen months old, no vendor has confirmed or denied the behavior since, and we could find no comparable public re-test. So the accurate position is not "AI crawlers cannot read JavaScript." It is that the only measurement available says they did not, the vendors have never claimed they do, and you are making a decision under uncertainty where one option costs a build change and the other costs total invisibility. That asymmetry decides it.

You can check our side of this in about ten seconds. Use view source on this page and search for a sentence you can see above. It is in the raw HTML, because this site is pre-rendered to static files rather than assembled in your browser. If you want the same check run against your own site along with the rest of the technical picture, the free SEO audit fetches your pages the way a crawler does and reports what came back, and our technical SEO services cover the fix when the answer is bad.

How to see your site the way an AI crawler sees it

Three checks, none requiring a developer. View the raw HTML your server sends, disable JavaScript and reload, and compare what survives. If your headline, body copy and links vanish, you have found the problem, and you found it in under five minutes without any specialist tooling.

The reason this matters more than a tool report is that you will see it yourself. Owners are routinely told their site has a technical problem and have no way to judge the claim. This one is directly observable, which makes it one of the few technical findings you can verify before authorising work on it.

The disabled-JavaScript view is a close approximation of what a non-rendering crawler receives, which is the condition the December 2024 measurement found across the major AI crawlers⁷. Work through the checks on your most valuable page rather than your homepage. Homepages are frequently the best-built page on a site while service and location pages, which are the ones that earn citations, were generated later by a template. The gap between the two is where the damage usually sits.

One caution on interpretation. Seeing some HTML in view source is not a pass. Look specifically for the words that make the page worth citing: the headings, the explanatory paragraphs, the answers. A shell containing your navigation and footer with an empty content area is the exact failure pattern, and at a glance it looks like a page that is working.

1. View the raw HTML. Right click, choose view source, then search the text for a distinctive sentence from your page. Present means server-delivered. Absent means built in the browser.
2. Turn JavaScript off and reload. In Chrome, open settings, search for JavaScript, and block it. Reload the page. What remains is close to what a non-rendering crawler receives.
3. Check the pages that matter, not the homepage. Test a service page and a location page. Templated pages often behave differently from a hand-built homepage.
4. Look for content, not markup. Navigation and footer surviving is not a pass. The headings and body copy have to be there.
5. Repeat after any redesign or platform change. This is a build-configuration property, and it can regress silently when a theme, plugin or framework version changes.

Server-side rendering, static generation, and prerendering explained

All three fixes achieve the same result by different routes: the HTML leaving your server already contains the words. Server-side rendering builds the page per request, static generation builds it ahead of time at deploy, and prerendering bolts a rendered snapshot onto an existing client-rendered app.

Google recommends server-side or pre-rendering on its own JavaScript documentation, on the grounds that it is faster for users and crawlers and that not all bots can run JavaScript³. Static generation is the strongest option when your content does not change per visitor. Pages are built once at deploy time into finished HTML files, so every crawler and every visitor receives complete content immediately, with no rendering step to skip and nothing to wait for. Marketing sites, service pages, location pages and blogs all fit this pattern, which covers the great majority of what a local business publishes.

Server-side rendering suits pages that genuinely vary per request, such as a logged-in dashboard or live inventory. The server assembles the HTML for each visit, so crawlers still receive complete content, at the cost of doing work per request. Most business websites do not need this and choose it accidentally because a framework defaulted to it.

Prerendering is the pragmatic retrofit. Your application stays client-rendered for humans while a service renders each page and serves the finished snapshot to crawlers. It is the least elegant option and the fastest to deploy when a rebuild is not realistic this quarter. The tradeoff is a second system that can drift out of date, so treat it as a bridge rather than a destination.

Whichever route fits, the decision is about where HTML is assembled and not about which framework you chose. React, Vue, Angular and Svelte all support at least one of these approaches, and the meta-frameworks built on them exist largely to make it straightforward. If a developer tells you this requires a rewrite, ask specifically which of the three options they evaluated and why each was rejected.

What this means for content you have already published

If your pages are client-rendered, the content you have already paid for has not been evaluated and rejected by AI systems. It has not been read. That is a better position than it sounds, because the work exists and only the delivery is broken.

Most owners arrive at this topic after a period of publishing that produced nothing. The instinctive diagnosis is that the content was not good enough, so the response is to commission more of it, which produces the same result at greater cost. Establishing that the pages were never readable changes the diagnosis completely, and it changes what you should spend next.

There is a second reason to fix delivery before adding content, and it concerns which surface you are trying to reach. Ahrefs compared 730,000 responses and found only 13.7 percent of citations overlap between Google's AI Overviews and AI Mode⁸, so these behave as separate systems with separate citation sets. Being readable is the shared prerequisite for both. Optimising for either one while the page arrives empty is effort spent on the wrong layer.

Once the rendering is fixed, existing content becomes eligible rather than instantly successful. Retrieval is still competitive, and roughly 15 percent of retrieved pages end up cited¹. What changes is that your pages join the pool. If you want the layer above this one, we covered how AI decides who to recommend separately, and it assumes throughout that your pages can be read.

What to tell your developer

Keep the brief short and outcome-based rather than prescriptive about implementation. The requirement is that the HTML returned by the server contains the page content, verifiable by fetching the URL without a browser. How they achieve it is their decision, and the test is objective.

Write the requirement as an acceptance test, because that is what prevents a six-week discussion about frameworks. The test is: fetch the URL with a plain HTTP request, with no browser and no JavaScript engine, and confirm the response body contains the page heading, the body copy and the internal links. That is checkable by either party, and it does not depend on anyone agreeing about React. It also matches the condition Google names when it advises pre-rendering for bots that cannot run JavaScript³.

Ask for it on the templates that matter rather than the whole site at once. Service pages, location pages and blog posts are where citations are won. A phased fix that covers those first delivers most of the value and is far easier to approve than a full rebuild.

Finally, ask how the requirement will be protected. This is a build configuration, and configurations regress when a framework is upgraded or a theme is replaced. A one-line check in the deploy process that fails the build when a known sentence is missing from the server response costs almost nothing and prevents the silent version of this problem, which is the expensive one.

• The server response for every public template must contain the page heading, body content and internal links.
• Verification is a plain HTTP fetch with no browser and no JavaScript execution.
• Priority order: service pages, location pages, blog posts, then everything else.
• Add a deploy-time check that fails the build if content is missing from the server response.
• Re-run the check after any framework upgrade, theme change or platform migration.

A note on the currency of this guide. The rendering behavior described here rests on vendor documentation checked in August 2026 and on a measurement published in December 2024. Crawler behavior can change without announcement, and none of these vendors has committed publicly either way. We will review this page again by 1 September 2026. The recommendation is deliberately robust to the uncertainty: server-rendered content is readable by every crawler in the table, including the ones that do render.