Common Canonical Tag Mistakes

Canonicalizing everything to the homepage or page one

A surprisingly common template bug canonicalizes every page in a section — every paginated results page, every filtered listing, sometimes an entire site — back to a single "master" URL such as the homepage or page 1 of a series.

The mistake is treating pages that aren't duplicates as if they were. Page 2 of a paginated archive contains different items than page 1; a filtered product listing shows a different subset than the unfiltered category page. Canonicalizing them all to page 1 tells Google "there is only one page here," and Google may respond by not indexing the deeper pages at all and disregarding links or signals found only on those pages — directly harming discovery of any content linked exclusively from page 2 onward.

Fix: each paginated page should carry a self-referencing canonical — page 2 canonicalizes to page 2, page 3 to page 3 — keeping every paginated page indexable in its own right. The only legitimate exception is canonicalizing to a genuine "view-all" page, if one exists and loads acceptably, since that page actually contains the same items as the paginated set.

Pointing a canonical at a redirect, 404, or noindexed page

Crawl audit tools flag this as a "Non-Indexable Canonical" — a canonical tag whose target isn't a clean, indexable 200 URL. It happens when the declared canonical points to a URL that redirects elsewhere, one that no longer exists (404 or 5xx), or one carrying a noindex directive.

Each variant fails differently. A canonical pointing to a redirect creates a muddled chain Google has to resolve, and it may respond by ignoring the declared canonical and picking its own instead. A canonical pointing to a 404 or server error points at nothing — Google disregards it. A canonical pointing to a noindexed page is directly contradictory, telling Google to both consolidate onto and exclude the same URL. This mistake shows up most often after a site migration, when old canonicals still reference pre-migration URLs that now redirect, or after an HTTPS move, when canonicals still reference the old HTTP versions.

Fix: every canonical target must return a 200 status, be indexable, not be robots-blocked, and not itself be canonicalized or redirected elsewhere — verify the full chain resolves in one hop, directly to a live page.

Outputting multiple conflicting canonical tags

A page can end up with more than one rel=canonical tag when a theme template hardcodes one and an SEO plugin injects a second, when two SEO plugins run at once, or when a canonical declared in the HTML head doesn't match a different one set in the HTTP Link header. Server-rendered markup and JavaScript-injected markup can conflict the same way.

Google's guidance is unambiguous: don't specify different canonicals via different techniques. The widely observed practical consequence is that with multiple conflicting canonical tags, Google is likely to ignore all of them and fall back to choosing its own canonical — meaning the declared preference has no effect at all, and control passes entirely to Google's own selection logic.

Fix: view the raw HTML source (not just the rendered page) to check for duplicate rel=canonical tags, and check the HTTP headers separately, since header-based canonicals are easy to miss in a source view. Disable whichever tool is emitting the redundant tag, so exactly one canonical is declared through exactly one method.

Using relative or inconsistent canonical URLs

Google recommends absolute URLs for the canonical link element specifically because relative paths "can cause problems in the long run" — a relative canonical resolves against whatever host and protocol actually served the page, which becomes a real risk if a staging site, an alternate host, or a non-HTTPS URL is ever crawled.

Inconsistency causes a related but distinct problem: a canonical that uses http:// while the site actually serves https://, a canonical pointing to non-www while the site 301-redirects non-www to www (creating an unnecessary canonical-to-redirect chain), or trailing-slash mismatches where /page and /page/ — technically different URLs — get used inconsistently between the canonical tag, internal links, and the sitemap.

Fix: use absolute URLs everywhere, and standardize on one protocol (HTTPS), one host (www or non-www), and one trailing-slash convention sitewide. Enforce that standard with 301 redirects for any variant, and make sure the canonical tag, sitemap entries, and internal links all reference the exact same URL string, character for character.

Combining a canonical with a noindex tag

Canonical and noindex on the same page send Google two instructions that can't both be honored: canonical says consolidate signals onto a target and index that URL; noindex says drop this page from the index entirely. Gary Illyes has described the outcome plainly — a noindexed page never reaches the serving index, even though Google may still fetch it for purposes like link-graph calculation — and John Mueller's guidance has settled into simply "pick one."

This combination usually isn't intentional. It tends to come from plugins or templates that apply noindex to paginated or faceted URLs that already carry a canonical, or from a developer adding noindex to "fix" duplicate content that a canonical tag was already handling on its own.

Fix: to consolidate a duplicate into one indexed URL, use canonical alone. To keep a page out of the index altogether, use noindex alone and drop any cross-page canonical — a self-referencing canonical alongside noindex is generally harmless, since noindex governs either way. Don't use noindex as a workaround to force a canonical choice.

Canonicalizing across hreflang language versions

On multilingual sites, a common mistake canonicalizes every regional or language variant back to a single "main" version — often English — in the name of consolidating authority. That directly contradicts hreflang markup on the same pages, which is telling Google to index each language version and serve it to the matching audience.

Google's own guidance states the rule plainly: when using hreflang, specify a canonical in the same language as the page itself, or the closest available substitute — never a different language entirely. When the /fr/ version canonicalizes to /en/, Google receives contradictory instructions from the same page and the practical result is that neither signal is reliably honored; the French version may fail to index independently or the wrong-language URL may get served to French searchers.

Fix: every page in a hreflang cluster should self-canonicalize — pointing to itself, never to another language version — while the hreflang annotations, not the canonical tag, handle the relationships between language and regional variants.

Blocking the canonical target in robots.txt or relying on JavaScript-only canonicals

Two related mistakes prevent Google from ever confirming a declared canonical. The first: blocking the canonical's target URL in robots.txt. Google can't crawl a blocked page to verify it's a genuine equivalent, and Google's own guidance says directly not to use robots.txt for canonicalization purposes — a canonical pointing at a page Googlebot isn't allowed to fetch is functionally useless.

The second: writing the canonical tag only via client-side JavaScript rather than in the raw HTML delivered to Googlebot. Because Google has to render the page before it sees a JS-injected canonical, there's a gap — sometimes significant — between when the page is crawled and when the canonical is actually recognized, and any rendering failure or delay means the canonical may never register at all.

Fix: never robots.txt-block a URL you intend to canonicalize to; if a page needs to stay crawlable for canonicalization to work, robots.txt must allow it. And place the canonical link directly in the raw HTML head — or in the HTTP Link header for non-HTML files like PDFs — rather than depending on JavaScript to write it in after the fact.

Frequently Asked Questions