How to diagnose and fix canonical errors
To fix a canonical problem, first identify the page you want indexed, then compare its declared canonical, redirects, index eligibility and duplicate content with Google's selected URL in Search Console. A different Google-selected canonical can be intentional deduplication. A tag check alone cannot prove an indexing error. Google's canonical guidance explains which signals express your preference.
Start with the free canonical declaration checker. It reads the fetched page's declarations. Target status and Google's selected canonical need separate checks.
What is a canonical error?
A canonical implementation error means your site declares a preference you did not intend, provides conflicting preferences, or places a declaration where Google cannot use it. Examples include a product page pointing at the homepage, two different canonical URLs in the same head, and a preferred target that has been removed.
Google can select a canonical without a tag. Missing a self-reference does not by itself prove lost traffic. Relative canonical URLs are supported; Google recommends absolute URLs to reduce resolution mistakes. An intentional cross-domain canonical can also be valid when the pages are duplicates.
Start with the Search Console reason
Inspect the affected URL in Search Console and save the inspection date, last crawl date, user-declared canonical and Google-selected canonical. Compare the indexed result with the current live page. The indexed result can describe a crawl that happened before your latest change.
| Observed state | What to check next |
|---|---|
| Alternate page with proper canonical tag | If this is an intended duplicate and the preferred page is indexed, no canonical repair may be needed. |
| Duplicate, Google chose different canonical than user | Compare both pages' content, declarations, redirects and internal links. This result does not identify the cause by itself. |
| Duplicate without user-selected canonical | Decide whether the pages should be duplicates. State a consistent preference if they should; improve meaningful differences if they should not. |
| Discovered or crawled, currently not indexed | Investigate discovery, crawl access, content value and indexing separately. This label does not prove a canonical tag defect. |
| Excluded by noindex, blocked or not found | Resolve the intended page's access or index eligibility before attributing its absence to canonical selection. |
Separate the declaration from its target
Read the HTML head and any HTTP Link header. Resolve relative targets against the fetched document URL, accounting for a valid base element. Record all declarations rather than stopping at the first. Conflicting targets need review; do not assume which one Google used.
Then fetch the preferred target separately. Check its final URL, response status, robots access, noindex state and content. A redirecting target may signal an outdated preference. A 404 target needs correction if it was supposed to remain the preferred page. A 200 response alone does not establish indexing or content equivalence.
A dated response receipt you can reproduce
On 19 September 2026 at 20:51 UTC, an ordinary GET of this guide returned HTTP 200, a self-canonical declaration and an index/follow meta directive. That response establishes the page’s declaration at that time. It does not establish Google’s selected canonical.
curl -sS -L -D canonical-headers.txt -o canonical-page.html 'https://auditlamp.com/learn/fix/fix-canonical-errors'
Record the response time and inspect every canonical declaration in the saved HTML and headers. Then save Google’s selected canonical, indexed state and last crawl date from your own verified Search Console property. Keep those two receipts distinct. URL Inspection reference.
A worked repair: tracking duplicate versus distinct page
This is an illustrative example, not a measured customer result. Suppose /blue-widgets?utm_source=newsletter shows the same product collection as /blue-widgets. If the clean URL is the preferred indexable page, both can declare:
<link rel="canonical" href="https://example.com/blue-widgets" />
Check that navigation and the sitemap use the preferred URL. If an old address is permanently retired, use an appropriate permanent redirect to its replacement. Keep the tracking URL available when it is needed for the campaign; a canonical declaration is a preference for duplicate consolidation.
Now suppose /red-widgets lists different products. Do not point it at the blue collection just because the two pages share a template. Preserve a separate canonical when this is a distinct page you want indexed. The same caution applies to pagination, filters, language versions and regional pages: decide what content is equivalent before changing their canonical relationship.
For a CMS, fix the template or canonical field that produced the wrong target. Sample a homepage, product, collection and article after the change. A hard-coded homepage URL in a shared template can affect many routes at once. Keep a copy of the old setting so you can reverse an incorrect change.
What a clean tag can and cannot establish
Redirects and canonical annotations are strong canonical signals; sitemap inclusion is a weaker signal. Consistent internal linking also helps communicate the preferred address. Google still chooses the canonical. Matching declarations cannot guarantee indexing, ranking, citations or traffic.
Do not use robots.txt to select a canonical. Blocking crawling can prevent Google from seeing a declaration. Do not use noindex simply to force Google to choose a different duplicate. Review removal and canonical preference as separate decisions in Google's consolidation documentation.
A repair handoff you can verify
Give the person editing the site a specific URL and intended outcome. Record the current declaration, preferred target, conflicting source, exact template or field to change, and a rollback. Avoid a task that says only "fix canonicals".
- Save the affected URL and the current fetched declaration as your baseline.
- Check the preferred target independently, including its status and index eligibility.
- Change the responsible template or field and align relevant links, redirects and sitemap entries.
- Re-fetch representative pages and compare the new declarations with the baseline.
- After Google recrawls, inspect the indexed result again and record its selected canonical.
The canonical checker can save a declaration baseline in your browser. The redirect checker helps trace a URL's redirects. Neither result substitutes for Search Console's indexed-page evidence.
When is the fix finished?
There are two separate milestones. The implementation is corrected when the fetched page expresses the intended preference and the target checks pass. Google's observed selection is confirmed only when a later indexed URL inspection reports the expected canonical. Note the inspection and crawl dates with both observations.
Recrawling and reprocessing can take time. There is no guaranteed next-crawl resolution or two-week deadline. A live test cannot predict which canonical Google will select. If the selection still differs after a new crawl, compare the competing pages and signals again. If the canonical matches but traffic remains low, examine query demand, search position, impressions and clicks; stop changing a working tag to chase an unrelated ranking problem.
For related checks, see accidental noindex, sitemap errors and duplicate content. Run a full visibility scan to organize technical findings and verification steps across the site.