Modern websites often look complete in a browser while sending almost nothing to the bots that read them. A product page might load its description, pricing, and reviews through scripts after the first response arrives. Google has spent years learning to render that content. Many AI bots haven’t. For teams that built their JavaScript SEO around Google’s rendering, this creates a blind spot: pages that rank well in search can be nearly empty to the systems that write AI answers.
Testing for the problem takes a few minutes, and the fixes are well understood.
Raw HTML and Rendered HTML Are Two Different Pages
Every page exists in two versions. The raw HTML is what the server sends first. The rendered HTML is what appears after the browser runs all the scripts. On a traditional site, the two are nearly identical. On a site built with client side rendering, the raw version may contain little more than a page shell, a loading message, and links to script files.
Search engines that render pages see the finished version. Bots that only read raw HTML see the shell. Strong JavaScript SEO has always meant reducing the gap between those two versions, and AI search has made that gap far more costly, because a page that sends an empty shell gives an assistant nothing to read, summarize, or cite.
What Bot Studies Have Found
The clearest evidence comes from a study published in December 2024 by the hosting company Vercel, which analyzed AI bot traffic across its network. It found that the bots used by OpenAI, Anthropic, Perplexity, Meta, ByteDance, and Common Crawl did not render JavaScript. Some of them downloaded script files, about 11.5 percent of ChatGPT’s requests and nearly 24 percent of Claude’s, but they did not run them.
Two exceptions stood out. Google’s Gemini relied on Googlebot’s infrastructure, which renders pages, and Applebot used a browser based crawler that also rendered content. The same study found that ChatGPT and Claude hit missing pages far more often than Googlebot, with about 35 percent of their fetches returning 404 errors compared with roughly 8 percent for Googlebot.
Bot behavior can change as these companies update their systems, so the findings are best treated as a snapshot. The safe assumption for now is that any content requiring scripts to appear may be invisible to most AI assistants.
Four Tests Anyone Can Run
View the page source
Open the page in a browser, then choose “View Page Source” rather than the inspect tool. The source shows the raw HTML. Use the browser’s search to look for a sentence from the main content, a price, or a product name. Content missing from the source is content many AI bots never receive.
Turn JavaScript off
Most browsers let users disable JavaScript in their settings or through developer tools. Reload the page with scripts disabled. Whatever disappears is what script dependent bots lose. Blank sections, endless loading spinners, and missing navigation are all warning signs.
Fetch the page as a bot would
A command line request returns exactly what the server sends, with no rendering. Developers can run a request like this and search the output for key content:
curl -A "OAI-SearchBot" https://example.com/product-page
Using an AI bot’s user agent also reveals whether a firewall or security service treats that bot differently from a regular visitor.
Compare with Google’s rendered view
The URL Inspection tool in Google Search Console shows the HTML Google saw after rendering. Comparing it with the raw source highlights exactly which content depends on scripts. A large difference means Google sees one page while most AI bots see another. SEO Sets runs a similar check automatically, reading the raw HTML an AI bot receives and flagging pages where the main content is missing.
Patterns That Hide Content From AI Bots
Some development patterns cause this problem far more often than others.
| Pattern | What a bot without JavaScript sees | Practical fix |
|---|---|---|
| Single page application with client rendering | An empty container and script links | Server side rendering or static generation |
| Product details loaded from an API after page load | A page shell with no prices or specs | Include key data in the initial HTML |
| Reviews loaded by a third party widget | No reviews at all | Render a summary of ratings on the server |
| Tabs and accordions filled by scripts on click | Only the first visible section, or nothing | Place all tab content in the HTML and hide it with CSS |
| Infinite scroll for article lists | Only the first few items | Add paginated links that work without scripts |
| Navigation built entirely in JavaScript | No internal links to follow | Use standard HTML links for menus |
The common thread is simple. Anything important to the page’s meaning should exist in the HTML the server sends, even if scripts later enhance how it looks or behaves.
Metadata deserves the same attention as visible content. Title tags, meta descriptions, canonical tags, and structured data are sometimes injected by scripts after the page loads, especially on sites using tag managers or client side routing. A bot reading only raw HTML may then see a generic title, no description, and no schema at all. Checking the page source for these elements takes seconds and often reveals problems that visual testing misses entirely.
Choosing the Right Fix
The best solution depends on the site’s framework and how often content changes.
Server side rendering generates the full HTML on each request, which suits pages with frequently changing content such as pricing or inventory. Static generation builds pages ahead of time, which suits blogs, documentation, and marketing pages. Many modern frameworks, including Next.js, Nuxt, and Astro, support both approaches and allow teams to choose page by page.
For sites where a full rebuild isn’t practical, prerendering is a middle path. A service or build step generates static HTML snapshots of script heavy pages and serves them to bots. Progressive enhancement offers the longer term answer: deliver complete content in HTML first, then use JavaScript to improve the experience rather than create it.
After any fix goes live, test again with the same four methods. Changes made in a staging environment don’t always survive deployment, and a quick retest prevents months of assuming a problem is solved. SEO Sets can re-read a live page on demand and report which readiness factors improved, which confirms whether a fix actually reached production.
Questions Teams Ask About Rendering and AI Bots
Does Google still render JavaScript?
Yes. Googlebot renders pages, although rendering can happen later than the initial crawl. AI Overviews draw on Google’s index, so they benefit from that rendering.
Is client side rendering always a problem?
No. It works well for interactive features, dashboards, and logged in areas. The issue arises only when public content that should be cited depends on scripts to appear.
Which pages should be fixed first?
Start with pages buyers ask assistants about: product pages, pricing, comparisons, and key guides.
The Bottom Line on Rendering
AI assistants can only cite what they can read, and many of them still read only raw HTML. JavaScript SEO in 2026 means making sure the content that matters most appears before any script runs, so Google, AI bots, and people all receive the same complete page.
A few minutes of testing reveals whether a site has this problem, and the fix is usually a rendering change rather than a content rewrite. SEO Sets checks whether key content appears in the raw HTML AI bots receive and tracks how often major assistants cite a site over time. View the source of your five most important pages today and search for the sentences you most want an assistant to quote.
