Fixing Canonical Tag Errors: Missing or Broken Tags

What the canonical tag does, and what it does not

The canonical tag looks like this and belongs inside <head>:

<link rel="canonical" href="https://www.example.co.uk/garden-furniture/oak-bench/">

It tells search engines: if you find this content at more than one address, this is the address I would like you to index and show. It is useful because the same page is often reachable in several ways, for example with a tracking parameter added by an email campaign, with a sort order added by a filter, or through a second category path in a shop.

Three points about the tag are worth keeping in mind before changing anything:

• It is a hint, not a command. Google weighs the canonical alongside redirects, internal links, sitemaps and the content itself, and can pick a different address if the other signals point elsewhere. A correct tag makes its choice easy; a wrong tag makes it harder.
• It does not hide a page. A page with a canonical pointing elsewhere can still be crawled, and visitors can still reach it. If you want a page kept out of search entirely, that is a job for the robots meta tag, not the canonical.
• It only works in the head. Google only accepts rel="canonical" when it appears in the <head> of the HTML, or in an HTTP Link header. A tag that ends up in the body, which happens when a stray element or broken markup closes the head early, is ignored.

This guide covers faults in the tag itself. When the tag is fine but the redirects, sitemap and internal links name a different address, the problem is a conflict between signals across the site, which has its own guide: canonical conflicts.

The canonical findings and what each one means

The analyzer reads the canonical from the HTML your server returns and compares it with the address it fetched. These are the faults it most often turns up, roughly in order of how much damage they can do.

The right canonical for each type of page

For the great majority of pages the answer is simple: the canonical should be the page's own clean address. That is called a self-referencing canonical. The exceptions are the page types below, and they are where most wrong tags come from.

Ordinary pages, posts and products

Self-referencing, using the address you want in search: https, your chosen host (with or without www), your chosen trailing-slash style, lower case if your platform treats case as different, and no query string.

Paginated lists

Page 2 of a category should name page 2 as its canonical, not page 1. Pointing every page of a series at the first page asks search engines to treat different lists of products or articles as duplicates, and items that only appear on later pages can become harder to discover. Google stopped using rel="prev" and rel="next" as an indexing signal some years ago, so there is no need to add them for Google's sake, though they do no harm.

Filtered and sorted views

A category sorted by price shows the same products as the unsorted category, so its canonical should normally point to the unsorted address. A filter that produces a genuinely different page that people search for, such as a colour or material landing page with its own text, can be self-referencing instead. Decide this per filter, not per page.

Product variants

If each colour or size has its own address but the page content barely changes, point the variants at the main product. If each variant has distinct content, images and search demand, let each one reference itself. Mixing the two approaches in one shop is the usual source of confused reports.

Syndicated and republished articles

When a partner republishes your article with permission, ask them to add a canonical pointing to your original. That is a cross-domain canonical, and it is a legitimate use of the tag. Google has said it may not always honour it for syndicated news, so the original should also be linked from the copy.

Files that are not HTML

A PDF cannot carry a link element, but the server can send the same hint as a header:

Link: <https://www.example.co.uk/guides/care-guide/>; rel="canonical"

This is useful when a downloadable PDF duplicates an HTML page and you want the HTML version to appear in search.

Checking the canonical properly

The canonical has to be checked in the raw HTML, because that is the version crawlers read first. The element inspector in browser developer tools shows the page after scripts have run, so a tag added or rewritten by JavaScript will look correct there even when the source is wrong.

From the command line

curl -sL https://www.example.co.uk/garden-furniture/oak-bench/ | grep -io '<link[^>]*canonical[^>]*>'

If this prints two lines, you have two canonicals. If it prints nothing, check whether the tag is being added by a script, and check the response headers too:

curl -sI https://www.example.co.uk/brochure.pdf | grep -i '^link'

Where the tag sits

Open View Source and search for canonical. Note the line number, then search for </head> and <body. If the canonical comes after either, it will not count. A common cause is an element that is not allowed in the head, such as an <img> tracking pixel, a <div> printed by a plugin, or text from an unclosed tag. Browsers and parsers that meet such an element close the head at that point, so every tag after it lands in the body, including a canonical that is correctly placed in your template.

Checking the target

Request the canonical address itself. It should return a 200 status with no redirect, carry the same canonical pointing to itself, and not be blocked by a noindex. A canonical that points at a redirect, a 404 or a noindexed page is a signal clash; the canonical conflicts guide goes through clearing those up across redirects and sitemaps.

Search Console

URL Inspection shows two values: the user-declared canonical, which is what your tag says, and the Google-selected canonical, which is what Google decided. When they differ, the Pages report lists the address under "Duplicate, Google chose different canonical than user". That is not always a fault in your tag, but if the declared value is wrong, fix the tag first and then look at the other signals.

Where the canonical comes from on common platforms

Very few sites type canonicals by hand. The tag is written by a template or a plugin, so the fix happens there.

The home page mistake

The most damaging template fault is a canonical hard-coded in a shared header file. Someone adds <link rel="canonical" href="https://www.example.co.uk/"> to fix the home page, forgetting that the same header is used by every page. Search the theme or layout files for the literal string rel="canonical"; there should be exactly one place it is written, and it should use a variable.

Building the value safely

In server code, never echo the requested address straight into the tag. That copies tracking parameters, mixed case and odd paths into the canonical, and on a badly configured server it can let anyone put their own host name into your tag. Use a configured base address and a cleaned path. A simple pattern in PHP:

<?php
$base = 'https://www.example.co.uk';
$path = parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH);
$path = rtrim($path, '/') . '/';
?>
<link rel="canonical" href="<?= htmlspecialchars($base . $path) ?>">

Adjust the slash rule to your own site; the point is that the host and protocol are fixed and the query string is dropped.

Awkward cases

• Canonical set by JavaScript. Google can read a canonical added by script after rendering, but it recommends not using JavaScript to change a canonical that is already in the HTML, because the two versions can disagree. Put the correct value in the server-rendered HTML.
• Language versions. Each language or country version should reference itself. Pointing the French page at the English one tells search engines the French page is a duplicate, which cancels the hreflang annotations. See hreflang and canonical conflicts.
• AMP and print versions. An AMP page should name the regular page as canonical, and the regular page should link to the AMP version with rel="amphtml". Print-friendly copies should point to the normal page.
• Staging copies. A staging site that uses relative canonicals will declare its own staging addresses. That is harmless only if staging is protected by a login. If it is public, absolute production canonicals at least point search engines back to the live site, but protection is the real fix.
• Mixed-case addresses. Some servers treat /Oak-Bench/ and /oak-bench/ as different pages. Choose lower case, redirect the rest, and make the canonical match.
• Encoded characters. Spaces and non-Latin characters in paths should be percent-encoded consistently, so the canonical is character-for-character the same as the address you link to.

The fix, step by step

Keeping canonicals correct

• One owner. Decide which layer prints the canonical, whether theme, plugin or framework, and document that the others must not.
• Test on deploy. A simple check in your build or monitoring that fetches a handful of pages and fails if there is not exactly one canonical, or if it does not start with your production base address, catches most regressions before search engines see them.
• Watch after theme or plugin changes. Theme updates, new SEO plugins and page builders are the usual reason a second tag appears. Re-run the analyzer on your sample pages after any such change.
• Keep the sitemap in step. Sitemaps should list only the addresses your canonicals name. When the two drift apart, the conflicts guide shows how to line up every signal.
• Review exceptions. Once a quarter, look at pages with a canonical pointing elsewhere and confirm each still makes sense. Variants and filters change as the product range does.