To find canonical errors, compare the declared URL, the destination’s content and Google’s selected canonical where reported. Canonical is a preference signal for similar content; it neither redirects visitors nor guarantees the selection. One tag is not enough: its destination must be relevant, accessible and consistent with other site signals.
Define the problem the canonical should address
Google documents canonicalisation methods for identifying a preferred URL among similar or duplicate content. A canonical is not a redirect and does not automatically move a visitor. Google's chosen version may differ from the declared preference.
Make that distinction clear within the team. A permanently moved address raises a redirect question, which is different from content available at multiple URLs. Consolidating distinct products or services is also an editorial decision that cannot be completed simply by changing a tag.
Sample templates and URL groups
Sample products, categories, articles, language versions and parameter URLs. Record the source URL, declared canonical, target HTTP response and expected equivalent content. If a product points to its category, examine whether that conflicts with a distinct product search task; do not canonicalise everything to the homepage.
Compare initial HTML with the DOM after JavaScript runs. Check whether the CMS and SEO plugin produce different tags, or a copied page retained an old canonical field. If the error affects the template, fix the shared output rather than editing URLs individually.
Verify the target's state and meaning
Open the target directly and check for redirects, errors, noindex or content in another language. Prefer the final intended URL instead of the first hop in a redirect chain. Produce one consistent HTML canonical in a valid head section; an absolute HTTPS URL reduces maintenance ambiguity.
Compare the reported Google selection with the site’s preference in URL Inspection. If they differ, examine actual content equivalence, internal links and sitemap entries. Language editions should use an appropriate canonical in their own language, with hreflang handled separately. Changing a canonical alone does not perform a permanent move for visitors.
| Finding | Question | Why it matters |
|---|---|---|
| Unrelated target | Is the content actually equivalent? | The page relationship is misrepresented. |
| Unavailable target | Can the preferred address be used? | The destination is invalid. |
| One target across a template | Were independent page purposes reviewed? | Many URLs may be affected. |
| Different source and final HTML | Which layer changes the declaration? | Implementation is inconsistent. |
| Language pages share one target | Are these translations or different content? | Language and page relationships need review. |
Align the correction with related page signals
Once the preferred address is agreed, check internal links, sitemap entries and related page connections against the same decision. If one team links a new address while another layer declares an old target, the investigation will recur. Record the source of the change and the expected result.
Do not consolidate every page that looks similar during the audit. A separate product or service decision may justify its own content. Make that difference clear on the page. Technical signals should consistently represent the editorial decision, not replace it.
Verify implementation before tracking later processing
Check that corrected examples produce the intended target. Track Google's subsequent evaluation separately; a changed tag does not mean the chosen canonical changes immediately.
Add target verification to new-page and migration checks. The question should be whether the destination is correct and meaningful, not merely whether a tag exists.