Canonical Tag Checker: Find and Fix Broken Canonicals

A canonical tag checker reads the <link rel="canonical"> element on a page and tells you whether it exists, whether there is more than one, and whether the URL it names is a live, indexable page. You need one because canonicals decide which of several near-identical URLs collects the links and ranking signals, and they break far more often through templates and plugins than through anyone's deliberate choice.

On a single site you might open the source now and then. Across a client portfolio, canonicals change as a side effect of work nobody associates with SEO: a theme update, a new redirect rule, a staging copy that got crawled while its canonicals still pointed at the staging hostname.

What the canonical actually tells Google

The tag sits in the <head> and names the preferred URL for a piece of content, for example <link rel="canonical" href="https://example.com/shoes/">. It matters wherever the same content answers on several addresses: ?colour=blue and other parameters, http and https, trailing slash and no trailing slash, print versions, paginated or filtered category views.

Google treats it as a strong hint, not a directive. It weighs the canonical against redirects, internal links, the URLs listed in your sitemap and HTTPS, then picks its own. You can see the outcome for any URL in Search Console's URL Inspection tool, which shows a "User-declared canonical" next to a "Google-selected canonical". When those two differ, Google has decided your tag is wrong or not credible.

Two less obvious rules catch people out. A canonical placed in the <body> is ignored, which happens when a script or page builder injects it too late. And non-HTML files such as PDFs can only declare a canonical through an HTTP header: Link: <https://example.com/guide/>; rel="canonical".

Problems a checker should flag

Problem	What you find in the source	Typical result
Missing	No rel="canonical" at all	Google picks a version itself, often a parameterised one
Multiple	Two tags with different URLs, usually from a theme plus an SEO plugin	Google may disregard the declared canonicals entirely
Wrong target	Every product page canonicalised to one product, or to the homepage	Those URLs drop out as duplicates
Target is broken	Canonical points at a 404, a redirect, or a page with noindex	Contradictory signals, and the "real" page may not be indexed
Stale hostname	Canonical still names staging. or the pre-migration domain	Signals are sent to a site that should not rank
Relative URL	href="/shoes/" instead of an absolute URL	Works in principle, but misfires when the page is served on another host

The template-level cases do the most damage because they hit every page of a type at once. In the Page indexing report, they tend to surface as a jump in "Duplicate, Google chose different canonical than user" or "Alternate page with proper canonical tag".

Checking one URL by hand

For a page you are debugging, the manual route is fine:

1. Open view-source: and search for canonical. Count the matches.
2. Check the response headers too (curl -I https://example.com/page/) for a Link header, which can contradict the HTML.
3. Request the canonical target and confirm it returns 200, has no noindex, and declares itself as canonical.
4. Run the URL through URL Inspection to see which canonical Google actually selected.

Where the tag comes from depends on the platform. Yoast SEO and Rank Math output a self-referencing canonical by default and let editors override it per page in the Advanced tab, which is where copy-paste mistakes live. Shopify themes normally print {{ canonical_url }} in theme.liquid, so a customised theme that hardcodes a value affects every template using that layout.

Watching canonicals across many sites

A manual check tells you what a canonical says today. The expensive failures are the ones that change after your last look, so the useful question is what changed since yesterday.

Deltio checks the pages in each client site's sitemap on a daily cycle and compares canonicals, along with titles, meta descriptions, H1s, noindex and robots.txt, against the previous check. When a canonical changes or disappears, the alert goes to that site's Slack channel and email with the affected URLs. You can also run a manual SEO scan straight after a deploy instead of waiting for the next cycle. The limit is timing: a change made this morning shows up on the next daily check, not within minutes. If you already check title tags the same way, canonicals belong in the same routine.

You can add a client site on a 14-day trial and see what its canonicals currently say.