JavaScript SEO: What Actually Happens When Google Renders Your Site

“Does Google actually run my JavaScript?” is a question I still get regularly, usually from someone worried their React-powered filter widget or client-rendered content is invisible to search. The honest answer is yes, but with a delay and a process that’s worth actually understanding, because that delay is exactly where things quietly go wrong.

The three-phase process, straight from Google’s documentation

Google’s own JavaScript SEO documentation describes indexing as happening in three distinct phases: crawling, rendering, and indexing. Googlebot’s first pass fetches the raw HTML response and parses whatever links and content are present in it — no JavaScript execution yet. Pages are then queued separately for rendering, where Google’s Web Rendering Service (built on an evergreen, regularly updated version of Chromium) actually executes the JavaScript much the way a real browser would, before the resulting rendered content gets indexed.

This is commonly called two-wave indexing: wave one is the raw HTML Googlebot receives immediately, wave two is whatever the rendered DOM looks like after JavaScript executes. The gap between the two waves isn’t fixed — Google’s own guidance says it can range from seconds to days, depending on the site’s crawl budget and how Google’s systems currently prioritize that page. A high-authority site with lots of crawl budget might see the gap close in minutes. A smaller or newer site can wait considerably longer.

Content that only exists after JavaScript executes isn’t invisible to Google — but it’s not treated with the same immediacy as content already present in the raw HTML. That gap is the entire practical risk of client-side rendering.

Why this matters more than it used to

A reported clarification to Google’s documentation states that all pages returning a 200 HTTP status code get sent to the rendering queue — meaning non-200 responses (redirects, errors) may not get the same rendering treatment. I’d flag that specific wording as one to verify directly against the current primary documentation before quoting it precisely, since it came through secondary reporting rather than a page I could confirm firsthand while writing this. But the underlying principle it describes is consistent with how Google has talked about rendering priority for years: a healthy, 200-status page earns Google’s full rendering effort; anything else is handled with less certainty.

Where WordPress sites actually run into this

Most WordPress sites are server-rendered by default — the theme outputs real HTML, and that’s what Googlebot sees immediately in wave one. The JavaScript SEO risk shows up specifically where a site layers client-side rendering on top of that baseline:

Headless or decoupled WordPress setups, where WordPress serves as a backend for a JavaScript framework front end (Next.js, Gatsby, etc.). If that front end isn’t using server-side rendering or static generation, all your actual content depends entirely on wave two.
Heavy client-side filtering or infinite scroll — a product catalog or archive page where content only populates after a script runs client-side, common in some WooCommerce theme customizations and page-builder-driven layouts.
Third-party widgets injecting content via JavaScript — reviews, related-content blocks, or dynamically loaded sections that exist only in the rendered DOM, never in the raw response.
Single-page-app-style admin dashboards or member areas built with a JS framework and mistakenly left crawlable, where content genuinely can’t be indexed reliably at all if it requires user interaction beyond initial page load to appear.

How to actually check what Google sees

The mistake I see most often is assuming JavaScript SEO is fine because the page looks correct in a browser. A browser always executes the JavaScript. The question is what Google’s rendering process produces, and that requires checking directly rather than assuming:

Use the URL Inspection tool in Search Console and view the “Rendered HTML” and screenshot Google actually generated — this is the closest thing to ground truth for what wave two produced for that specific URL.
Compare the raw HTML response (view-source, or a simple fetch without executing JavaScript) against what appears after rendering. If critical content — main copy, key links, product details — only appears in the rendered version, that content is dependent on wave two timing, not immediately available.
Check whether critical internal links are present in the raw HTML. Even if content itself renders fine eventually, links that only exist after JavaScript execution are discovered later than links present in the initial HTML — which can affect how quickly new pages get found and crawled at all.

A quick test that doesn’t require any special tooling

If you want a fast gut-check before diving into Search Console’s URL Inspection tool, disable JavaScript entirely in your browser and reload the page you’re worried about. Whatever’s still visible is roughly what wave one sees; whatever disappears is dependent on wave two. This isn’t a perfect substitute for checking Google’s actual rendered output — Googlebot’s rendering environment isn’t identical to your browser with JavaScript switched off — but it’s a genuinely useful first pass for spotting content that’s obviously and entirely dependent on client-side execution, without needing to set anything up first.

The practical takeaway

For most standard WordPress sites — a theme rendering HTML server-side, standard content in the database, no headless front end — this is largely a non-issue, and worrying about two-wave indexing is solving a problem you don’t have. The sites that genuinely need to think carefully about this are the ones layering significant client-side rendering on top: headless setups, heavily JavaScript-driven filtering, or dynamically injected content that a plugin or theme loads after the initial page response. If that describes your setup, the fix isn’t avoiding JavaScript entirely — it’s making sure the content that matters for search is present in the initial server response wherever possible, rather than depending entirely on Google’s rendering queue to catch up.