This happens when the initial, unrendered HTML response and the final rendered DOM genuinely disagree on indexing-critical elements, most commonly the canonical tag, a noindex directive, the title, or core content itself. When that disagreement exists, Google’s indexing pipeline has discretion over which version’s signal it weights for a given decision, and it doesn’t always defer to the post-render state. This isn’t rendering failing, and it isn’t random; it’s a direct consequence of Google’s own long-standing guidance against relying on JavaScript to inject or change indexing-critical directives, playing out exactly as that guidance warns.
Why raw HTML and rendered DOM disagreements happen
Google’s indexing process for JavaScript-heavy pages happens in stages. Googlebot first fetches the raw HTML response from the server, the same thing you’d see with view-source before any script executes. Some initial signals can be extracted and used at this stage, independent of whatever the JavaScript on the page will eventually do. Later, if the page is queued for rendering (a separate step, not guaranteed to happen immediately), the Web Rendering Service executes the JavaScript and produces a fully rendered DOM, which is then used to extract additional or updated signals.
Under normal circumstances, where the raw HTML and the rendered DOM broadly agree, once you account for JavaScript legitimately adding content, this two-stage process is invisible and unremarkable; the rendered version simply supersedes the initial snapshot for content purposes. The anomaly the question describes shows up specifically when the two stages disagree about something Google treats as a strong directive rather than ordinary content. A canonical tag present in the raw HTML pointing to one URL, but altered or removed by client-side JavaScript in the rendered version, is the clearest example. A noindex meta tag present pre-render but stripped out post-render (or the reverse, absent initially but injected by a script) is another. A title tag that differs meaningfully between the two states is a milder version of the same pattern.
Google has documented, repeatedly and specifically, that it does not recommend relying on JavaScript to insert or modify rel=canonical, precisely because of this ambiguity. The underlying reason is architectural rather than arbitrary: canonical signals and noindex directives are used earlier and more structurally in Google’s pipeline than ordinary content is. Content extraction naturally happens against the fully rendered DOM because that’s the version that actually represents what a user sees. But directives that affect whether and how a URL should be indexed at all carry a kind of precedence risk, if the raw HTML and rendered DOM disagree on such a fundamental instruction, which one should Google trust as the “real” statement of intent from the site owner? Google’s systems don’t guarantee they’ll always wait for and defer to the fully rendered version for these specific signals, and in some observed cases, they clearly don’t, falling back to or otherwise weighting the pre-render HTML value instead.
It’s worth being precise that this isn’t a bug in the conventional sense, and it isn’t something Google has described as happening due to a specific named glitch. It’s presented in Google’s own JavaScript SEO guidance as a predictable consequence of introducing exactly this kind of inconsistency between the two rendering stages. The safest interpretation is that Google’s systems have discretion to use either signal when they conflict, and that discretion isn’t something site owners can reliably predict or control on a case-by-case basis.
A hypothetical illustration
As a hypothetical illustration: imagine a hypothetical SaaS company called Northwind Analytics rebuilding its marketing site on a JavaScript framework. Suppose a developer sets the canonical tag server-side to point every regional variant of the pricing page back to a single default URL, but a client-side script, added later to support a separate personalization feature, rewrites the canonical tag after the page loads so it self-references instead.
Hypothetically, Googlebot’s initial fetch of the raw HTML sees the server-rendered canonical pointing to the default pricing URL, but if a render is queued and completed, the rendered DOM shows a different, self-referencing canonical. Suppose Google’s indexing pipeline, faced with that disagreement, ends up weighting the raw HTML’s canonical value in some cases and the rendered value in others, producing inconsistent indexing behavior across Northwind’s regional pricing pages, some consolidating as intended, others not. In this scenario, checking Search Console’s URL Inspection tool and comparing the raw HTML source against the rendered DOM would reveal the mismatch directly, and the fix would be moving the canonical logic so it’s correct in the server-rendered HTML from the start, rather than leaving it dependent on a client-side script that may or may not execute before Google’s indexing decision is made.
What to do about canonical tags and noindex directives in JavaScript
The practical fix is to eliminate the inconsistency at its source rather than trying to predict which version Google will trust. Canonical tags, noindex/robots directives, and the title should be present, correct, and complete in the raw server-rendered HTML response, before any client-side JavaScript executes, for any page where getting this right matters. If a framework or CMS is currently setting or modifying any of these values via client-side script, that’s the specific pattern to change, moving that logic to server-side rendering, static generation, or another mechanism that produces the correct value in the initial HTML response itself.
This doesn’t mean JavaScript can never touch page content Google indexes; ordinary content additions and enhancements rendered via JavaScript are handled through the normal rendering pipeline without this particular risk. The risk is narrow and specific to indexing directives and the handful of elements Google treats as authoritative signals about how to handle a URL. Auditing a site for exactly this pattern, comparing the raw HTML source against the fully rendered DOM (available side by side in Search Console’s URL Inspection tool) for canonical tags, robots meta directives, and titles specifically, is the direct way to check whether a given site is exposed to this problem before it shows up as an unexplained indexing inconsistency.
