Should we abandon the two waves of indexing model?

Where does this story of two waves come from?

The metaphor of the two waves of indexing has circulated for years within the SEO community. The idea? Google would first crawl the raw HTML (wave 1), then come back later — sometimes several days after — to execute the JavaScript and index the dynamic content (wave 2).

This mental model simplified how Googlebot processes modern sites. It also reassured some practitioners who saw their heavy JS pages being indexed with delays. However, this scheme has always been a rough approximation, never a faithful technical description of the actual pipeline.

What really happens during indexing?

Martin Splitt states: the process is crawl-render-index in nearly all cases. In practice, Googlebot fetches the page, executes the JavaScript right away, and then indexes the rendered content. No mysterious queue, no systematic second pass weeks later.

This doesn't mean that every page is rendered instantaneously — crawl budget and algorithmic priorities still play a role. But the separation into two distinct and predictable waves? It was storytelling, not engineering.

Why did Google use this metaphor?

Because explaining the nuances of the rendering pipeline to a non-technical audience quickly becomes a nightmare. The two waves metaphor allowed a key message to be communicated: “Your JS can delay indexing, optimize it.”

The problem? It created a false sense of certainty. Some SEOs built entire strategies around this supposed second wave, monitoring fictional delays and inventing correlations. Result: lots of noise, little signal.

• The crawl-render-index process is unified in the majority of scenarios
• There is no predictable and systematic “wave 2” queue
• Indexing delays depend on crawl budget, content quality, and server load, not on a two-phase architecture
• The metaphor was a teaching tool, never an operational model

Is this statement consistent with field observations?

Yes and no. On well-optimized sites with a generous crawl budget, it is indeed observed that JS content is indexed quickly, in a single pass. Logs confirm: Googlebot does not systematically return days later to “finish the job”.

However, on massive sites, with thousands of JS pages and a limited budget, delays are still observed. Some pages remain in raw HTML for several weeks before being fully rendered. Is this a “wave 2”? No. It’s just that Google prioritizes and does not render everything immediately. An important nuance. [To verify] on each project depending on its technical profile.

Why this clarification now?

Because the metaphor has generated too many misconceptions. SEOs were passively waiting for a second wave that was never going to arrive. Others were over-optimizing to speed up a process that did not exist as they imagined.

Google now prefers to hammer home the simple message: optimize your rendering from the start. No hacks, no waiting strategy. If your critical content is in JS, ensure it executes quickly; otherwise, you will lose crawl budget — end of story.

What gray areas still exist?

Martin Splitt says “in nearly all cases”. What are the exceptions? No exhaustive list has been provided. We know that some pages with very low priority may be indefinitely pushed back in the rendering queue. But is it 1% of cases? 5%? 15% on a poorly structured site?

Another vague point: how Google handles dynamic content updates after the first rendering. If a page changes client-side after the initial crawl, is there an automatic re-render or must a new crawl be forced? [To verify] — the official documents remain vague on this scenario.

What should be done concretely on a JS-heavy site?

Stop waiting for a hypothetical second wave. Your critical content must be accessible from the first rendering. This requires server-side rendering (SSR), pre-rendering, or at a minimum, optimized JS that loads quickly and cleanly.

Always test with Search Console (URL inspection tool) and check that the rendered content matches your expectations. If elements are missing in the rendered version, Google will not see them — or will see them much later, negatively impacting the ranking.

What mistakes to avoid after this clarification?

Avoid falling into the opposite excess. Some will conclude, “Google renders everything instantly, I can do anything in JS.” False. The crawl budget remains limited, and costly rendering slows down the indexing of the entire site.

Another trap: believing that this statement invalidates any progressive enhancement strategy. No. Serving a basic HTML with textual content remains a good practice, even if Google renders the JS. This enhances resilience, speed, and accessibility — signals that Google indirectly values.

How to check if my site aligns with this crawl-render-index model?

Analyze your server logs to spot crawl patterns. If Googlebot frequently returns to the same URLs without content changes, it might be a sign that rendering is an issue. Cross-check with Search Console data: a gap between “crawled pages” and “indexed pages” may indicate a rendering issue.

Use tools like Screaming Frog in JavaScript mode or tests via Puppeteer to simulate Googlebot's behavior. If your crawling tool takes 10 seconds to render a page, Google will have the same problem — and it won’t wait indefinitely.

• Implement SSR or pre-rendering for critical content
• Test each key template with the Search Console URL inspection tool
• Analyze logs to detect crawl/rendering anomalies
• Optimize the size and execution speed of JavaScript (code splitting, smart lazy loading)
• Never block strategic content behind user interactions (clicks, infinite scroll without fallback)
• Monitor the gap between crawled pages and indexed pages in Search Console