Canonical tags on source pages

What the tag means

Many sites serve the same article at several addresses: with and without tracking parameters, under a category path and a date path, as an AMP or print version, or syndicated on a partner domain. The rel="canonical" link element (or the equivalent HTTP Link header) lets the publisher name the preferred one. Google's documentation lists it as a strong signal for choosing a canonical, alongside redirects (also strong) and sitemap inclusion (weak). It is not a command; Google can choose a different URL.

When Google settles on a canonical, it generally shows that URL in search results and treats the others as duplicates. A duplicate URL can be crawled without being the version Google indexes.

Why it matters for a backlink

A buyer reviews the URL the publisher sent in the delivery report. If that page declares a different canonical, three situations are possible:

The third and fourth rows are the costly ones. A guest post whose canonical points at the blog index page looks complete to a human visitor, yet Google is being told the article is a copy of something else. This is one of the quieter reasons a placement shows up as not indexed in source page indexation checks despite being crawlable and free of noindex.

Common causes on publisher sites

• Hard-coded canonicals in templates that output the category or home URL for every post.
• Syndication arrangements where the original article on another site is named as canonical. Press-release distribution pages often work this way.
• Paginated or parameterised URLs delivered by the publisher instead of the clean article URL.
• Migrations that changed URL structure while old canonicals still point at the previous paths.

How monitors record it

A monitor fetches the source page, reads any canonical declared in the HTML head or response headers, and stores the URL it found. Comparing that value with the monitored source URL after normalization (scheme, trailing slash, letter case in the host) separates harmless differences from real ones.

The IndexChex monitor stores the declared canonical URL on each check result alongside the robots meta, X-Robots-Tag and robots.txt findings. The canonical is recorded as evidence rather than turned into an outcome code of its own, because a cross-URL canonical is not automatically a failure: whether it hurts depends on what the canonical target contains. The outcome codes themselves are listed in the outcome code reference.

Treat the canonical as one input in a backlink health check, read together with the indexation result:

1. Canonical matches and the page is indexed: nothing to do.
2. Canonical differs, page not indexed: open the canonical target and look for your link.
3. Canonical differs, target lacks the link: raise it with the publisher.
4. Canonical differs, page is indexed anyway: Google chose the page despite the tag; keep monitoring, since that choice can change.

Canonical versus noindex

The two are often confused because both can keep a URL out of results. A noindex rule is a directive that Google follows once it sees it; a canonical is a consolidation hint. Google's guidance specifically advises against using noindex to pick a canonical. For the buyer, a noindexed source page (covered in noindex on source pages) is a clear defect, while a cross-URL canonical needs a second look before anyone is blamed.

Asking for a fix

The request to a publisher is narrow: set the article's canonical to its own URL. Include the declared value and the URL it should be. Template-level errors usually affect many posts at once, so publishers tend to fix them once shown. If the canonical is intentional (for example, syndicated content), the placement was not the independent article it appeared to be, and that is a matter for the original agreement and ongoing backlink monitoring records.