Multiple canonical tags means one page declares its preferred URL more than once with <link rel="canonical">. Conflicting canonical tags can lead to unexpected results: Google may disregard them and choose the canonical itself. The fix is to find which theme, plugin or layout adds the extra tag and keep exactly one.
What a canonical conflict looks like
Open the page source and you find two canonical tags in the <head>, often far apart:
<head>
<link rel="canonical" href="https://example.com/shoes/trail-runner">
...
<link rel="canonical" href="https://example.com/shoes/trail-runner?color=blue">
</head>
Sometimes both tags point at the same URL. That looks harmless, but it is still a sign that two systems write to the same <head>, and the day one of them changes its URL logic, they start to disagree.
Why it matters
- Your canonical stops being a reliable hint. Conflicting or multiple canonical tags can lead to unexpected results. Google then chooses the canonical from other signals, such as redirects, internal links and the sitemap.
- The wrong URL can rank. If Google picks a parameter version or an old path, that is the address people see in search results and in AI answers that cite the page.
- Ranking signals split. Links pointing at the duplicates are only consolidated when Google trusts your canonical. Without it, they can stay spread across several URLs.
- Search Console shows the symptom. Pages with conflicting canonicals can end up as Duplicate, Google chose different canonical than user.
Why it happens
Canonical conflicts are almost never written by hand. They appear when two parts of the stack both believe they own the <head>:
- Two SEO plugins active at the same time, or an SEO plugin plus a theme that hardcodes its own tag.
- A theme update that adds a canonical the site already gets from an app or plugin.
- Nested layouts in a JavaScript framework, where a shared layout and a page both print a tag.
- Marketing scripts or tag managers that inject a canonical after the page loads.
- A migration that kept the old template's tag next to the new system's metadata.
How to fix it
Decide which system owns the canonical, usually your SEO plugin or the framework's metadata API, and remove the tag from everything else. The one tag that stays should be absolute, use HTTPS and point at a page that returns 200. The missing canonical tag guide covers what a good canonical looks like.
Let the Metadata API write the canonical and delete any hand-written <link rel="canonical"> from layouts and pages:
export const metadata: Metadata = {
alternates: { canonical: '/shoes/trail-runner' }
}
Next.js merges metadata from the root layout down to the page, so the deepest alternates.canonical wins and only one tag is rendered. Duplicates come from a manual tag in layout.tsx or from an extra SEO package that also writes to the <head>. Remove those and keep the Metadata API as the single source.
WordPress core prints a canonical on single posts and pages, and SEO plugins such as Yoast SEO and Rank Math replace it with their own. Conflicts mean something else adds a tag too:
- Keep only one SEO plugin active.
- Search your theme's
header.phpandfunctions.phpforrel="canonical"and remove any hardcoded tag. - If a plugin you need prints its own canonical, turn that option off in its settings rather than editing plugin files.
Shopify themes print the canonical from theme.liquid:
<link rel="canonical" href="{{ canonical_url }}">
Keep this line and remove any second one. Conflicts usually come from an SEO app that injects its own tag, or from a theme snippet that was copied into a section. Search the theme code for canonical and check installed apps for a canonical setting.
Let AI fix it, page by page.
Paste this prompt into AI with your project open. In UpCrawler, every affected page comes with a prompt like this, already filled in with its URL.
Leave exactly one canonical per page. Remove the duplicates injected by a plugin or a nested layout, and confirm the survivor is absolute and resolves to a 200.
How to keep it from coming back
- One owner for the
<head>. Document which plugin, app or file writes the canonical, and turn the feature off everywhere else. - No canonicals from JavaScript. Keep the tag in the server HTML, and make sure no script or tag manager adds a second one or changes its URL.
- Check after every theme or plugin update. These are the moments a second tag appears.
- Keep every signal on the same URL. Internal links, the sitemap and hreflang should all use the canonical address, so Google's choice and yours match even while a fix is waiting for a recrawl.
- Watch for duplicate content. A clean single canonical is what consolidates duplicate URLs, so fixing conflicts often clears duplicate groups too.
Frequently asked questions
What happens if a page has two canonical tags?
Conflicting canonicals can lead to unexpected results. Google may disregard them and pick the canonical itself from other signals. The page still gets crawled, but you lose control over which URL is indexed and shown.
Are two identical canonical tags a problem?
Usually not for indexing, because both point at the same URL. It is still worth fixing, since it means two systems write the tag and they will disagree as soon as one changes.
Can I set the canonical in the HTTP header instead?
Yes. A Link: <https://example.com/page>; rel="canonical" response header is useful for PDFs and other files without a <head>. For HTML pages, pick one method, because a header and an HTML tag that disagree are another kind of conflict.
How long until Google uses the fixed canonical?
Google needs to recrawl the page. Request indexing in URL Inspection for important pages; the rest update as Google revisits them, which can take days to weeks.
Share it with whoever runs your site’s SEO.
