Most AI Crawlers Still Don't Render JavaScript in 2026 - And It's Not Even Close
A recurring claim has been making the rounds in 2025-2026 AI-SEO writeups: the major AI crawlers have caught up to Googlebot, they render JavaScript now, and your single-page app is fine. On the evidence available in Q2 2026, it is wrong almost everywhere it matters. None of the AI-native crawlers - OpenAI's three, Anthropic's three, Perplexity's two - render JavaScript by their own vendor documentation. The only confirmed renderers in the AI-relevant set (Googlebot, Applebot) are pre-existing search-engine crawlers reusing infrastructure built years before generative AI existed.
Key Takeaways
- Vendor documentation through Q2 2026 confirms that GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, PerplexityBot, Perplexity-User, Bytespider, and CCBot do not execute JavaScript. Googlebot and Applebot are the only AI-relevant crawlers that ship a full renderer. Bingbot's rendering is limited and Microsoft itself recommends server-rendered HTML. A November 2025 SEJ analysis of AI crawlers found that AI crawlers cannot execute most JavaScript and cannot see dynamically loaded content - client-side rendered content is invisible to them. OpenAI's official documentation states it directly: its crawlers cannot render JavaScript and only see the initial HTML response.
- Onely's February 2026 analysis found that 42% of JavaScript-rendered content never gets indexed by AI systems - the largest quantified estimate of the visibility gap published to date.
- User-triggered crawlers (ChatGPT-User, Claude-User, Perplexity-User) explicitly avoid JS execution. The likely reason is per-fetch latency cost inside chat responses - the "user-triggered means headless browser" hypothesis is wrong, and fast/lightweight is consistent across both training and retrieval cohorts.
- Google-Extended is a real separate Google crawler - confirmed by Google's own crawler list and Martin Splitt's 2025 disclosure - that uses the same Web Rendering Service as Googlebot and crawls pages for Gemini AI training. Blocking it via robots.txt excludes your content from Gemini training without affecting Google Search indexing. Applebot-Extended functions as an opt-out signal for Apple Intelligence training, not as a separate crawler.
- Vendor-confirmed traffic-share breakdowns by engine are not consistent enough to anchor a hard percentage, but the structural pattern is unambiguous: the dominant generative-AI products operate retrieval through non-rendering crawlers by deliberate architectural choice.
The Per-Crawler Rendering Map
| Crawler | Renders JS? | Source |
|---|---|---|
| GPTBot | No | OpenAI docs |
| OAI-SearchBot | No | OpenAI 2026 docs |
| ChatGPT-User | No | OpenAI 2026 docs |
| ClaudeBot | No | Anthropic Feb 2026 docs |
| PerplexityBot | No | docs.perplexity.ai |
| Perplexity-User | No (same engine as PerplexityBot) | docs.perplexity.ai |
| Bytespider | Unknown | No vendor documentation |
| CCBot | No | SEJ AI crawlers analysis, Nov 2025 |
| Claude-User | Unknown | Not documented in vendor docs |
| Bingbot | Partial / limited | Microsoft docs |
| Googlebot | Yes (headless Chromium) | Google docs |
| Applebot | Yes | Apple docs |
| OAI-AdsBot | Unknown - vendor silent | OpenAI docs |
| Claude-SearchBot | Unknown | Not documented in vendor docs |
| Google-Extended | Yes (WRS, AI training only) | Google docs; Martin Splitt |
| Applebot-Extended | Opt-out token | Apple docs |
Seven crawlers confirmed non-rendering, one partial, three yes (Googlebot and Applebot as pre-existing search crawlers, plus Google-Extended for AI training), four with undocumented rendering status, and one opt-out token. We documented the full taxonomy - who launched what and when - in our companion piece on AI crawler blocking through Q3 2026.
The Googlebot-Gemini exception runs deeper than the table suggests. Martin Splitt confirmed in 2025 that Gemini AI uses the same Web Rendered Service (WRS) as Googlebot - the same headless Chromium infrastructure Google has maintained since 2015. Both Googlebot and Google-Extended share this rendering pipeline, which is why Google's AI products can process JavaScript-heavy sites in ways that ChatGPT, Claude, and Perplexity cannot. This is a structural infrastructure advantage, not a crawl-time policy choice, and it is unlikely to close for the AI-native vendors in the near term.
Why User-Triggered Crawlers Don't Render Either
Here is the intuition most teams arrive at and then defend: "GPTBot is a training crawler, sure, it fetches static HTML. But ChatGPT-User fires when a real human asks for my page in real time. That has to be a headless browser, because the model is sitting there waiting." For OpenAI's ChatGPT-User and Perplexity's Perplexity-User, the intuition is wrong - confirmed by their own documentation. Anthropic's Claude-User rendering behavior is not documented by Anthropic, but the structural argument below applies across all three vendors.
The most likely reason is latency cost, not engineering capability. Every one of these vendors could ship a headless Chromium with their user-triggered crawler. What is harder to absorb is the per-page render wait inside the chat response: each rendered page adds non-trivial time on top of the model's own latency budget, and the user is sitting there waiting. No vendor has published a latency budget for user-triggered fetching, but the consistency of the architectural choice across OpenAI, Anthropic, and Perplexity points at a shared constraint of this shape. Google and Apple can renderer-fetch because their renderers are shared infrastructure paid for by organic search; the AI-native vendors had to choose, with a blank slate, and they all chose the same way.
What This Means for Single-Page Apps
If your primary content arrives via client-side JavaScript - the React/Vue/Svelte/Angular SPA shipped between 2018 and 2024, with content loaded by fetch() after the initial HTML response - the page that GPTBot, PerplexityBot, and ClaudeBot see is the empty shell. The <div id="root"> is empty. The headline, the article body, the product description, the schema markup - none of it is in the markup the crawler stores. The model, asked later to answer a question that would have referenced your content, has nothing in its index that matches.
The scale of the problem is not theoretical. Onely's February 2026 analysis put a number on it: 42% of JavaScript-rendered content never gets indexed by AI systems. That is not a rounding error or a fringe edge case - it is the majority-plus outcome for content that only exists in the rendered DOM. A 2025 Sitebulb survey of 295 SEO professionals found that 33.9% believe none of the LLM crawlers render JavaScript and another 29.8% had no idea - meaning the majority of practitioners have either correctly identified or are unaware of the gap, but few are treating it as a solved problem.
The remediations are the same ones the SEO community has been recommending since 2015 for Googlebot reliability, with the bar raised:
- Server-side rendering (SSR) - Next.js, Nuxt, SvelteKit, Remix, etc., with primary content in the initial HTML response.
- Static site generation (SSG) - pre-rendered HTML at build time. The same shape, more aggressive caching.
- Hybrid / island architectures - server-rendered shell with client-side hydration, but with all citation-relevant content in the HTML.
- Edge rendering / streaming SSR - pre-render at request time at the CDN edge.
What changes in 2026 is not which patterns work - those are unchanged - but how confidently you can skip them. "Googlebot renders JS pretty well, we can probably get away with CSR" was a defensible cost trade-off until 2024. The AI-cohort crawlers that now drive the bulk of AI referral traffic do not render. The trade-off no longer favors deferral.
How Our Audit Treats This
Our audit applies one of its largest non-indexing-related penalties when the AI-visibility surface of a page depends on JavaScript-injected content - when the headline, primary copy, structured data, or main article body is absent from the raw HTML response and only appears after client-side execution. We rebalanced this weight in Q1 2026 specifically because the AI cohort is the traffic that matters now, and the AI cohort does not render. If your site's main content is JS-rendered, an audit will surface it as such, with the SSR/SSG migration path as the recommendation.
A 5-Minute Self-Check for Your Own Site
You do not need an audit tool to find out whether your site has the JS-only-content problem.
- Open the page (homepage, top blog post, top product page) in a browser.
- View Source (Ctrl/Cmd-U) - the raw HTML the server returned, exactly what a non-rendering AI crawler sees.
- Search the source for your headline, the first paragraph of body text, and any structured data (
application/ld+json). - If both are in the source, you are server-rendering (or pre-rendering at build). AI crawlers see your content.
- If View Source shows an empty
<div id="root">or a page shell with no actual copy, your site is client-side rendered and the non-rendering AI crawler cohort is currently storing an empty shell.
For a bypass-the-browser confirmation:
curl -A "GPTBot" https://your-domain.com/your-page | grep "your headline text"
If grep returns the line, your headline is in the raw response and AI crawlers see it. If grep returns nothing, your headline is being injected later by JavaScript.
What This Doesn't Mean
Five caveats, because the contrarian claim is narrower than it sounds.
- JavaScript is not forbidden. Interactive widgets, analytics, sign-up flows, configurators, comments, chat - all of that runs on the client and should. The argument is specifically about the primary content the page exists to communicate: headline, article body, product description, structured data.
- Googlebot has not stopped rendering. Google still renders. The point is that Google Search is no longer the only ranking surface, and ChatGPT Search / Perplexity / Claude Search explicitly do not render.
- Dynamic content is not the problem. A news homepage that updates every five minutes is fine. The question is who renders it into HTML - your server (good for AI crawlers) or the user's browser (invisible).
- Not every SPA page is broken. If your SPA pre-renders critical pages at build time, or if your hosting layer SSRs the cited routes, those pages are fine. The check is per-page, not per-framework.
- "Unknown" cells mean unknown, not yes. Claude-SearchBot and OAI-AdsBot have no published rendering behavior. Treating them as renderers is wishful; treating them as non-renderers is the conservative bet that matches every other crawler from the same vendors.
Run a free audit at hybridranking.com on your homepage or a top article to see whether the shell-and-no-content pattern is showing up in your raw HTML. The JS-rendering signal is one of 99 checks the audit evaluates per page - heuristic on SPA-framework markers plus raw-HTML word count, not a literal raw-vs-rendered DOM diff, so it covers the common case rather than every edge case. AI-assistant workflow: the same check catalogue is callable as native tools from Claude Desktop and Cursor - we shipped an MCP server so the assistant can pull our current weighting straight into your chat.
Sources
- OpenAI bot documentation
- Anthropic clarifies its three Claude bots - Search Engine Land, Feb 2026
- Perplexity Crawlers - official docs
- What AI Sees When It Visits Your Website - Search Engine Journal, Nov 2025
- 68 Million AI Crawler Visits Show What Drives AI Search Visibility - Search Engine Journal, Apr 2026
- Semantic SEO for AI Search: The Enterprise Guide to Citation-Driven Visibility - Onely, Feb 2026
- Gemini AI Renders JavaScript Like Googlebot: Martin Splitt - StanVentures, 2025
- JavaScript SEO Report 2025: Survey & Audit Data - Sitebulb