Does Google really index all pages after JavaScript rendering?

Why does this statement contradict a common belief?

For years, the dominant SEO narrative opposed raw HTML indexing versus post-JavaScript rendering indexing. Martin Splitt cuts through the confusion: there aren't two distinct paths. Google first processes the initial HTML, then decides to render the page, and finally indexes it.

The idea that a URL could be indexed without being rendered is technically possible, but extremely marginal. We're talking about anecdotal cases where a page loads no critical external resources. In 99.9% of real-world scenarios, the crawler waits for rendering before generating the index.

What does this change for the architecture of a JavaScript-heavy site?

If Google systematically renders before indexing, the risk is no longer that your content will be ignored — it’s that it might be deferred. A Single Page Application (SPA) with complex client hydration will ultimately make it into the index, but with an unavoidable delay between crawling and effective indexing.

This delay varies based on the crawl budget allocated, the server load on Googlebot, and the complexity of the rendering. On a news site or an e-commerce platform with rapid product rotation, this gap can become problematic: your new content arrives late in the SERPs while the competition indexes its static HTML immediately.

What is Google's true definition of 'rendering'?

Google executes JavaScript, waits for critical requests to complete (fetch, XHR), triggers DOM events, and then captures the final DOM snapshot. It's this snapshot that goes to the indexation, not the initial source HTML.

The catch: Google imposes a timeout. If your JS takes too long to load or if infinite lazy-loads delay the display of the main content, the crawler captures an incomplete picture. You might have had a perfect rendering from the user's side after 8 seconds — Googlebot, however, may have cut off at 5.

• Almost 100% of pages are rendered before indexing — the exception is negligible in practice.
• The initial HTML serves as a first pass analysis, but final indexing relies on the rendered DOM.
• The delay between crawling and indexing lengthens with JavaScript complexity — a critical point for high-velocity sites.
• A timeout on Googlebot's side can truncate content if rendering is too slow or blocked by external resources.
• Meta tags, titles, and structured data injected via JS are indeed taken into account, but only after rendering.

Is this statement consistent with real-world observations?

Yes and no. In 2018-2019, we still regularly saw cases where raw HTML was indexed without rendering — particularly on orphan pages or low-authority sites. Since 2021-2022, these cases have become rarer. Splitt's assertion reflects the current state of the crawler, not its historical behavior.

But be wary of confirmation bias: the sites we audit generally have a proper crawl budget. On millions of low-quality pages or recent domains, [To be verified] whether Google really maintains this rendering rate close to 100%. Server logs show that Googlebot does not render all crawled URLs — there's a prior sorting based on quality and priority signals.

What nuances should be added to this generalization?

Splitt says 'practically 100%' — this 'practically' hides a reality: Google actively chooses which pages deserve a rendering. If your site generates duplicate or low-value content in bulk, Googlebot may decide to crawl without rendering, or to render with a delay of several weeks.

Another nuance: rendering doesn’t guarantee indexing. A page can be perfectly rendered and still end up excluded due to duplicate content, thin content, or canonicalization. Rendering is a technical step — indexing remains an editorial decision by the algorithm.

In which cases does this rule not apply or cause problems?

Sites with real-time content (news feeds, trading, events) suffer from the rendering delay as a competitive handicap. If your competitor publishes static HTML and you do React SSR, they will be indexed within minutes while you wait several hours.

Complex Progressive Web Apps with service workers also pose issues: Googlebot may struggle to trigger certain rendering paths or miss lazy-loaded fragments. In these architectures, it’s often necessary to implement server-side prerendering or dynamic rendering to circumvent the crawler's limitations.

What concrete steps should be taken to optimize rendering for Googlebot?

First, reduce critical rendering time. Use tools like Puppeteer or Chrome DevTools in mobile mode to measure how long it takes before the main content is available in the DOM. If it exceeds 3-4 seconds, Googlebot is likely to capture an incomplete version.

Next, serve essential content from the initial HTML. Even if Google renders, it first analyzes the raw HTML to decide if the page deserves rendering. If this HTML is empty or generic, you risk being deprioritized. A good compromise: inject at least the <title>, <meta description>, and structured data server-side, even if the textual content is hydrated client-side.

What mistakes should be avoided when migrating to a JavaScript-heavy site?

A classic mistake: blocking JS/CSS resources in robots.txt. If Googlebot cannot load your JavaScript bundles, it won't be able to render the page — and you’ll lose indexing. Check in Search Console > Settings > Crawl Testing Tool that all critical resources are accessible.

Another pitfall: aggressive lazy-loading without fallback. If your main content only appears after infinite scrolling or user clicking, Googlebot will never see it. Ensure that critical content is loaded automatically on the first rendering, without any required interaction.

How can you check if Google is rendering your pages correctly?

Use the URL Inspection Tool in Search Console. Compare the raw HTML (tab ‘View Source’) with the rendered DOM (tab ‘View Page as Explored’). If blocks of content are missing in the rendering, it means Googlebot timed out or missed JavaScript execution.

Complement this with a Screaming Frog crawl in JavaScript mode and compare the results with a crawl of HTML-only. Discrepancies in titles, meta tags, or the number of internal links reveal areas where rendering poses problems. Also monitor server logs: if Googlebot crawls your URLs but doesn’t load JS/CSS resources, that’s a red flag.

• Measure critical rendering time with Puppeteer or Lighthouse — aim for under 3 seconds.
• Inject at least the <title>, <meta>, and structured data server-side.
• Verify in robots.txt and Search Console that all JS/CSS resources are accessible to Googlebot.
• Avoid lazy-loading on main content — load it automatically on the first rendering.
• Use the URL Inspection Tool to compare raw HTML and rendered DOM.
• Crawl your site in JavaScript mode with Screaming Frog to detect indexing discrepancies.