JavaScript SEO: The Complete Guide to Rendering, Crawling and Indexing

The question “can Google render JavaScript?” was settled years ago. Yes, it can. Google confirmed on its own podcast that it renders all web pages for search, including JavaScript-heavy ones.

That answer created a false sense of safety. The useful question in 2026 isn’t whether Google can render your JavaScript. It’s whether it will render your specific implementation, how long that takes, and what happens to every other system that isn’t Google.

Key Takeaways

• Google indexes JavaScript sites in two waves: raw HTML immediately, rendered content later from a queue.
• Render queue delay is variable and can stretch from seconds to days or weeks.
• Google now describes dynamic rendering as a workaround, not a long-term solution.
• AI crawlers render JavaScript far less reliably than Googlebot, which makes client-side content a GEO liability.

How does Googlebot actually process JavaScript?

In two separate waves. Wave one is an immediate HTTP crawl where Googlebot fetches the raw HTML and indexes whatever is in it. Wave two is deferred: the page enters a render queue, and the Web Rendering Service executes the JavaScript before the resulting DOM is indexed.

The Web Rendering Service runs headless Chromium, and since 2019 it’s been evergreen, meaning it tracks current Chrome versions. Modern syntax is fully supported. ES6, async/await, promises and the Fetch API all work.

Where does the problem sit, then? In the gap between the two waves. Anything that exists only after JavaScript executes doesn’t exist to the index until wave two completes.

What is the render queue and why does it matter?

The render queue is where pages wait for rendering resources, and its delay is variable and unpredictable. Rendering is computationally expensive, so Google defers it. That delay can be seconds. It can also stretch to days or weeks on large or low-priority sites during periods of high queue load.

Think about what that means for different business types. For a slow-moving brochure site, a multi-day delay is irrelevant. For a news publisher or a fast-moving e-commerce catalogue, it’s the difference between capturing a moment and missing it entirely.

There are also documented technical limits, including a cap on HTML and resource size, and limited interaction with elements that require user action. Content behind a click is content Googlebot generally doesn’t see.

The practical rule that follows: anything you need indexed reliably and quickly belongs in the initial HTML response.

CSR, SSR, SSG or ISR: which should you use?

Server-side rendering or static generation for anything that matters to search, with client-side rendering reserved for interactive elements that don’t need indexing.

Plain React, Vue or Angular without a server rendering layer are no longer defensible choices for content that needs to rank. The frameworks all have server rendering options now, and using them costs less than diagnosing indexing problems later.

Is dynamic rendering still a valid option?

Only as a temporary migration step. Google now describes dynamic rendering as a workaround rather than a recommended long-term solution, and its documentation has become progressively clearer on that point.

Dynamic rendering serves pre-rendered HTML to crawlers while serving normal JavaScript to browsers. It works, but it means maintaining two delivery paths, two sets of bugs, and a permanent divergence between what bots and users receive.

If you’re already running it, treat it as a bridge. For anything new, don’t start here.

What are the most common JavaScript SEO failures?

Six problems account for most of what we find in technical audits:

• Links that aren’t links. A <div> with an onclick handler is not a link. Googlebot follows <a href="">. If your navigation is built from click handlers, large parts of your site may be undiscoverable.
• Fragment-based routing. Google deprecated the old AJAX crawling scheme and recommends the History API. If your pages depend on #/route patterns, crawlability is weaker than it should be.
• Soft 404s. Showing a “not found” message in the interface while returning HTTP 200. The server must return the real status code.
• Blocked resources. Disallowing JavaScript or CSS in robots.txt breaks rendering and degrades indexing quality.
• Client-side metadata. Titles, descriptions and canonicals injected after load. These sometimes work and sometimes don’t, which is the worst possible property for a critical tag.
• Content behind interaction. Tabs, accordions and infinite scroll that only load on click or scroll. If it requires a user action, assume it isn’t indexed.

How do you check what Google actually sees?

Compare the raw HTML against the rendered HTML, and never rely on your browser’s view. Your browser has already executed everything, which makes it the one perspective that tells you nothing about the problem.

Four checks, in order of usefulness:

1. URL Inspection in Search Console. Use “Test live URL” and view the rendered HTML. This is Google telling you directly what it sees.
2. View source versus inspect element. View source shows the raw response. Inspect element shows the rendered DOM. The difference between them is your JavaScript dependency.
3. Crawl with rendering enabled. A crawler in JavaScript rendering mode can compare raw and rendered output across the whole site at once, which surfaces patterns a single-page check misses. Screaming Frog and Sitebulb both support this, and the comparison view is where template-level problems become obvious.
4. Disable JavaScript and load the page. Crude, but it reveals immediately how much of the page depends on it.

Check the specific things that matter: is the main body text present, are internal links present as real anchors, are title and canonical in the raw response, and is structured data there.

Does JavaScript still hurt rankings even when it renders?

Yes, through three indirect channels that persist even when rendering completes successfully.

Performance. Core Web Vitals are ranking signals, and heavy JavaScript is the most common cause of poor interaction responsiveness. Rendering correctly but slowly is still a ranking problem.

Crawl efficiency. Rendering consumes Google’s resources. Sites that require expensive rendering across many pages get less of it, which compounds on large catalogues.

Delay. Even successful rendering happens later than the raw HTML crawl. For fast-moving content, later can mean too late.

The AI crawler problem nobody planned for

This is the part that changes the calculation, and it’s why JavaScript SEO matters more in 2026 than it did in 2023.

Googlebot renders JavaScript well. The crawlers behind AI answer engines largely don’t, or do so far less reliably, and there’s no public documentation equivalent to Google’s specifying how each one behaves. More significantly, the standard pipeline for preparing web pages as language model training data strips CSS and JavaScript before extracting plain text.

Follow that logic through and the consequence is uncomfortable: content that exists only in the rendered DOM is systematically underrepresented in what language models learn from, and it’s at risk of being missed by the retrieval crawlers that feed AI answers.

A site can therefore render perfectly for Google, rank well, and still be close to invisible to ChatGPT, Perplexity and the other systems that increasingly sit between a customer and a decision. The remedy is identical to the one for the render queue, which makes it an easy argument: put the content in the initial HTML.

For the broader framework, see our generative engine optimisation service.

A pre-launch technical checklist

Before any JavaScript-heavy site goes live:

• Main content appears in the raw HTML response
• Internal links are real <a href> elements
• Title, meta description and canonical are server-rendered
• Structured data is in the initial HTML
• Routing uses the History API, not fragments
• Error pages return real HTTP status codes
• JavaScript and CSS are crawlable in robots.txt
• No SEO-critical content requires a click or scroll to load
• Rendered output verified in Search Console URL Inspection
• Core Web Vitals measured on real devices, not just lab tools

Run this before launch. Diagnosing these problems after a migration costs considerably more than preventing them.

How VOCTOS handles technical builds

Framework choices made in week one determine indexing behaviour for years, and by the time the symptoms appear the cost of changing course has multiplied. We work with development teams while the architecture is still a decision rather than a legacy.

That covers rendering strategy, crawlability audits comparing raw against rendered output, structured data delivery, and Core Web Vitals work on real devices. We also check the surface most technical audits still skip, which is what an AI crawler retrieves from your pages as opposed to what Googlebot does.

Planning a build, or stuck on an indexing problem that won’t resolve? Send us the URL and we’ll take it apart. Request a technical SEO audit.

The questions developers ask us most

Does Google index JavaScript content?

Yes, but in a second wave after an initial HTML crawl. Googlebot fetches and indexes the raw HTML immediately, then queues the page for rendering by its Web Rendering Service. Content that only appears after JavaScript executes is indexed only once rendering completes, and that can take from seconds to weeks.

What is the difference between CSR and SSR for SEO?

Client-side rendering builds the page in the browser, so search engines receive a near-empty HTML shell and must render before they see content. Server-side rendering builds the HTML on the server, so content arrives in the first response. SSR is more reliable for indexing, faster to first paint, and safer for AI crawlers.

Should I use dynamic rendering?

Only as a temporary measure during migration. Google now describes it as a workaround rather than a recommended long-term solution. It requires maintaining two separate delivery paths, which doubles the surface for bugs. On a new build, reach for server-side rendering or static generation instead.

Why are my pages indexed but showing no content?

Usually because Googlebot indexed the raw HTML from wave one before rendering completed, and the raw HTML contained almost nothing. Check the live URL in Search Console and compare the rendered HTML against your view source. If your content only appears in the rendered version, you have a render dependency.

Do AI search engines render JavaScript?

Far less reliably than Googlebot, and there is no public documentation specifying how each one behaves. The pipelines that prepare pages as training data typically strip JavaScript before extracting text. Content that exists only in the rendered DOM risks being invisible to AI answer engines even while ranking normally in Google.

Where to start

Open your most important page, view source, and search for a sentence from the middle of the body text. If it’s there, you’re in reasonable shape. If it isn’t, everything below that sentence depends on the render queue.

That one check takes thirty seconds and tells you more than most technical audits. Do it on a service page, a product page and a blog post, since different templates often behave differently.

Then read our local SEO guide if you serve a specific city, since rendering problems and local visibility problems often show up together, or our technical support service if you want the fixes handled for you.

Related guides

• The Complete Local SEO Guide for 2026: How to Rank in Your City
• Healthcare SEO: A Practical Playbook for Clinics and Medical Centers
• AI Search Optimization in 2026: SEO vs GEO vs AEO vs AIO, and How to Get Cited by AI
• SEO Copywriting: How to Write Content That Ranks on Google and AI