Google crawls and indexes most pages in two passes. The first indexes whatever HTML Googlebot receives on the initial request. The second — rendering JavaScript and indexing what it produces — is queued separately through the Web Rendering Service and can land hours to weeks later, depending on crawl and rendering capacity.

Key takeaways

  • Wave one is immediate; wave two is queued. Raw HTML gets indexed on the first crawl. JS-rendered content waits for a separate rendering pass.
  • The gap has no fixed number. Reports and Google's own statements describe hours to weeks — treat any specific figure you read as a snapshot, not a guarantee.
  • It affects content, links and structured data alike — anything that only exists in the DOM after client-side JavaScript runs waits for wave two, not just visible text.
  • Server-side rendering skips the wait entirely — if it's in the initial response, there's no second wave to queue for.
  • This is why time-sensitive content is the real risk, not content in general. A blog post landing a day late is harmless; a corrected price or an urgent update is not.

The two waves, precisely

Wave one happens the moment Googlebot fetches your URL — it reads whatever HTML exists in that initial response, full stop. For a server-rendered page, that's the actual content. For a client-rendered single-page app, it's often close to an empty shell: a root <div>, a script tag, nothing readable yet.

Wave two is where the JavaScript actually runs. Google queues the URL for its Web Rendering Service, which executes the page's scripts roughly the way a browser would, then indexes whatever the DOM looks like after that execution — the fully rendered version, including content, internal links, and any structured data that JavaScript injected rather than shipped in the source.

What each wave sees, and when.
Wave What's indexed Timing
Wave oneRaw HTML from the initial responseImmediate, on crawl
Wave twoFully JS-rendered DOM, via the Web Rendering ServiceQueued — hours to weeks, variable

How long the gap actually is

Nobody outside Google can state a precise number, and Google hasn't committed to one. Documented reports and statements from Google describe anywhere from a few hours to several weeks, depending on how often the site is crawled and how much Web Rendering Service capacity is available at that moment. Google representatives have also periodically said this gap matters less over time as rendering capacity improves — worth knowing, but not the same as it being solved.

Claims about two-wave indexing, graded by evidence.
Claim Status Basis
Google indexes raw HTML before rendering JavaScript Documented Confirmed in Google's own developer documentation on JavaScript SEO basics
The rendering pass is queued separately, not instant Documented Confirmed by Google's own statements about the Web Rendering Service
The delay is "hours to weeks" Inferred Consistent range across multiple reports and Googler statements; no single fixed figure published
The gap has shrunk meaningfully in 2026 versus prior years Inferred Google has said rendering capacity improves over time; no measured before/after figure available to confirm by how much
There is a fixed, universal rendering timeout Googlebot applies per page Unsupported Specific numbers circulate widely but aren't consistently sourced to a current, citable Google statement

What's actually affected

Everything that only exists in the DOM after JavaScript executes waits for wave two — not just body text. That includes internal links a crawler would otherwise follow immediately, structured data injected by a client-side script rather than present in the source, and any meta content a JS framework rewrites after hydration. If your canonical tag, title, or JSON-LD only reaches its final form post-render, all of it is on wave-two time, not wave-one time.

Where this actually bites. Not the blog post that's a day late. The product that just came back in stock, the price correction, the urgent fix you needed reflected in search results this week — anything time-sensitive rendered only client-side is gambling on a queue you don't control the length of.

What to actually do about it

  1. Serve time-sensitive content in the initial HTML response. Server-side rendering or static generation puts it in wave one, where there's no queue to wait for.
  2. Don't rely on client-side JavaScript for canonical tags, titles, or structured data if you need those recognized promptly — ship them in the source, not injected after hydration.
  3. Check Search Console's URL Inspection tool to see what Google actually has indexed for a given URL right now, not what your browser renders — the two can differ for exactly this reason.
  4. Treat "it's not showing up yet" as expected, not broken, for JS-rendered content on a normal publishing cadence — the fix is architectural, not a resubmission request.
The delay figure is a range, not a measurement. This site hasn't run its own controlled test of wave-two timing — the hours-to-weeks range above is drawn from published reports and Google's own public statements, not a first-party benchmark. Treat it as directionally reliable, not a number to plan a launch around precisely.
Deciding between server rendering and a client-side app? The Visibility pillar guide covers the render-strategy trade-offs this delay is a direct consequence of.

Badri Dutta

Software engineer · 8 years technical SEO

Eight years doing technical SEO and fifteen building for the web. This exists because "JavaScript SEO" content routinely states a specific delay figure as settled fact when Google itself has never committed to one.

Full background →