Review canonicals through page purpose, destination validity and consistent technical signals. Use a diagnostic table to prioritise incorrect targets.
The presence of a canonical does not establish that its target is correct. A product might point to an unrelated category, new content might retain an old address, or an entire language section might share one target. Start with which page should represent the content, then check whether the implementation reflects that decision.
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
Review products, categories, articles, filters and language versions separately. Record the intended target and current declaration for each example. If one template creates the same error across a group, the correction may belong at the source instead of in individual pages.
Imagine a new page created from an older page's copy while retaining its canonical field. The content now differs, but the technical signal still points backwards. In this hypothetical case, establish the new page's independent purpose, then correct the creation template or editorial check.
Verify the target's state and meaning
Open the destination and check whether it represents the intended content. Review whether the declaration changes between source and final HTML. When Google's preference differs from the site's, use its canonicalisation troubleshooting guidance to investigate technical and content issues.
| 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.