What happens when conflicting canonical tags in raw and rendered HTML block your page indexing?

What is the difference between raw HTML and rendered HTML?

Raw HTML corresponds to the source code as sent by the server during the initial request — this is what you see in a "curl" or in "View Page Source" in your browser. Rendered HTML is the final result after the execution of all client-side JavaScript: elements added, modified, or dynamically removed.

For modern sites built with React, Vue, or Next.js, this distinction is crucial. A canonical tag may be present in the initial HTML, then modified or replaced by a script that executes after the load. Google first crawls the raw HTML, then executes the JavaScript to get the final render — and that's where the problems arise.

How does this conflict manifest in practice?

Imagine a product page whose source HTML contains <link rel="canonical" href="https://example.com/product-a">. A JavaScript framework then loads and dynamically injects another tag pointing to https://example.com/product-a?variant=blue. Google receives two opposing signals regarding which URL should be considered the reference version.

The engine cannot reliably decide: should it prioritize the first declaration (raw) or the second (rendered)? This ambiguity paralyzes the indexing process or leads to arbitrary choices that do not align with your SEO intentions. You lose control over which URL appears in the SERPs.

What are the common causes of these conflicts?

Client-side routing systems (SPAs) are the main culprits: they manipulate the URL and the meta-tags after the initial render without coordination with the static HTML. Poorly configured templates in headless CMS can also generate a static canonical by default, then replace it via a misconfigured React component.

Tag managers (GTM, Segment) conditionally injecting canonical tags also create these inconsistencies. The same issue arises with some A/B testing frameworks that modify the canonicals based on displayed variants, without distinction between crawlers and human users.

• Raw vs rendered conflict: two different canonical tags depending on when the DOM is read
• Ambiguity for Googlebot: inability to reliably determine the reference URL
• Impact on indexing: ignored pages, incorrect URL indexed, or incorrect consolidation of signals
• Technical origins: SPAs, headless CMS, tag managers, poorly configured JavaScript frameworks
• Mandatory detection: systematically compare raw source HTML and final render using Google tools

Is this statement consistent with field observations?

Absolutely. Technical audits regularly reveal canonical discrepancies between raw and rendered, especially on headless e-commerce sites or media under Next.js. These conflicts result in pages stagnating in "Discovered – currently not indexed" for months, with no apparent explanation in the logs or Search Console.

Interestingly, Google does not specify which signal it prioritizes in the case of a conflict — raw or rendered. According to my observations, the behavior varies depending on contexts: on some sites, the rendered canonical prevails; on others, the raw one. This inconsistency confirms the ambiguity highlighted by Google. [To be verified]: no official documentation details the priority order applied.

What are the gray areas that Google does not mention?

The statement remains deliberately vague about the timing of JavaScript execution by Googlebot. If your canonical is injected after 5 seconds of loading, is it taken into account? What about rendering timeouts or JavaScript errors that prevent the execution of the script manipulating the canonical? Silence.

Another blind spot: what happens if the rendered canonical points to a URL that returns a 404 or a 301 redirect? Does Google follow this new directive or consider the conflict as a sign of poor technical quality and deprioritize the page? Edge cases are not documented, even though they are common in production.

In which cases can this problem be tolerated?

Let's be honest: if your site generates the same canonical in raw and rendered, even via JavaScript, you are technically in conflict (two declarations), but practically without risk since the signal is identical. The real danger occurs when there are URL discrepancies.

For fully static or well-configured SSR sites (Next.js with getServerSideProps, Nuxt in universal mode), the problem usually does not arise: the canonical is integrated into the initial HTML and no script modifies it. It is on pure CSR SPAs that vigilance is paramount.

How to detect these conflicts on your site?

Use the URL Inspection tool in Google Search Console: it displays the HTML as Googlebot sees it after rendering. Compare the canonical tag displayed in "Rendered HTML" with the one present in the raw source code (right-click > View Page Source). Any difference is a red flag.

To automate at scale, tools like Screaming Frog in JavaScript-enabled mode or OnCrawl allow you to crawl the site in two passes: one with JS disabled (raw), one with JS enabled (rendered). Export the canonicals from each pass and cross-reference the data in Excel or BigQuery to identify discrepancies. Sites with thousands of pages require this industrial approach.

What technical modifications should be prioritized?

If you are using a modern JavaScript framework, ensure that the canonical is managed server-side (SSR) or pre-generated at build time (SSG). With Next.js, prefer next/head in components loaded by getStaticProps or getServerSideProps — the canonical will be present in the initial HTML. Absolutely avoid useEffect that inject the canonical after mounting client-side.

For pure React/Vue/Angular SPAs, integrate a pre-rendering solution (Prerender.io, Rendertron) or migrate to a hybrid SSR mode. If that’s not feasible in the short term, make sure at a minimum that the JavaScript canonical is injected before any other script and that the raw HTML already contains the correct value as a fallback.

Should you completely remove JavaScript canonical tags?

Not necessarily. The issue is not the use of JavaScript to manage the canonical, but the contradiction between raw and rendered. If your source HTML contains no canonical tag and JavaScript reliably injects one, it can work — as long as Googlebot successfully executes the JS and the timing is correct.

However, the best practice remains to always provide the canonical in the initial HTML, and possibly validate/correct it via JS if needed (e.g., to handle dynamic URL parameters). This defensive approach ensures that even if JavaScript execution fails, Google receives a valid canonical signal.

These technical optimizations require a fine understanding of your site's architecture and how Googlebot crawls it. If you experience recurring conflicts or unexplained indexing issues, it may be wise to seek the expertise of a specialized technical SEO agency to audit your configuration and implement solutions tailored to your stack.

• Audit raw vs rendered using the Google Search Console inspection tool on a representative sample of pages
• Automate large-scale detection with Screaming Frog or OnCrawl in active/inactive JS mode
• Prioritize SSR or SSG to inject the canonical into the initial HTML (Next.js getStaticProps, Nuxt generate)
• Eliminate canonicals injected by GTM, third-party scripts, or A/B testing frameworks without coordination with the raw HTML
• Test modifications in a staging environment with the "Test Live URL" tool before production deployment
• Regularly monitor "Discovered – currently not indexed" pages that may signal unresolved canonical conflicts