CanonicalTag.com logo, a canonical tag referenceCanonicalTag.comThe canonical tag, explained
Diagnose and fix

Canonical tag issues and fixes

Most canonical tag issues are not errors. They are disagreements between the URL a page nominates and the URL Google selects, or between the tag and the site's other signals. This page sorts every issue by how much attention it deserves and traces each one back to its source.

Reading the Search Console statuses

The Page indexing report files its canonical states under reasons pages are not indexed, and that framing leads people to treat them as failures. Most are Google working as intended. Two facts sort every status: whether you declared a canonical at all, and whether Google accepted it. URL Inspection shows both side by side, as the user-declared canonical and the Google-selected canonical, and that comparison is the first thing to check before changing any markup.

An override is a prompt to look, not a verdict against the site. Google is often right: it may have preferred the HTTPS version, the one with more internal links, or the one your own redirects already favor. Decide first whether you actually disagree with its choice. If you do, the fix is to put every signal behind the preferred URL, so that the tag, the sitemap, the internal links and the redirects all name the same address, rather than restating the tag and waiting.

How conflicts arise

Conflicts come from signals that contradict each other, usually because two systems each believe they own the canonical. The most mechanical case is multiple canonical tags on one page, typically a theme and an SEO plugin each printing its own, which may lead Google to ignore every one of them and fall back on its own choice. A subtler case begins when a developer adds a robots rule to a page whose canonical already points elsewhere. Canonical and noindex together ask Google to consolidate the page and drop it at the same time, and the noindex rule tends to win.

Other conflicts are logical rather than mechanical. Canonical tags and pagination go wrong when a template points pages two, three and four at page one, which declares the deeper pages duplicates even though each lists different items and links to different products. A related failure is the non-indexable canonical: a target that redirects, returns a 404, carries a noindex rule or is blocked in robots.txt asks Google to consolidate onto a URL it cannot index. Point every canonical straight at a final URL that returns 200.

A cross-domain canonical is technically supported as a hint, but for syndicated articles Google now prefers that partners keep their copy out of the index rather than point it back at the original, because republished pages often differ too much for the hint to hold. The self-referencing canonical sits at the other end of the scale: the baseline that prevents much of this, because every variant of a page arrives with an unambiguous answer attached. Its own failure is subtle, a template that self-references the variant being served, parameters and all, instead of the clean URL.

Where duplicate URLs come from

The third group is a supply problem: the URLs that make canonicalization necessary. Host and protocol variants are the oldest source, and settling them starts with a canonical domain: one host, with or without www, served over HTTPS. Search Console retired its preferred domain setting in 2019, so the choice now rests on redirects, internal links and consistent canonicals that all name the same host and protocol. Canonical redirects enforce the choice with a single 301 or 308 hop from every variant. Chains, loops and platforms that default to a temporary 302 are the defects that turn up most.

Parameters and variants multiply URLs faster than hosts do. URL parameters for tracking, sorting and faceted navigation create near-identical pages, and a canonical consolidates them for indexing without stopping Google from crawling them, which is why crawl control is a separate decision with a separate set of tools. Product variants have two valid models: one URL per color or size, each canonicalizing to itself, or one base URL that every variant consolidates to. Either works when it is applied consistently across the catalog.

Some duplicates are paired by design. AMP pages carry a canonical pointing at the regular page, and m-dot mobile URLs point theirs at the desktop URL, with a matching annotation in the other direction; if either half is missing, Google may ignore the pair. Files with no HTML head, such as PDFs, can declare a canonical in an HTTP Link header instead. That header is invisible in page source, so it is easy to miss when an HTML tag on the same resource says something different.

Finally, non-canonical URLs are normal, and every site has them. Audit tools flag them because they turn up where they do not belong: in XML sitemaps, in internal links, in hreflang annotations, and as the targets of other canonicals. A duplicate address existing is not the defect. Pointing the site's own signals at it is, because each of those references is a vote for a URL you have asked Google not to choose.

A sensible order of work

When an audit returns a long list, fix whatever makes the canonical unreadable first: several tags on one page, tags outside the head, and targets that redirect or fail. Next, remove contradictions, such as noindex paired with a canonical or paginated pages pointed at page one. Then tighten supply with redirects and parameter handling. Only after that is it worth reading the remaining Search Console statuses, because by then most of them describe choices you made deliberately.

Every issue at a glance

Canonical issues with their verdicts
PageGroupVerdict
Duplicate Without User-Selected CanonicalGoogle Search Console StatusesReview it: declare a canonical if Google's pick is wrong
Alternate Page With Proper Canonical TagGoogle Search Console StatusesUsually no action needed: the canonical is working
Self-Referencing Canonical TagsConflicts & Edge CasesRecommended on every indexable page, not required
Duplicate, Google Chose Different Canonical Than UserGoogle Search Console StatusesInvestigate: remove the conflicting signal, or agree with Google
Duplicate, Submitted URL Not Selected as CanonicalGoogle Search Console StatusesFix the sitemap: list only canonical URLs
User-Declared vs Google-Selected CanonicalGoogle Search Console StatusesA mismatch is a hint to investigate, not an error
Canonical Tag and Noindex TogetherConflicts & Edge CasesPick one: do not combine them on the same page
Canonical Tags and PaginationConflicts & Edge CasesSelf-canonicalize each page; never point page 2 at page 1
Cross-Domain Canonical TagsConflicts & Edge CasesWorks as a hint; for syndication Google prefers noindex
Multiple and Conflicting Canonical TagsConflicts & Edge CasesFix it: Google may ignore every one of them
Canonical Pointing to a Redirect, 404, or Noindexed PageConflicts & Edge CasesFix it: point straight at the final 200 URL
Canonical RedirectsURL Variants & Duplicate URLsEnforce it: one-hop 301 or 308 from every variant
Canonical Domain: www, Non-www, HTTP and HTTPSURL Variants & Duplicate URLsChoose one host on HTTPS and redirect everything else
Non-Canonical URLsURL Variants & Duplicate URLsNormal to have; keep them out of sitemaps and links
Canonical in the HTTP HeaderURL Variants & Duplicate URLsSupported by Google; use it for PDFs and other files
Canonical Tags and URL ParametersURL Variants & Duplicate URLsCanonical consolidates but does not stop crawling
Canonical Tags for Product VariantsURL Variants & Duplicate URLsTwo valid models; pick one and apply it consistently
Canonical Tags for AMP and Mobile URLsURL Variants & Duplicate URLsPair the annotations both ways, or Google ignores them

Google Search Console Statuses

5 pages

The canonical states you see in the GSC Page indexing report, what each one means, and how to respond.

Conflicts & Edge Cases

6 pages

How the canonical tag interacts with noindex, pagination, hreflang, redirects, and other signals.

URL Variants & Duplicate URLs

7 pages

Where duplicate URLs come from in the first place: host and protocol variants, redirects, parameters, product variants, AMP and mobile URLs, and non-HTML files.

Top