Can Google really overlook your critical tags in the battle between initial and rendered HTML?

What does 'initial HTML' vs 'rendered HTML' really mean?

Initial HTML refers to the source code that the server sends to the browser — the one you see when you 'View Page Source'. It is the document's first state, before any JavaScript execution.

Rendered HTML is the final state of the DOM after all your scripts have modified the page. If React, Vue, or any framework injects canonical, noindex, or title tags on the client-side, it's this 'rendered' state that Googlebot analyzes secondarily, after the initial crawl.

Why does this distinction create indexing issues?

Googlebot first crawls the initial HTML, extracts critical tags, and then executes JavaScript to get the final render. If both versions contain conflicting instructions, the engine has no documented rule to decide.

Google may favor initial HTML one day, rendered the next — or even treat two identical pages differently depending on server load, crawl budget, or other opaque parameters. This non-determinacy is at the heart of the problem: you lose control.

Which tags are affected by this inconsistency?

Martin Splitt explicitly cites three tags: canonical, noindex, and title. However, the issue potentially extends to any indexing directives modified client-side.

A canonical pointing to URL A in the initial HTML and then to URL B after JavaScript execution creates an indeterminate situation. The same goes for a noindex tag that is absent at first and then injected by React, or vice versa. The engine is not obligated to respect either version — and in practice, it chooses unpredictably.

• Google crawls the initial HTML first, before any JavaScript execution
• The JavaScript render can modify canonical, noindex, title, and create inconsistencies
• In case of divergence, Google chooses arbitrarily — no documented rule
• Critical tags must be identical in both states to ensure expected behavior
• This rule applies to all sites using client-side JavaScript to manipulate the DOM

Is this statement consistent with real-world observations?

Yes. For years, it's been observed that Google erratically treats sites that inject critical tags via JavaScript. Pages marked noindex on the client-side end up indexed, rendered canonicals are ignored in favor of the initial version, and React titles disappear from SERPs.

What has changed is that Google now openly acknowledges the lack of guarantees. Previously, one could hope for convergence towards the final render — Martin Splitt explicitly tells us that this is not the case. The engine reserves the right to choose. [To be verified]: Google has never published stats on the frequency of each behavior or the decision criteria.

What nuances should be added to this rule?

The statement does not specify whether certain tags are more 'stable' than others. Empirically, we know that client-side titles are often ignored, but what about hreflang, meta descriptions, structured data? Google remains vague.

Additionally, this rule does not apply equally depending on the architecture: a site using SSR (Server-Side Rendering) or SSG (Static Site Generation) sends an already complete initial HTML, eliminating the issue at the source. The real danger lies in pure CSR (Client-Side Rendering) architectures where the initial HTML is almost empty.

In what cases can this inconsistency seem acceptable?

Some practitioners try to 'force' Google to index one version over another by manipulating render timing. For instance, blocking indexing in the initial HTML and then injecting a canonical via JavaScript after detecting the user-agent. This technically creates an inconsistency — but in this specific case, one seeks to deceive the engine.

Google guarantees nothing, but if your goal is to achieve unpredictable behavior for tactical reasons (cloaking edge cases, tests), this 'loophole' may seem useful. Obviously, this is playing with fire — and Splitt explicitly tells us that the behavior is 'undefined', thus unstable.

What should be done concretely to avoid these inconsistencies?

The rule is simple: all critical tags must be present and identical in the initial HTML. If you are using React, Next.js, Nuxt, or any other framework, configure server-side rendering so that canonical, noindex, and title are already in the source code before any JavaScript execution.

If you modify these tags client-side, ensure that the modification is strictly identical to the initial state — which means: do not modify them. Any divergence creates a risk of unpredictable indexing.

How can I check that my site follows this rule?

Compare the raw source HTML (right-click > 'View Page Source') with the inspected DOM after full loading. The canonical, noindex, and title tags must be rigorously identical.

Use the URL testing tool in Google Search Console to see what Googlebot crawls and renders. If the two versions differ in the screenshot or reported source code, you have a problem. An automated audit with Screaming Frog or Sitebulb can also detect these divergences — but beware, these tools sometimes render differently from Googlebot.

Which mistakes should be absolutely avoided?

Never let a JavaScript framework inject a canonical or noindex that does not exist in the initial HTML. This is the most frequent source of inconsistency: the developer adds the tag client-side 'for simplicity', without realizing that Google may ignore it.

Do not rely on JavaScript rendering to 'fix' a misconfigured server-side tag. If the initial HTML contains an erroneous canonical, do not attempt to replace it in JS — fix it at the source. Lastly, avoid client-side A/B tests that modify these tags: Google will see a random version, and you will have no guarantee.

• Generate all critical tags server-side (SSR, SSG, or classic server templates)
• Consistently compare source HTML and rendered DOM using DevTools
• Use Google Search Console to verify what Googlebot actually crawls
• Never modify canonical, noindex, or title via JavaScript after the initial render
• Regularly audit with Screaming Frog in 'JavaScript rendering' mode vs 'raw HTML'
• Document any changes to these tags to trace potential inconsistencies