Canonical Tag in HTML and HTTP Header: How to Fix the Conflict

The short version

This check fires when a single page declares a canonical twice — once as a <link rel="canonical"> in the HTML head and once as a rel="canonical" in the HTTP Link: response header. Google accepts either method, but two declarations on one URL is a redundancy at best and a contradiction at worst, and when they disagree Google can distrust both and canonicalize on its own.

Two valid methods, one URL, one problem

There are two legitimate places to put a canonical: in the HTML head, or in the HTTP response header. Google treats them as equivalent — either alone works perfectly. The failure mode is using both on the same page. When they name the same target it's harmless clutter that invites future drift. When they name different targets — which is common, because they're usually set by different systems that don't know about each other — you've handed Google two contradictory instructions for one URL.

This is distinct from a mismatch between you and Google, and distinct from a malformed tag. Here both declarations can be individually valid and well-formed; the defect is that there are two of them, emitted by two different layers of your stack, and nothing guarantees they agree. Typically the HTML tag comes from the CMS or an SEO plugin and the header comes from the server, a CDN edge rule, or a reverse proxy — three places that rarely coordinate.

Why it matters

Google's guidance on conflicting canonicals is blunt: when it sees multiple canonical declarations that disagree, it may treat all of them as unreliable and ignore the lot, then pick a canonical itself. So a page that looks thoroughly canonicalized — belt and suspenders, tag and header — can end up with no honored canonical because the two fought. Even when they currently agree, you've built in a landmine: the day someone changes the CDN rule or the plugin default, the two silently diverge and your canonicalization breaks with no visible edit to the page. Redundant signals aren't safety; they're two things to keep in sync forever.

Seeing both declarations, and which to keep

Pull the headers and the body together and you'll see the duplication — here they even disagree on the trailing slash:

$ curl -sI -A 'Mozilla/5.0' https://example.com/page
HTTP/2 200
content-type: text/html; charset=UTF-8
link: <https://example.com/page>; rel="canonical"

$ curl -s -A 'Mozilla/5.0' https://example.com/page | grep -i canonical
<link rel="canonical" href="https://example.com/page/" />

The header says /page, the head tag says /page/ — two different URLs, one page, and Google gets to guess. The fix is to keep one method and kill the other. For most CMS-driven sites the HTML head tag is easiest to control, so drop the header:

# Keep ONLY the HTML head tag; remove the server/CDN Link header.
# Result — one canonical, one method, no conflict:

$ curl -sI -A 'Mozilla/5.0' https://example.com/page/
HTTP/2 200
content-type: text/html; charset=UTF-8      # no link: rel=canonical header

$ curl -s -A 'Mozilla/5.0' https://example.com/page/ | grep -i canonical
<link rel="canonical" href="https://example.com/page/" />

Which source is emitting the extra canonical?

How to detect it

1. curl -I for the header. Run curl -sI -A 'Mozilla/5.0' URL and look for a link: line containing rel="canonical". Then run curl -s URL | grep -i canonical for the head tag. Two hits across the two commands = two declarations on one page.
2. Screaming Frog. Crawl and open the Canonicals tab. Frog reports both the HTTP Canonical (from the header) and the HTML Canonical (from the head) in separate columns — filter for rows where both are populated, and especially where they differ.
3. GSC URL Inspection. Inspect the URL and read the User-declared canonical. If it's blank or shows a URL you didn't expect while both a header and a tag exist, Google may already have discarded the conflicting pair — a sign the two are fighting.
4. View Rendered Source / DevTools Network. Open the Network panel, select the document request, and read the Response Headers for a link: rel=canonical while the Elements tab shows the head tag. Seeing both at once confirms the redundancy.

How to fix it

1. Decide on one method for the whole site — for most stacks, the HTML head tag, since it's the easiest to see and control.
2. Find who's emitting the second one. A canonical Link: header almost always comes from server config, a CDN rule, or middleware, not the CMS.
3. Remove the redundant declaration at its source so exactly one canonical method remains.
4. If you must keep both for a technical reason, make them byte-for-byte identical — same protocol, host, path, case, and trailing slash — so they can never disagree.
5. Re-run curl -sI and curl -s | grep canonical to confirm only one declaration survives, then re-inspect in GSC to confirm the user-declared canonical is what you intended.

FAQ

If both canonicals point to the same URL, is it still a problem?

It's not actively broken, but it's a liability. You now have two systems that must stay in perfect sync indefinitely, and the first config change to either one — a CDN tweak, a plugin update — can split them without touching the page itself. Remove one now while they agree; don't wait for the drift.

Which one wins when the header and the head tag disagree?

There's no guaranteed winner. Google treats the two methods as equivalent, so a genuine conflict is exactly the "multiple conflicting canonicals" case it may distrust and ignore entirely — after which it self-selects. Don't rely on a precedence rule that doesn't exist; eliminate the conflict.

Is the HTTP header canonical worse than the HTML tag?

No — the header method is completely valid and is actually the required approach for non-HTML files like PDFs, which have no head to put a tag in. It's only a problem when it duplicates a head-tag canonical on the same HTML page. Pick one per page.

How do I set a canonical on a PDF, then?

Use the HTTP Link: header — that's precisely what it's for, since a PDF has no HTML head. This check isn't about banning the header method; it's about not doubling up on a single HTML page where both are possible.

My SEO plugin and my CDN both set a canonical. Which do I disable?

Usually the CDN/server one, and keep the plugin's head tag, because the plugin is easier to audit and reason about per-page. But whichever you can control most reliably is the right one to keep — just make sure only a single source emits a canonical after you're done.

Related reading

Read the canonical tag glossary and Canonical Tags reference for the rules on both methods, and why the rel="canonical" HTTP header is faster if you're weighing which to keep. For header mechanics generally, see HTTP header optimization for SEO. If your two declarations disagree on the target, that overlaps with canonical mismatch.