Multiple canonical tags: find the generator that disagrees

Capture all three delivery layers

In the fixture, GET /products/blue-mug returns a valid product. The application’s server template declares that product as canonical. A legacy CDN rule adds a Link header naming /collections/mugs, while a hydrated component appends a request-derived tag containing ?campaign=email. The browser’s document.head cannot reveal the HTTP header; View Source cannot reveal the later append.

Google recommends choosing either an HTML annotation or an HTTP canonical header because combining them makes contradictory targets easier to introduce. Both matching declarations and conflicting declarations deserve an ownership review, but they are different findings. Two identical tags do not establish that Google rejected the page; two different targets do not come with a documented first-tag-wins rule.

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Link: <https://example.com/collections/mugs>; rel="canonical"

<head>
  <link rel="canonical" href="https://example.com/products/blue-mug">
</head>

<link rel="canonical" href="https://example.com/products/blue-mug">
<link rel="canonical"
      href="https://example.com/products/blue-mug?campaign=email">

Assign each observation to its generator

Disable the redundant emitter in the source configuration, then inspect its output. In a CMS that may mean the theme versus an SEO plugin; in this fixture it means an edge rule versus a route template versus client metadata. Deleting a node in DevTools changes only the current browser document and will not repair the next response.

Treat URL values literally until you establish equivalence. An uppercase path, trailing slash, language parameter or product option can identify different content. Resolve relative URLs using the actual document base, then inspect the final targets. Do not erase a query or switch hosts simply to make a comparison pass.

The corrected capture has one stable preference

The route template owns the product identity. The edge canonical header is removed; the client preserves the existing server declaration rather than appending another. The product remains available at the campaign address when tracking requires it, while the canonical identifies the equivalent clean product.

Google’s JavaScript guidance cautions against changing an existing canonical to a different value. Rendering can discover an injected annotation, but it is a poor place to repair a contradictory initial head. Deliver the intended declaration in the initial HTML when you can.

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8

<head>
  <link rel="canonical" href="https://example.com/products/blue-mug">
</head>

[...document.head.querySelectorAll('link[rel~="canonical"]')]
  .map(node => ({ declared: node.getAttribute("href"), resolved: node.href }));

Verify the family, not just the page you edited

Fetch the public product response again, including its headers. Open the direct product URL, its campaign variant and a second product using the same template. Check the canonical count after a direct load and after navigating between products. A component can be correct on the first mount and append stale metadata on the next route.

Confirm that the target returns the intended product, does not redirect to a different offer, and is eligible for the intended indexing decision. Check robots meta and X-Robots-Tag separately: a perfect canonical cannot rescue an unwanted noindex directive.

Use the canonical + noindex comparison for exclusion conflicts and the proper-canonical alternate example for harmless tracking duplicates. The hub’s capture checklist keeps response, rendering and discovery checks together.

A canonical and noindex conflict requires a separate indexing decision after the canonical generators agree.

Check Google after it sees the changed response

URL Inspection distinguishes the indexed report from the live test. Read the crawl date, user-declared canonical and Google-selected canonical for the source and target. A live accessibility result does not prove that Google has reprocessed the duplicate family.

Keep the deployment date separate from Google’s observation. The immediate acceptance condition is the corrected public response and stable template behavior. The later search check asks whether Google chose an appropriate representative. Neither the repair nor a tidy tag count guarantees a ranking change.