JavaScript SEO & Rendering: How Googlebot and AI Crawlers Handle JS Pages

On March 4th, 2026, Google removed a warning from its official JavaScript SEO documentation. The “Design for accessibility” section – which recommended keeping pages functional without JavaScript – was dropped with the note that the information had become “outdated and no longer as helpful as before.” Google has been rendering JavaScript for years, so JS no longer makes indexing harder.

That sounds like an all-clear. It isn’t. The question “Can Google render JavaScript?” was largely settled back in 2019. The relevant question in 2026 is: Which crawlers actually reach your JavaScript-generated content? And that’s where things get uncomfortable. While Google has steadily improved its Web Rendering Service (WRS), most AI crawlers – GPTBot, ClaudeBot, PerplexityBot, Bytespider, Meta-ExternalAgent – render no JavaScript whatsoever. None of them.

In my technical audits, I regularly see single-page apps that are indexed correctly by Google but are practically invisible in ChatGPT Search or Perplexity. That is the real JavaScript SEO problem in 2026 – not whether Google can handle it, but who else can keep up.

In this article: How Google’s WRS works technically, what can go wrong in the two-wave crawl, why AI crawlers don’t render JS, and which rendering strategy is right for 2026.

Google’s rendering infrastructure centers on the Web Rendering Service (WRS). The WRS runs a headless Chromium browser to process JavaScript – the same Chromium build that powers Google Chrome. Since 2019, this Chromium build has been “evergreen,” meaning it’s automatically updated to current versions. This means modern JavaScript syntax (ES6+, async/await, Promises, Fetch API) is fully supported.

The crawling process runs in two clearly separated phases:

Phase 1 – HTTP Crawl: Googlebot fetches the raw HTML from the server. No JavaScript, no CSS. Whatever is in the initial HTML at that point is immediately evaluated and used for indexing. Title tags, meta descriptions, canonical URLs, robots meta tags – all are read from this HTML. The 2 MB limit applies here: bytes beyond 2 MB are completely ignored.

Phase 2 – Rendering Queue: Pages containing JavaScript are queued by Googlebot for rendering. Once Google’s resources allow, the WRS renders the page with headless Chromium. Only then does Google see the JavaScript-generated content. How long does it take? Google provides no concrete numbers. In practice, the range spans from a few hours to several weeks – depending on the domain’s crawl frequency, server performance, and available WRS capacity.

What the WRS processes: CSS, JavaScript, XHR requests and API calls. What it doesn’t process: images and videos are not downloaded. This means that with APIs that have long response times, the WRS may abort rendering before content has loaded.

For a detailed look at Google’s overall crawling mechanism – crawl budget, priorities, frequency – see my article on Google crawling and indexation.

When Phase 2 completes successfully, Google sees the fully rendered state of the page. Text, internal and external links, structured data in JSON-LD format (even if the script tag was injected via JS), images with correct alt tags – all of this is indexable. How Google fundamentally parses and processes HTML – before rendering even comes into play – I cover in my article on HTML Parsing & SEO. Native HTML lazy loading (loading="lazy" attribute) is not a problem. Infinite scroll is trickier, but solvable through pagination with correct canonical URLs.

The Classic JS SEO Failures – Still Just as Relevant in 2026

In my technical SEO work, certain patterns keep appearing. The most frequent mistakes:

Setting canonical URLs via JavaScript: Google’s documentation is clear – canonical tags must be in the initial HTML, not set via JavaScript. If the canonical is only set after rendering, Google may treat the wrong URL as canonical – or no URL at all. This is especially critical for e-commerce sites with dynamically generated URL parameters.

Fragment-based routing (#): When your SPA uses fragment URLs (e.g., example.com/#/product/123), Googlebot sees these as a single page with fragments – not as separate pages. The correct solution is the browser’s History API, which generates clean URLs without fragments.

HTTP status codes via JavaScript: 404 pages that are only marked as “not found” client-side but return HTTP status 200 – this is a classic SPA problem. Google sees a 200 page and indexes it as empty or misleading content.

For a detailed overview of common structured data errors, see my article on FAQ Rich Results and schema markup – many of the foundational principles apply equally to JavaScript-generated markup. If you want to know whether structured data provides a specific advantage for AI Overviews, see my piece on structured data and AI Overviews.

This is the part that many 2026 JS SEO articles still overlook: Google’s ability to render JavaScript is the exception – not the rule. The vast majority of crawlers consuming your content work without JavaScript rendering.

An overview of the most relevant AI crawlers and their rendering status as of mid-2026 – individual platform infrastructure can change over time:

* Observation, as of May 2026, no official vendor statement. Since crawler infrastructure can change at any time, site owners should regularly check their visibility in AI-powered search.

What does this mean in practice? ChatGPT and Claude do sometimes download JavaScript files, but they don’t execute them. They typically cannot read content that is only generated in the browser through client-side rendering. If your product descriptions, pricing, or main content are only rendered via JavaScript into the DOM, these crawlers see an empty page – or at best the HTML skeleton.

In my work with clients, this is no longer an abstract problem. At an e-commerce client running a Vue.js SPA without SSR, GPTBot traffic was simply zero. Not because the content was poor, but because GPTBot couldn’t see anything. Indexation in ChatGPT Search was effectively non-existent.

How AI crawlers affect overall traffic and visibility is a topic that goes beyond the scope of this article. Relevant in this context: Google has introduced a dedicated user agent for AI agents – what that means, I cover in my article on the Google user agent for AI agents. If you want to make your content specifically visible for AI searches, see the llms.txt guide. And how Google weights its algorithm for AI-powered search is covered in my piece on the Google algorithm: crawling, indexing and ranking.

The four common rendering approaches differ fundamentally in where and when HTML is generated (technical background: web.dev: Rendering on the Web):

Client-Side Rendering (CSR)

The browser receives a minimal HTML page with an empty <div id="app"></div>. JavaScript loads, executes, and only then generates the visible content. This is the classic SPA approach with React, Vue or Angular without server-side rendering.

For Google: Works after Phase 2 – but with delays and crawl budget costs. For all other crawlers: Usually invisible.

Server-Side Rendering (SSR)

The server renders the page fully on each request and delivers complete HTML. Next.js, Nuxt.js and Remix support SSR natively. Every crawler – Google, GPTBot, ClaudeBot – immediately receives complete HTML.

Downside: Server load under high traffic. Upside: Best crawlability for all bots, no rendering queue problem.

Static Site Generation (SSG)

HTML is generated once at build time and served as a static file. Astro, Next.js (getStaticProps), Nuxt.js (nuxt generate) or 11ty are typical SSG tools. Maximum performance, perfect crawlability for all bots, no server-side rendering overhead.

Limitation: Dynamic content (user-specific, real-time data) requires client-side loading or ISR.

Dynamic Rendering

Middleware detects crawlers via user agent and delivers statically pre-rendered HTML only to bots. Regular users receive the SPA. Since Google recommends SSR frameworks, dynamic rendering is officially a migration workaround – not a preferred approach for new projects.

The problem with dynamic rendering for AI crawlers: many AI bots aren’t included in standard bot-detection lists. You’d need to manually add GPTBot, ClaudeBot, PerplexityBot etc. and update the list as new crawlers emerge. That’s maintenance-heavy and error-prone.

The framework doesn’t determine SEO success or failure. The rendering configuration does. That said, there are clear differences in how easily a framework enables good rendering:

Next.js is the market leader for React-based SSR and SSG projects. App Router, Server Components, getStaticProps and ISR (Incremental Static Regeneration) offer granular control over what gets rendered server-side versus client-side. Technically very strong for SEO when rendering modes are used deliberately – not on autopilot.

Nuxt.js is the Vue.js equivalent of Next.js and equally capable in rendering flexibility. SSR, SSG and hybrid modes are natively supported. The natural choice for teams with a Vue background.

Astro takes a different approach: “Islands Architecture” or “Partial Hydration.” By default, static HTML pages are served without any client-side JavaScript. JavaScript is only loaded where interactive components actually need it. From an SEO perspective – and especially from an AI crawler perspective – this is the cleanest approach. Downside: highly dynamic applications are more complex to build with Astro.

Remix is strongly oriented toward web standards and native browser APIs. Server-side rendering is the default. A very solid choice for content-driven sites.

Angular (without Universal) and plain React/Vue without SSR are no longer a viable option for SEO-relevant projects in 2026 if content needs to be visible to AI crawlers.

One technical aspect that often gets underestimated: oversized JavaScript bundles can cause timeouts during WRS rendering. The Googlebot 2 MB crawl limit applies to external resources too. Bundle splitting and code splitting are therefore not just performance optimizations – they’re directly SEO-relevant.

Google has removed an outdated note from its documentation: the browser quick-check where you disabled JavaScript to see what Googlebot sees. That was a widespread method for years – it’s now outdated. The correct workflow:

URL Inspection Tool in Search Console: Returns the rendered HTML that Googlebot last saw, including a screenshot. Click “View tested page” – there you’ll see exactly which resources were loaded, which errors occurred, and how the page looks rendered. This is the most direct signal Google offers.

Rich Results Test: For JSON-LD validation and structured data verification. Shows whether Google can read your markup – whether it’s directly in the HTML or injected via JavaScript.

Lighthouse in Chrome DevTools: Provides performance metrics (LCP, CLS, INP) and shows how JavaScript rendering affects Core Web Vitals. High JavaScript execution times directly translate into poor INP scores. A complete optimization guide for all three metrics is in my article on Core Web Vitals: LCP, INP & CLS optimization.

Log file analysis: Server logs show when Googlebot crawls your pages (Phase 1) and when the WRS returns for rendering (Phase 2 – identifiable by the different user agent string of the Googlebot renderer). Large gaps between Phase 1 and Phase 2 signal that your pages are being given low priority in the rendering queue.

For broader technical SEO monitoring – including Core Web Vitals, crawl budget management and indexation status – see my articles on Google crawling and the indexation process.

Google’s decision to drop the “disable JavaScript” recommendation from its docs is a signal: the war “Can Google render JS?” is won. Anyone who has migrated their stack to SSR or SSG in recent years is in good shape.

The new front is AI search. And there, the answer to the rendering question is still a clear no for most bots. In my work with clients, I see how underestimated this point is – especially in teams with a strong developer background who argue “but Google renders it.” True. GPTBot doesn’t. Perplexity doesn’t. And that’s becoming increasingly traffic-relevant.

The action framework for 2026 is clear: SSG as default for content-heavy pages, SSR where dynamic content is needed, client-side JavaScript only for interactive elements – never for content-relevant material. Dynamic rendering only as a migration workaround for legacy SPAs, not as a new-build approach.

Last updated: mid-2026. In particular, the information about JavaScript rendering behavior of AI crawlers is based on observation and may change as crawler infrastructure evolves. Recommendation: regularly audit AI search visibility via log analysis or dedicated crawler testing.