JavaScript SEO and Rendering: How Google Processes JS Sites
By Kavi, SEO Consultant · Last updated: 3 September 2026
Google processes JavaScript sites in two waves: it crawls the raw HTML first, then renders the page with a headless Chromium to see JavaScript-generated content. Rendering happens later and is not guaranteed to succeed. Content and links that exist only after JavaScript runs are found more slowly and are more fragile than content in the initial HTML.
What is JavaScript SEO?
JavaScript SEO is the practice of making sure search engines can access content and links that a site generates with JavaScript rather than serving in the initial HTML response. It matters for React, Vue, Angular, and any site where the raw HTML is largely empty and the page assembles itself in the browser.
Google can render JavaScript. That is the fact people quote, and it is true. The nuance that matters for technical SEO is that rendering is a separate, deferred, resource-constrained step that can fail quietly. “Google can render JavaScript” and “you can rely on JavaScript rendering” are different claims.
Quick facts
| Item | Detail |
|---|---|
| Processing model | Crawl, then queue, then render |
| Renderer | Headless Chromium, evergreen with recent Chrome |
| Rendering delay | Variable; can be minutes or considerably longer |
| Guaranteed? | No. Google warns rendering “may fail for various reasons” |
| Link discovery | Requires real <a href> elements |
| Other search engines | JavaScript support is weaker outside Google |
| Safest approach | Server-side rendering or static generation |
How does Google render JavaScript?
- Crawl. Googlebot fetches the URL and receives the initial HTML response.
- Parse. It extracts links and content present in that raw HTML immediately, and queues the discovered links.
- Queue for rendering. The page waits for rendering resources to become available. This is where the delay lives.
- Render. A headless Chromium executes the JavaScript and produces the final DOM.
- Index the rendered result and queue any newly discovered links from it.
The practical consequence: links present only after rendering enter the crawl queue in a later cycle than links in the raw HTML. On a large site this compounds, and deep sections can take a very long time to be discovered.
Expert tip: the single most valuable diagnostic here takes ten seconds. Disable JavaScript in your browser and load your key templates. Whatever remains is what Google sees on the first wave, guaranteed. Everything that disappeared depends on a step that is deferred and can fail. That test tells you more than most audit tools.
Rendering strategies compared
| Strategy | How it works | SEO reliability | Best for |
|---|---|---|---|
| Static site generation (SSG) | HTML built at deploy time | Highest | Blogs, docs, marketing sites |
| Server-side rendering (SSR) | HTML built per request on the server | High | Ecommerce, personalised content |
| Incremental static regeneration | Static, rebuilt on a schedule or on demand | High | Large catalogues with periodic updates |
| Hydration on top of SSR/SSG | HTML served, JS adds interactivity | High | Most modern frameworks |
| Client-side rendering (CSR) | Empty shell, JS builds everything | Lowest | Logged-in app screens that need no indexing |
| Dynamic rendering | Pre-rendered HTML served to bots only | Workaround | Legacy sites; Google now calls it a workaround, not a recommendation |
The ranking here is about reliability, not quality of engineering. Client-side rendering is a legitimate architecture; it is simply the one that puts the most between Google and your content.
How to diagnose rendering problems
Step 1: Compare raw HTML with rendered HTML
Fetch the raw response and search it for a distinctive sentence from your main content:
curl -s https://example.com/page/ | grep -c "a distinctive phrase"A result of zero means that content is not in the initial HTML.
Step 2: Use URL Inspection Live Test
In Search Console, run a live test and open “View tested page”, then the HTML tab. This is Google’s actual rendered output. Compare it against your browser. Also check the “More info” tab for resources Google could not load.
Step 3: Check for blocked resources
If JavaScript or CSS files are disallowed in robots.txt, rendering fails or produces a broken page. This remains one of the most common causes of a rendered page that looks nothing like the real one.
Step 4: Verify links are real anchors
Google follows href attributes. These do not work for discovery:
<div onclick="navigate('/products/')">Products</div>
<span class="link" data-href="/products/">Products</span>
<a href="#" onclick="router.push('/products/')">Products</a>This does:
<a href="/products/">Products</a>A framework router can still intercept the click for a soft navigation; the requirement is only that a real href exists in the markup.
Step 5: Check what depends on interaction
Google does not click, scroll, hover, or fill forms. Content behind a “load more” button, an infinite scroll that only fires on scroll, or a tab that fetches on click may never be seen. Content inside a tab that is already in the DOM but visually hidden is generally fine.
Common JavaScript SEO mistakes
| Mistake | Consequence | Fix |
|---|---|---|
| Blocking JS or CSS in robots.txt | Broken rendering | Allow all render-critical assets |
| Links as onclick handlers | Pages never discovered | Use real anchor tags with href |
| Content behind infinite scroll only | Never rendered | Provide paginated URLs as well |
| Client-side redirects instead of server redirects | Unreliable; may not be seen | Use server-side 301s |
| Titles and canonicals injected by JS | May be missed or conflict with the raw HTML | Render meta tags server-side |
| Soft 404s returning HTTP 200 | Empty pages get indexed | Return a real 404 status from the server |
| Fragment URLs (#) for distinct pages | Fragments are not separate URLs | Use real paths with the History API |
| Lazy-loading main content | May not render | Lazy-load below-the-fold images only |
| Long JS execution times | Rendering may time out | Reduce bundle size and defer non-critical work |
| Assuming other engines render like Google | Invisible on Bing and AI crawlers | Serve content in HTML |
JavaScript and AI crawlers
This deserves separate mention because it is a growing blind spot. Most AI crawlers currently do far less JavaScript execution than Googlebot, and several fetch raw HTML only. A client-side rendered site can therefore rank acceptably in Google while being effectively invisible to the systems that generate AI answers.
If citation in AI answers matters to you, serving content in the initial HTML stops being a nice-to-have. See how to control AI crawlers and how AI Overviews choose citations. (Reasonable Inference from documented crawler behaviour; operators publish little detail about their rendering capabilities.)
Decision guide
- Content site or blog: static generation or plain server-rendered HTML. There is no reason to render content client-side.
- Ecommerce: server-side rendering for product and category pages; client-side is fine for cart and account.
- SaaS marketing site: static or SSR for public pages; the logged-in app needs no indexing.
- Existing CSR site you cannot rewrite: prioritise SSR for the templates that earn traffic, starting with the highest-value ones.
- WordPress: already server-rendered. Your JavaScript concern is performance, not indexability.
JavaScript SEO checklist
- Main content present in the initial HTML response
- All internal links are real anchor tags with href attributes
- JavaScript and CSS not blocked in robots.txt
- Title, meta description, and canonical rendered server-side
- No content requiring a click, scroll, or hover to load
- Server-side redirects, not JavaScript redirects
- Real 404 status codes for missing pages
- Real URL paths, not fragment identifiers
- Rendered HTML in URL Inspection matches the browser view
- No “resources could not be loaded” warnings in the live test
- Content visible with JavaScript disabled
- Structured data present in the server response where possible
Frequently asked questions
Can Google index JavaScript content?
Yes. Google renders pages with a headless Chromium and indexes the result. The caveats are that rendering is deferred, resource-limited, and can fail, so it is less reliable than serving content in HTML.
How long does rendering take?
It varies and Google does not publish a figure. It can be minutes, and on large or low-priority sites considerably longer. Treat it as unpredictable rather than assuming any particular window.
Is React bad for SEO?
No. React rendered on the server or statically generated is fine. Purely client-side React for public content is the risk, and every major React framework offers a server-rendering mode.
Should I use dynamic rendering?
Only as a stopgap on a legacy site. Google now describes it as a workaround rather than a recommended solution, and it means maintaining two rendering paths indefinitely.
Do other search engines render JavaScript?
Support outside Google is weaker and less consistent. If Bing, DuckDuckGo, or AI answer engines matter to you, serve content in HTML.
How do I test what Google sees?
URL Inspection’s live test with “View tested page” is authoritative because it is Google’s own renderer. The disable-JavaScript browser test is the fastest approximation of the first wave.
Does JavaScript slow down indexing?
It adds a queued step between crawling and indexing, so in practice yes, JS-dependent content is typically indexed later than content in the raw HTML.
Key takeaways
- Google crawls first and renders later; rendering is deferred and can fail.
- Anything in the initial HTML is guaranteed to be seen; anything after is not.
- Links must be real anchor tags with href attributes.
- Never block JavaScript or CSS in robots.txt.
- Google does not click, scroll, or hover.
- Server-side rendering or static generation is the reliable choice for public content.
- AI crawlers generally render less JavaScript than Googlebot.
Conclusion
The question is not whether Google can render your JavaScript, it is how much you want to depend on a step you do not control. Run the disable-JavaScript test on your most valuable template today. If your content survives, you have nothing to fix. If it vanishes, you have found the highest-priority item on your technical roadmap.
Related articles
- Technical SEO guide
- How to do a technical SEO audit
- Robots.txt explained
- Core Web Vitals explained
- How to control AI crawlers
External references
- Google Search Central: JavaScript SEO basics
- Google Search Central: Fix search-related JavaScript problems
One Comment