JavaScript SEO in 2026: What Google Renders and What It Skips
Google renders JavaScript. That has been true for years and it is still true in 2026. The problem is that rendering is queued, resource-limited, and never guaranteed for a specific page. Content that only appears after a client-side render can be indexed late, indexed partially, or missed. Rendering happening is not the same as rendering happening reliably.
How Google renders in 2026
Googlebot works in two waves. First it fetches the HTML and reads what is there. Then it queues the page for rendering with a headless, evergreen Chromium, runs the JavaScript, and reads the result. On a small, healthy site the gap between those waves is short. On a large site with a tight render budget, or on pages with heavy or fragile scripts, the second wave can lag or fall short.
The practical consequence: anything critical for search should not depend on the second wave. If your h1, body copy, internal links, or canonical tag only exist after JavaScript runs, you are betting on a render that may not go your way.
What it reliably renders
Modern, well-built client-side apps often do index, so this is not a reason to fear JavaScript. Google reliably handles content that loads automatically on page load, without interaction, without long delays, and without depending on scripts that time out. Server-rendered and statically generated pages are the safest, because the content is already in the HTML before any script runs.
What it skips or delays
Trouble clusters around a few patterns. Content behind a user action Googlebot will not perform. Content injected after a slow API call that exceeds the render budget. Routes that only work through client-side navigation with no crawlable server response. Lazy-loaded content that never triggers because Googlebot does not scroll like a person. And anything gated by a script that fails silently.
| Pattern | Risk to indexing | Safer approach |
|---|---|---|
| Content loaded on click or tab change | High | Render it in the initial HTML, hide with CSS if needed |
| Body copy from a slow client-side fetch | Medium to high | Server-render or statically generate the content |
| Client-only routing, no server response | High | Ensure each route returns real HTML on request |
| Lazy content triggered by scroll | Medium | Load above-the-fold content without interaction |
Scroll table horizontally →
How to test your own site
Do not guess. Compare the raw HTML with the rendered DOM, and check what Google actually crawled.
# What is in the HTML before any JS runs
curl -s https://example.com/page | grep -c "<h1"
# Then compare with the rendered HTML in
# Search Console > URL Inspection > View crawled page.
# If the content is only in the rendered version,
# it depends on client-side rendering.The URL Inspection tool is the source of truth, because it shows what Googlebot rendered, not what your browser renders. A page can look perfect to you and arrive empty to Google. That gap is exactly the crawled, currently not indexed situation many teams misdiagnose.
Two myths worth dropping
The first myth is that Google cannot handle JavaScript at all, so any framework is a death sentence for SEO. That has not been true for years. Well-built React and Vue sites index fine every day. Fear-driven advice to avoid JavaScript entirely is as wrong as the opposite complacency. The real question is never whether Google can render, but whether your specific implementation makes rendering reliable and fast enough.
The second myth is that a JavaScript framework automatically means server-side rendering. It does not. Plenty of teams ship a framework in pure client-side mode and assume the SEO is handled because they chose a modern tool. The tool does not decide the rendering strategy; you do, per route, in configuration. A Next.js app can serve fully static pages or fully client-rendered ones from the same codebase, and the difference to a crawler is enormous.
The practical upshot of dropping both myths is that you stop arguing about the framework and start auditing the output. Look at what arrives in the HTML for each important template, decide whether that is enough for search, and change only the routes that need it. That is a far calmer conversation to have with an engineering team than a demand to rip out their stack.
The fix, by stack
The fix is almost always to move important content into the initial server response. How you do that depends on the framework.
- Next.js and Nuxt: choose server-side rendering or static generation per route, so SEO-critical pages ship real HTML.
- Single-page apps without a framework: add a rendering layer or pre-render the routes that matter for search.
- Legacy SPAs you cannot rewrite: prioritise the templates carrying the SEO weight and render those, rather than boiling the ocean.
The takeaway: treat rendering as a spectrum of risk, not a yes-or-no question. Get your important content into the HTML before JavaScript runs, test with the rendered HTML rather than your browser, and focus the work on the templates that earn traffic. If a large share of your pages depend on client-side rendering, a focused JavaScript SEO engagement will map the risk and close it stack by stack.