Google's indexing pipeline splits into stages that most SEO advice collapses into one. Separating them explains nearly every JavaScript SEO problem you will encounter.
The pipeline
- Crawl. Googlebot fetches the raw HTTP response. This is the HTML your server sent — not the DOM after scripts run.
- Process. Google parses that HTML, extracts links to schedule for crawling, and decides whether the page needs rendering.
- Render queue. Pages requiring JavaScript execution are queued for the Web Rendering Service, which runs a current version of headless Chromium.
- Render and re-process. The WRS executes scripts, produces a rendered DOM, and that DOM goes back through processing — new links discovered here get scheduled now, not earlier.
- Index. The result is evaluated for indexing.
The queue at step 3 is the crux. Google has said the delay is often short, sometimes seconds. "Often" is doing a lot of work in that sentence. For large sites, low-authority sites, or sites with constrained crawl budget, rendering can lag substantially behind crawling.
What breaks, and why
Links only present after render are discovered late. If your primary navigation is client-side rendered, Google cannot see those links in step 2 — it sees them in step 4, after the queue. On a small site this barely matters. On a large site with deep architecture, each level of depth compounds the delay, and the deepest pages can take a long time to be discovered at all.
Content that requires interaction is not seen. The WRS does not click, scroll indefinitely, or fill forms. Content behind a "load more" button, inside a tab that fetches on click, or below an infinite scroll that requires user scroll events is functionally invisible. Tabbed content that is present in the DOM but hidden with CSS is fine — the distinction is DOM presence, not visual visibility.
Failed resources fail silently. If a script is blocked by robots.txt, times out, or errors, the WRS renders what it can and moves on. There is no error surfaced in Search Console that says "your rendering failed." You get a page indexed with missing content and no obvious cause.
Canonical and meta directives from JavaScript are unreliable. A canonical tag or robots meta injected client-side may be respected, but conflicting signals between the raw HTML and rendered DOM resolve unpredictably. Put these in the server response, always.
Diagnosing it in three steps
One: compare raw against rendered. curl the URL and search the response for a distinctive sentence from the body copy. Then load the same URL in a browser and search the rendered DOM. If the text is in the browser but not in the curl output, that content depends on rendering.
Two: use the URL Inspection tool on the live URL. Search Console's "Test live URL" shows the rendered HTML that Google's own renderer produced, plus a list of page resources it could not load. That resource list is the single most useful diagnostic in JavaScript SEO and is routinely ignored.
Three: check the cache of the rendered output, not the source. Compare what is indexed against what you expect. A site: search with a distinctive phrase from a JavaScript-rendered section quickly tells you whether that content made it into the index.
The rendering strategies, ranked
Server-side rendering. The server returns complete HTML. Google sees everything in step 1, skips the queue, and the failure modes above largely disappear. Best outcome for SEO, highest infrastructure cost.
Static generation. Pages pre-built at deploy time. Same SEO benefits as SSR, cheaper to serve, works only for content that does not need per-request personalization. For marketing sites, documentation, and blogs this is close to strictly correct.
Dynamic rendering. Serve pre-rendered HTML to bots, client-rendered to users. Google has moved from recommending this to describing it as a workaround, and it introduces a maintenance burden plus a cloaking risk if the two versions drift apart. Treat it as a transitional measure.
Pure client-side rendering. Works for many sites, particularly small ones with strong authority. It is a bet that the render queue will be fast for you specifically, and that bet gets worse as the site grows.
The pragmatic rule
You do not need to server-render your entire application. You need the SEO-critical layer in the initial HTML response: the primary content, the internal links that define your architecture, the title and meta description, the canonical tag, the robots directives, and structured data.
Everything else — interactive widgets, personalization, dashboards, anything behind a login — can render client-side without consequence, because none of it is what you are asking Google to index.
That split is usually achievable without rewriting the application, and it converts a category of unpredictable indexing problems into a category of problems you no longer have.