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), no JavaScript execution was measured for GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot, Bytespider or Meta-ExternalAgent (Vercel/MERJ, December 2024). Not one of them, in that measurement.

In my technical audits, I regularly see single-page apps that are indexable for Google but whose client-side generated content is missing from the initial HTML. That can limit discoverability in AI services. Absent visibility cannot be proven from the rendering method alone. 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, what the measurement data shows about AI crawlers and JavaScript, and which rendering strategy is right for 2026.

For rendering, Google uses a headless Chromium environment. In an SEO context this rendering step is commonly called the Web Rendering Service, or WRS. Since 2019 Googlebot has run on an evergreen version of Chromium that is updated regularly. This means modern JavaScript syntax (ES6+, async/await, Promises, Fetch API) is fully supported.

Google’s search process has three main phases: crawling, rendering and indexing. For JavaScript pages the sequence can be read, in simplified form, as two consecutive processing steps, and that is exactly how Phase 1 and Phase 2 below are meant:

Phase 1 - HTTP Crawl: Googlebot fetches the HTTP response and processes the HTML it contains. JavaScript is not executed at this point; that happens later, in the rendering phase. Whatever is in the initial HTML at that point is immediately evaluated and used for indexing. The initial HTML carries the important signals: links, title tags, meta descriptions, canonical URLs and robots meta tags. They should be present and consistent there wherever possible; Google can still process some of them after rendering. The fetch limit does apply here: each individual fetched URL or resource has a 2 MB ceiling, and bytes beyond it are not fetched, not rendered and not indexed.

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 for rendering: CSS, JavaScript, XHR requests and API calls. The same does not hold in that form for image and video content, and Google’s JavaScript docs make no firm statement about it. For critical media, don’t rely on deferred JavaScript execution; verify it in the rendered HTML instead. If API requests fail, get blocked or answer too late, the content you need can be missing from the rendered HTML. You can check that in the URL Inspection tool in Search Console and in the Rich Results Test.

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

When the subsequent rendering completes successfully, Google can evaluate the DOM it produces. Text, internal and external links and structured data in JSON-LD format can be processed from the rendered DOM, even when the script tag was injected via JavaScript. For images and videos, the URLs and the matching HTML elements also have to be present in the rendered HTML. Processed does not automatically mean indexed. How Google fundamentally parses and processes HTML - before rendering even comes into play - I cover in my article on HTML Parsing & SEO. Native lazy loading via loading="lazy" is generally fine, but belongs in the URL Inspection tool: what matters is that the image and video URLs are present in the rendered HTML. Infinite scroll becomes a problem where individual items have no standalone, crawlable URLs. An accessible pagination with normal links and consistent canonicals is more robust — a canonical alone does not replace pagination.

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: Canonical tags belong in the initial HTML wherever possible. Google can process a rel="canonical" injected with JavaScript, but states plainly “we don’t recommend using JavaScript for this”. If the canonical is set or altered after rendering, it must not diverge from the canonical URL given in the original HTML - otherwise Google may fall back on other signals or fail to canonicalise the URL as intended. 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. Many crawlers outside Google operate without demonstrated JavaScript execution.

An overview of the most relevant AI crawlers and their rendering status - individual platform infrastructure can change over time. The “JavaScript Rendering” column is based on the Vercel and MERJ analysis of 17 December 2024 (“none of the major AI crawlers currently render JavaScript”, over 500 million GPTBot fetches analysed). No vendor documents JavaScript execution for any of these bots, and no public re-measurement exists for 2026. Retrieved 16 August 2026.

* Based on the Vercel/MERJ analysis of December 2024. There is no official vendor statement on this, and no public re-measurement for 2026 that I have been able to confirm. Since crawler infrastructure can change at any time, site owners should regularly check their own visibility in AI-powered search.
† Apple: Applebot may render pages in a browser; the same analysis calls it “a browser-based crawler, similar to Googlebot”.
‡ Anthropic documents three crawlers with separate purposes: ClaudeBot (training), Claude-User (fetching in response to a user question) and Claude-SearchBot (search quality inside Claude). Only ClaudeBot was part of the 2024 analysis; for the other two I have no measurement. I could also not confirm the purpose given for Bytespider (TikTok) against a vendor source.

What does this mean in practice? In the Vercel/MERJ analysis the ChatGPT crawlers downloaded JavaScript files in 11.50% of requests and the Claude crawlers in 23.84%, without executing them. For the remaining bots this behaviour should not be generalised without your own measurement. Content that only comes into being through client-side rendering in the browser stays unread by them. 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. In an e-commerce project I reviewed, running a Vue.js SPA without SSR, the server logs showed no verified GPTBot fetch across the period I analysed. Verified here means matched against OpenAI’s published IP ranges, because a user agent alone can be spoofed. Across the search queries I checked, no visibility in ChatGPT Search was detectable for that project. That is an observation from one project, not proof that rendering was the cause.

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 possible delay and additional resource fetches that can weigh on the crawl budget. For crawlers that do not execute JavaScript, the content usually stays uncaptured.

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 receives complete HTML on fetch and does not depend on client-side JavaScript execution.

Downside: Server load under high traffic. Upside: a very good starting position for crawlers that process HTML without JavaScript, and no additional wait for client-side rendering.

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. Very good performance, a very good starting position for crawlers without JavaScript execution, 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 require extra work on SEO-relevant projects if the content also needs to be readable by AI crawlers. Without SSR, SSG or prerendering it isn’t in the initial HTML, and that is exactly what these crawlers depend on according to the available measurement.

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 Googlebot fetches and the intervals between them. They do not prove which fetch belongs to the rendering phase: Google documents no separate user agent for the renderer, so a differing user agent is not proof on its own. 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, according to the last solid measurement, the answer to the rendering question is no, without any vendor confirming or denying it officially. 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 for Google. For GPTBot and PerplexityBot, the measurement drawn on here found no JavaScript execution, and there is no current official vendor confirmation either way. That is becoming increasingly traffic-relevant.

The action framework for 2026 is clear: SSG as the preferred option for largely static, content-heavy pages, SSR for dynamic content, hybrid models where both come together, 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.