“The canonical tag is not working” can mean several things: the HTML points to the wrong URL, duplicate pages disagree, redirects contradict the preferred version, the sitemap contains a different signal, or Google selects another representative URL because it considers it more complete or useful. A canonical hint is a signal, not a command.
Google’s canonicalization documentation describes canonicalization as selecting a representative URL from duplicate or similar content. Its canonical specification guide lists redirects, rel="canonical", and sitemap inclusion as signals with different strength. Start by defining the conflict you actually observed.
Define the expected canonical set
List the URLs that represent the same or substantially similar content: protocol variants, host variants, parameters, sorting pages, print versions, regional versions, and accidental duplicates. Choose a preferred URL based on user value, accessibility, content completeness, and business ownership.
Do not canonicalize pages that are meaningfully different merely because they share a topic. A canonical is not a way to erase legitimate local, language, product, or audience differences.
Capture the signals separately
For each URL record:
- final response URL and status;
- redirect chain;
- HTML
rel="canonical"; - HTTP header canonical, when relevant;
- sitemap inclusion;
- internal-link targets;
- hreflang or regional relationship;
- indexability directives;
- Google-selected canonical observation.
Store fetch date, device or rendering condition, and the tool used. A browser address bar alone is not evidence of the canonical signal.
Check self-referential and cross-page logic
An indexable preferred page commonly points to itself, while duplicate variants point to the preferred URL. Look for accidental loops, relative URL errors, mixed protocol, host mismatch, staging domains, and templates that emit the same canonical on every page.
Compare the canonical with the page’s actual content. A page that says one thing but points to a substantially different URL creates a weak signal and a poor user path.
Inspect redirects before tags
Redirects are a stronger consolidation signal than a tag. Confirm that legacy URLs resolve to the intended destination, do not chain unnecessarily, and do not redirect users to a page with a different job. If a redirect target is unavailable or unserviceable, repair the destination before changing metadata.
Do not use a redirect to hide a page that should remain independently useful. Choose consolidation only after reviewing intent and user expectations.
Check internal links and sitemaps
Internal links should consistently point to the preferred URL unless there is a deliberate reason to expose a variant. Google’s crawlable-link guidance explains why standard links help discovery and interpretation.
A sitemap can reinforce a preference, but it cannot repair a broken page architecture. Remove obsolete or parameterized URLs from the sitemap after confirming that users and systems no longer need them.
Compare content similarity and completeness
Canonical disagreements can be a symptom of near-duplicate pages with weak differentiation. Compare opening answer, main evidence, entity, service scope, internal links, and practical artifact. If the preferred page is thinner or less useful than the alternate, improve the page or consolidate intentionally rather than repeating the tag.
Mark whether the conflict is technical, editorial, architectural, or expected. Google may choose a different URL even when implementation is syntactically valid.
Test in a controlled order
Repair one signal family at a time: destination and redirects, canonical markup, internal links, sitemap, then content differentiation. Record before state, change, owner, expected effect, and recheck date. Do not change all layers simultaneously if you need to learn which signal was broken.
Recheck after crawling and processing time. A same-day absence of change does not prove that the repair failed.
For high-risk templates, test several representative URL types: preferred page, duplicate variant, parameter URL, redirected legacy page, and a page with regional or language relations. A fix that works on one example may be wrong for an entire template family.
Keep the raw fetches and rendered output with the diagnostic record. This makes a future regression distinguishable from a different crawler or processing state.
Check templates in source control and in the public response. A correct template can be overridden by a plugin, edge cache, translation layer, or CMS field. Record the active version and invalidate caches only through an approved, reversible change.
If the preferred URL is not accessible, complete, or serviceable, stop trying to reinforce it and choose a better representative. Canonical repair cannot compensate for a weak destination.
Log the chosen representative and the reason in the URL registry so future editors do not re-open the same conflict without new evidence.
If different templates emit different canonical logic, split the diagnosis by template and owner. A single global rule can conceal a local regression.
Keep the repair note attached to the release or migration record so the same conflict is not reintroduced later.
Include the final URL.
Record the template version too.
Document verdicts
Implementation break: markup, URL, redirect, or template is wrong.
Signal conflict: tags, redirects, links, or sitemap disagree.
Content overlap: pages are too similar or the preferred page is not the best answer.
Expected selection: signals are valid, but Google chose another representative URL.
Insufficient evidence: observation method or processing window cannot support a conclusion.
The Canonical Diagnostic Sheet is complete when it lists the duplicate set, preferred rationale, every signal, content comparison, repair owner, change order, and recheck date. The objective is not to force a URL choice; it is to make the site’s preferred representation coherent and useful.
How did this article land?
Choose one reaction. You can change it anytime.
