JavaScript SEO
JavaScript SEO is the practice of optimizing JavaScript-rendered web content so search engines can crawl, render, and index it. Because Google first crawls the HTML and then runs JavaScript in headless Chromium to index the rendered result, the goal is to ensure content is exposed by the time rendering completes.
- JavaScript SEO is the discipline of optimizing JS-generated content so search engines can crawl, render, and index it.
- Googlebot moves through crawling, rendering, and indexing, executing JavaScript in headless Chromium during the rendering stage.
- Rendering passes through a queue and can be delayed; measured at roughly a 10-second median and a ~3-hour 90th percentile.
- Google no longer recommends dynamic rendering for new sites, favoring server-side rendering, static rendering, and hydration instead.
- It is safer to design core content and signals such as noindex and canonical so they do not depend on client-side JavaScript alone.
JavaScript SEO Overview
JavaScript SEO refers to optimizing JavaScript-rendered content so that search engines can accurately crawl, render, and index it. Unlike traditional pages where the server returns fully formed HTML, app-shell JavaScript sites often ship an initial HTML document with no real content, populating it only after JavaScript runs in the browser. The starting point of JavaScript SEO is therefore guaranteeing that search engines reach the output produced by that JavaScript execution.
Google handles JavaScript as a two-stage processing flow of crawling, rendering, and indexing. First, Googlebot fetches a URL, checks robots.txt permissions, parses the links in the HTML, and adds them to the crawl queue. Pages that return a 200 status code are then sent to the render queue, and once resources are available, headless Chromium opens the page, executes the JavaScript, and produces rendered HTML. Google parses additional links from this rendered HTML and uses the same result for indexing. In other words, what gets indexed is the post-rendering output rather than the raw HTML captured at crawl time.
Because rendering does not happen instantly and passes through a queue, delays can occur. Google's documentation notes that a page may sit in the queue for a few seconds, though it can take longer. In an analysis of more than 100,000 Googlebot requests by Vercel and MERJ, every 200-status HTML page was fully rendered, with a median rendering delay of about 10 seconds and a 90th percentile of roughly 3 hours. The study also confirmed that removing a noindex tag on the client side does not work for SEO purposes.
Rendering Approaches Compared
Rendering approaches for JavaScript sites differ by where and when content is finalized into HTML, and each carries a different balance of indexing reliability and operational overhead.
| Approach | Render location / timing | Search indexing perspective | Considerations |
|---|---|---|---|
| CSR (client-side rendering) | When JavaScript executes in the user's or bot's browser | Depends on Googlebot's rendering stage, making it vulnerable to queue delays and execution failures | The initial HTML is empty, so content exposure hinges on whether rendering succeeds |
| SSR (server-side rendering) | HTML generated on the server at request time | Delivers complete HTML up front, yielding strong crawl and indexing reliability | Requires managing server load and response speed, and entails hydration design |
| SSG (static rendering) | HTML pre-generated at build time | The simplest and most reliable to index, with a significant speed advantage | Content changes require a rebuild, limiting real-time freshness |
| Dynamic rendering | A separate server-rendered version served only to crawlers | A temporary workaround that Google does not recommend for new sites | Requires manually maintaining user-agent detection and bot lists, increasing complexity |
Google's Position on Dynamic Rendering
Google frames dynamic rendering as a workaround rather than a long-term solution and removed it from its recommendations, citing the added complexity and resource burden. It instead recommends server-side rendering, static rendering, and hydration. That said, dynamic rendering is not treated as cloaking as long as users and crawlers receive equivalent content, and sites already using it will not immediately run into problems. The guidance is closer to advising against adopting it for new builds.
Evidence
The processing flow and recommendations above are grounded in official Google Search Central documentation. The JavaScript SEO basics document specifies the crawl, render, and index stages, headless Chromium rendering, and render-queue handling of 200-status pages. The dynamic rendering document states that the approach is a workaround rather than a recommended solution and presents SSR, static rendering, and hydration as alternatives. The real-world rendering behavior and delay figures draw on Vercel and MERJ's large-scale analysis of Googlebot logs.
Implementation Checklist
- Confirm that core content appears in the rendered HTML using the rendering output of a URL inspection tool.
- Verify that the title, meta description, canonical, and structured data (JSON-LD) output correctly after rendering.
- Do not make indexing signals such as noindex and canonical depend on client-side JavaScript alone.
- In single-page apps (SPAs), use the History API for routing instead of fragments, and handle nonexistent paths with an appropriate status code or noindex rather than a soft 404.
- Return meaningful HTTP status codes so error pages do not return 200 and get indexed.
- Allow the resources needed for rendering in robots.txt so JavaScript bundles and API responses are not blocked.
- Default to SSR or static rendering for new builds, and consider dynamic rendering only as a temporary migration workaround.
- Pair content-fingerprint-based long-term caching with page-speed optimization.