Why does Google ignore your canonical tags when the raw HTML contradicts the rendered output?

Where does this confusion between raw HTML and rendered HTML come from?


The raw HTML corresponds to the source code sent directly by the server when a browser (or Googlebot) makes an HTTP request. This is what you see if you view the source of a page via 'View Page Source' in Chrome.

The rendered HTML corresponds to the state of the DOM after executing the client-side JavaScript. If your framework (React, Vue, Angular, Next.js in partial CSR mode) injects, modifies, or replaces a <link rel="canonical"> tag via JS, Google first sees one version, then another after rendering indexation.

Why does this divergence pose a problem for Google?


Google first crawls the raw HTML, then queues the page for JavaScript rendering. This process is neither instantaneous nor guaranteed: some pages may wait for days or even weeks before being rendered. In the meantime, Googlebot has already extracted signals from the raw HTML — including the canonical.

When the canonical changes after rendering, Google inherits two contradictory instructions for the same URL. The engine has no way of knowing which one is 'the right one' — which breaks the consolidation logic. Martin Splitt claims that in this case, Google may choose a third URL as canonical or toggle between the two versions depending on crawl cycles.

What does 'toggle between the two versions' actually mean?


This means that during a crawl, Google retains the canonical from the raw HTML, then on a subsequent crawl (after rendering), switches to the canonical from the rendered HTML. This instability fragments ranking signals: backlinks, anchors, click history, everything gets diluted across multiple URLs.

In Search Console, you observe inconsistent coverage reports: a URL marked 'Duplicate – canonical URL different from that defined by the user', then reclassified as 'Indexed', then marked duplicate again. It's impossible to manage your indexing properly under these conditions.

• Mixed signals = Google can't decide which URL to consolidate as the reference.
• Canonical toggling = your GSC metrics become unusable for performance tracking.
• Arbitrary choice = Google may select a URL that you've never defined as canonical, diluting your authority.
• Crawl budget impact = the bot wastes time crawling and reprocessing unstable variants instead of discovering fresh content.

Is this statement consistent with field observations?


Yes, and it confirms a phenomenon that many SEO practitioners mistakenly attributed to 'bugs' from Google. In reality, it's a poorly managed front-end architecture issue. Sites migrating to modern JS frameworks (Next.js, Nuxt, SvelteKit) without strict SSR often fall into this trap.

This behavior is particularly observed on e-commerce sites where the canonical is managed via a React component that loads after the initial HTML. As a result, Google first indexes the product page with an empty or generic canonical, then switches to the correct URL after rendering — but in the meantime, backlinks have landed on the wrong variant.

What nuances should be added to this claim?


Martin Splitt mentions a 'completely different' choice of canonical by Google, but he doesn’t specify the exact criteria for this choice. [To be verified]: it can be assumed that Google uses other signals (sitemaps, majority internal links, external backlinks) to arbitrate, but no official confirmation on the exact weighting.

Another unclear point is the frequency of toggling. Does Google switch each crawl? Only during rendering cycles? Or randomly based on the load of the rendering servers? Again, no publicly available data. We are navigating in a dependent manner, in an empirical observation mode.

In what cases does this rule not strictly apply?


If your site is 100% static (complete SSG, without client-side JS hydration modifying meta tags), you are safe. Raw HTML = rendered HTML, so no divergence. This is the case for well-configured Gatsby, Hugo, or Jekyll sites.

Also, if you are using strict SSR (Server-Side Rendering) where the server sends the final HTML directly with the correct canonical, and the client-side JS never touches this tag, you remain safe. But as soon as a third-party library (tracking, consent, CMP) injects or modifies tags in the <head>, the risk reappears.

What should be done concretely to avoid this problem?


First, audit your raw vs rendered HTML for all your strategic pages. Compare the server source code (curl or 'View Page Source') with the DOM state after full loading (DevTools → Elements). If the canonical tags differ, you are in the red zone.

Next, prioritize server-side rendering for critical tags: canonical, hreflang, meta robots, structured data. Never allow JavaScript to modify these elements after the first paint. If your framework requires it, configure strict SSR or SSG for indexable pages.

What errors should be absolutely avoided?


Never inject a canonical tag via a useEffect in React, a mounted() in Vue, or a script that runs after the DOMContentLoaded. Google crawls the raw HTML as a priority — your JS may take seconds to execute, and in the meantime, the signal is already sent.

Another classic trap: headless CMS (Contentful, Strapi, Prismic) that generate canonicals client-side via asynchronous API requests. If the API takes 500 ms to respond, your initial HTML is missing a canonical, which then appears after rendering. Google sees two incompatible states.

How can I check if my site is compliant?


Use the URL inspection tool in Search Console: compare the 'Raw HTML' tab with 'Screenshot' (which reflects the rendering). If the canonicals diverge, you have a problem. Do this check on 10-15 standard pages (home, categories, products, articles).

Complement this with a Screaming Frog crawl in JavaScript mode: compare the 'Canonical Link Element 1' (raw HTML) and 'Rendered Canonical' (after JS) columns. Any divergence = potential mixed signal. Prioritize fixing high-traffic organic pages and backlinks.

• Audit raw vs rendered HTML on 15 strategic pages using the GSC inspection tool
• Configure strict SSR for all canonical tags, hreflang, and meta robots
• Never inject a canonical tag via client-side JavaScript (useEffect, mounted, etc.)
• Crawl the site with Screaming Frog in JS rendering mode and compare raw vs rendered canonicals
• Verify that headless CMS send canonicals in the initial HTML, not via asynchronous API requests
• Monitor GSC coverage reports to spot canonical switches between two crawls