Is Two-Wave JavaScript Indexing Really Disappearing?

What Exactly is Two-Wave Indexing?

Historically, Google employed a two-step indexing process for JavaScript sites. The first wave crawled the raw HTML and indexed what was immediately available. The second, time-delayed wave executed the JavaScript to index dynamically generated content.

This process introduced a potentially significant delay between the initial crawl and the actual indexing of the real content. For sites heavily reliant on frameworks like React, Vue, or Angular, this meant waiting several days — or even weeks — before a page was fully indexed.

Why Did This Two-Wave Process Exist?

The main reason was server resources. Executing JavaScript for each crawled page is infinitely more costly in computation than simply reading static HTML. Therefore, Google historically separated these two operations to optimize its infrastructure.

The second factor was the version of Chrome used by Googlebot. For a long time, the rendering engine ran on an outdated version of Chrome (several versions behind), unable to correctly interpret some modern JavaScript syntaxes or recent APIs.

What Changes Does This Update Actually Bring?

Splitt mentions that Googlebot now uses the latest version of Chrome for rendering. Technically, this means better compatibility with ES6+, JavaScript modules, and faster execution thanks to optimizations in the V8 engine.

The central claim is that this modernization makes indexing “more efficient” and reduces the need to wait for a separate second wave. In other words, less delay between crawling and complete indexing of JavaScript content.

• Traditional two-wave indexing: Raw HTML first, JavaScript later with variable delay
• Modern Chrome engine: Better compatibility with recent JavaScript syntaxes and browser APIs
• Stated goal: Reduction of indexing delays for client-side generated content
• Server resources: The two-wave process existed to limit the rendering load of JavaScript
• Expected impact: Potentially faster indexing without waiting for a separate rendering queue

Does This Statement Align with Field Observations?

Tests conducted by various practitioners show mixed results. Some modern JavaScript sites do see faster indexing — sometimes within hours instead of days. Others still display significant delays, especially if crawl budgets are limited or if the site has rendering errors.

The promise of “more efficient” indexing remains vague. Splitt provides no figures, no time thresholds, no metrics to quantify this improvement. [To be verified] on your own projects using before/after measurements and indexing tracking tools.

What Nuances Should Be Added to This Claim?

Stating that the two-wave process “is decreasing” does not mean it completely disappears. Google continues to crawl HTML first, then queue JavaScript rendering. The difference lies in the delay between these two steps and the likelihood that the content is indexed on the first pass.

Sites with a tight crawl budget or poorly optimized JavaScript architecture will likely continue to experience delays. A newer Chrome engine does not compensate for excessive loading times, blocking console errors, or the absence of SSR on critical pages.

In What Cases Does This Improvement Not Apply?

If your site uses complex JavaScript patterns — aggressive lazy loading, poorly managed asynchronous hydration, dependencies on slow third-party APIs — the modern Chrome engine won’t change the fundamental problem: Googlebot sees an empty or incomplete page at rendering time.

Similarly, sites that generate content after user interaction (infinite scrolling, clicks to reveal, modals) will not benefit from this change. Googlebot does not interact with the page like a user — it executes JavaScript on initial load, period.

What Should You Do with This Information?

First, test. Use the URL inspection tool in Search Console to compare raw HTML and JavaScript-rendered versions on your strategic pages. Ensure that critical content appears correctly in the rendered version without blocking console errors.

Next, monitor your indexing delays with tools like OnCrawl, Botify, or Screaming Frog Log Analyzer. Measure the time elapsed between the initial crawl (visible in server logs) and the effective appearance of the page in the Google index. If this delay exceeds 48-72 hours on important pages, the issue does not lie with the Chrome engine but with your architecture.

What Mistakes Should Be Avoided Despite This Evolution?

Don’t fall into the trap of putting all your eggs in the JavaScript rendering basket simply because Googlebot uses a modern Chrome. SSR or static generation remain superior in terms of reliability, indexing speed, and user performance.

Avoid neglecting the Core Web Vitals as well. A JavaScript site may be perfectly rendered by Googlebot while offering a disastrous user experience (high LCP, significant CLS). The modern Chrome engine indexes better but does not compensate for a slow site.

How Can You Verify That Your Site Is Actually Benefiting from This Improvement?

Set up a regular indexing monitoring using the Search Console API. Track the number of indexed pages, JavaScript rendering errors, and the delays between publication and indexing. Compare these metrics before and after architecture modifications.

Test your pages with recent JavaScript syntaxes (async/await, ES6 modules, optional chaining) to ensure Googlebot interprets them correctly. If you still see errors in the inspection tool’s console, the problem lies with your code, not the engine.

• Inspect key JavaScript pages via Search Console (raw HTML vs rendered)
• Measure actual indexing delays on a representative sample of pages
• Maintain SSR or static generation for critical content
• Monitor Core Web Vitals to avoid degrading UX for the sake of technical SEO
• Verify that modern JavaScript syntaxes are correctly interpreted by Googlebot
• Eliminate blocking console errors that prevent full rendering