Canonical: 5 Mistakes That Break SEO on Large Sites
The rel=canonical tag looks simple, but it is responsible for some of the most painful indexation disasters. We break down 5 common mistakes and how to detect and fix them.
The <link rel="canonical"> tag looks, at first glance, like one of the simplest SEO tools: you tell the search engine which page is the "real" one, and it stops creating duplicates in the index. In practice, it is responsible for some of the most painful indexation disasters. On large sites — e-commerce platforms, aggregators, news portals — a single misconfigured canonical setting can remove 60% of pages from the index within a week.
This article covers the five most common canonical mistakes, the real-world scenarios in which they occur, and how to detect each one.
What Canonical Actually Does
First, the fundamentals — briefly, because the important part comes next.
<link rel="canonical" href="..." /> in the <head> of a page tells search engines: "this page is a copy of the page at the given URL. Keep the original in the index, and attribute all ranking signals to the original." This is a strong hint, not a directive — search engines can ignore it if they are confident you are wrong, but in 95% of cases they follow the instruction.
Goals:
- Consolidate the "weight" of duplicates onto a single page (avoid splitting the link profile)
- Prevent multiple similar pages from appearing in search results for the same query
- Control exactly which URL gets indexed (with or without www, with or without a trailing slash, with or without UTM parameters)
Mistake 1: Self-Referencing the Homepage from Every Page
The most common "side effect" of low-quality development. The homepage template contains <link rel="canonical" href="/" />, and that same template is used across all other pages of the site.
What happens: Every page on the site tells the search engine "I am a duplicate of the homepage." The search engine tries to comply — and gradually deindexes everything except the homepage.
Symptoms:
- A sharp drop in the number of indexed pages in Google Search Console and Yandex Webmaster
- Internal pages disappear from search results for their own queries
- The homepage starts "absorbing" all traffic but cannot handle the diverse range of search intent
How to detect: In Search Console → Coverage report → "Page excluded due to chosen canonical URL." If there are hundreds or thousands of rows all pointing to the homepage — that is the issue.
How to fix: The template must generate the canonical dynamically: <link rel="canonical" href="${currentURL}" /> for each individual page. In Next.js this is done via alternates: { canonical: '/some-path/' } in metadata; in WordPress, this is the default behavior of Yoast and RankMath.
Mistake 2: Canonical Chains
Page A has a canonical pointing to page B. Page B has a canonical pointing to page C. Page C has a canonical pointing to page D. This is a canonical chain three steps deep.
What happens: Search engines typically follow a chain up to 3 steps and then give up, treating the setup as broken. Often, ranking signals never reach the final destination page at all.
Where it comes from: Usually site structure migrations. When URLs have been changed multiple times and each revision left its own canonical behind. Or a CMS generating canonicals based on outdated rules.
How to detect: Screaming Frog → Canonical Chains report. Or manually: crawl all pages with a script, parse the canonical values, and search for chains longer than one step.
How to fix: All canonicals must point directly to the final URL, with no intermediaries. If page A is meant to consolidate with page D, then page A should contain <link rel="canonical" href="URL of D" /> — do not route through B and C.
Mistake 3: Canonical Pointing to a Page That Returns 404 or a Redirect
A page is live and functional. Its canonical, however, points to a URL that no longer exists or that itself redirects.
What happens: The search engine attempts to follow the canonical and receives a 404 or a 30x response. In the best case, it ignores the canonical and indexes the current page. In the worst case, it deindexes the current page (because its canonical target is unavailable) and does not index the target page (because it is inaccessible).
Where it comes from: Most commonly — a page was removed from the catalog without updating all variants that had a canonical pointing to the deleted URL.
How to detect: Crawl all pages and check the HTTP status of every canonical target. Any canonical pointing to a non-200 response is a potential problem.
How to fix: Either restore the target page, or update the canonical to point to a valid live URL.
Mistake 4: Conflict Between Canonical and Noindex
A page has <meta name="robots" content="noindex"> and simultaneously <link rel="canonical" href="/other-page/" />.
What happens: This sends a contradictory signal. On one hand you are saying "do not index this page," on the other — "index /other-page/ instead of this one." Google and Yandex resolve this conflict differently, and often noindex wins, but in the process the canonical signal pointing to /other-page/ is lost as well.
Where it comes from: A combination of different configuration systems. For example, the canonical is set in the template, while noindex is applied via a CMS plugin for specific page types (filters, pagination pages, tags).
How to detect: A crawl tool that simultaneously collects canonical values and meta robots directives. Any page carrying both signals at the same time is a potential problem.
How to fix: If a page should be hidden from the index — keep only noindex and remove the canonical (it becomes meaningless). If a page should consolidate signals with another — remove noindex and keep the canonical. Do not use both simultaneously.
Mistake 5: Canonical Breaking Pagination
A site with a large catalog or blog uses pagination: /blog/, /blog/page/2/, /blog/page/3/. Every paginated page carries a canonical pointing to the first page: <link rel="canonical" href="/blog/" />.
What happens: Before 2019, Google recommended using rel="next" and rel="prev" for pagination. It then dropped that recommendation. Many SEO specialists subsequently added a canonical from paginated pages to the first page "just to be safe," assuming this was harmless.
In practice, this leads to the deindexation of all paginated pages and everything that exists only on deeper pages — because Google now treats them all as duplicates of page one. If you have 200 articles paginated at 10 per page, articles 11 through 200 can lose their search visibility entirely.
How to detect: Search Console → check the indexation status of the 5th, 10th, and 20th pagination pages. If they are excluded with the label "alternate page with proper canonical tag" — there is a problem.
How to fix: Each paginated page must have a self-referencing canonical — that is, a canonical pointing to itself:
/blog/→<link rel="canonical" href="https://site.com/blog/" />/blog/page/2/→<link rel="canonical" href="https://site.com/blog/page/2/" />/blog/page/3/→<link rel="canonical" href="https://site.com/blog/page/3/" />
The search engine will figure out the structure on its own.
Bonus: Common Minor Mistakes
In addition to the five major mistakes — a few smaller but frequent issues:
Canonical with a relative URL: <link rel="canonical" href="/page/" /> instead of <link rel="canonical" href="https://site.com/page/" />. Technically it works, but using an absolute URL is recommended — it leaves less room for misinterpretation.
Canonical with a different protocol than the current page: The page is served over HTTPS, but the canonical points to the HTTP version. This creates an unnecessary redirect loop for the search engine crawler.
Canonical pointing to a different domain without a clear reason: If a page on site1.com has a canonical pointing to site2.com, search engines will have questions. Cross-domain canonicals are a valid technique, but they require a solid technical justification.
Canonical containing UTM parameters: Never include ?utm_source=... in a canonical. This tells search engines to "index the version with UTM parameters," which results in thousands of duplicate URLs being indexed.
Dynamic canonical that depends on the user's state: If the canonical changes based on cookie or session state — that is a bug. The canonical must be stable and unambiguous for each URL.
Audit Tools
For regular canonical checks on your site:
- Screaming Frog SEO Spider (desktop, $200/year) — a powerful crawler with detailed canonical analysis, chain detection, and conflict reporting
- Sitebulb (desktop, $150/month) — visual diagrams of canonical structure
- Ahrefs Site Audit (online, $99+/month) — cloud crawl with integration of additional data sources
- DIY crawl — Python + Beautiful Soup + a URL list from your sitemap, ~100 lines of code
Recommended audit frequency: quarterly for stable sites, monthly for sites undergoing active change.
Summary
Canonical is a high-impact tool with a high cost of error. On a small site (under 100 pages), problems surface quickly and are easy to fix. On a large site (10,000+ pages), a single templating mistake can sit undetected for months, quietly destroying indexation.
If you cannot remember the last time you ran a full canonical audit on your site — it is probably time. We can handle it ourselves — get in touch, and we will come back with a report within 2 business days.