The redesign shipped. Traffic looks uneven. Search Console whispers about duplicates. Someone asks, "Did we set canonicals?" and the room goes quiet.
A canonical URL tells search engines which version of a page you prefer when multiple URLs could show the same or similar content. After a site update, canonical mistakes are common: missing tags, pointing to the wrong domain, HTTP vs HTTPS splits, or CMS plugins fighting your dev team's template.
You do not need to read HTML all day. You do need five checks that catch most post-update duplicate issues before they linger for months.
We support technical SEO for site updates when marketing and dev need a shared verification list. Use this after launches, CMS migrations, or template rollouts.
In the page <head>, a line like:
<link rel="canonical" href="https://example.com/services/web-development" />signals: index and attribute signals to this URL, not alternate versions (when Google respects the hint).
Canonicals are hints, not commands. Google may choose differently if internal links, sitemaps, and redirects contradict the tag. That is why verification is a bundle, not one checkbox.
After an update, confirm:
href values use that same hostFailure pattern: canonicals say https://www.example.com/... but marketing links and sitemap use https://example.com/.... Split signals, messy coverage.
Owner: dev / hosting. Time: one sprint item, high impact.
Every page you want indexed should canonicalize to itself (its clean final URL), unless it is intentionally an alternate (see Check 4).
Spot-check templates:
Failure pattern: canonical missing entirely, or defaulting to homepage on every URL (some CMS misconfigs do this).
Use View Source or URL Inspection in Search Console. Fix at template level, not page-by-page forever.
E-commerce and CMS sites generate extras:
?page=2, ?sort=priceDecide policy:
Failure pattern: hundreds of parameter URLs indexed with duplicate titles. Fix robots, canonicals, or faceted navigation settings together.
Some duplicates are deliberate:
Confirm canonical points to the original on your domain you want in search results.
Failure pattern: syndicated copy on a partner site without canonical to your hub article, or two full copies both claiming index rights.
Canonicals fail in isolation. After an update, triangulate:
|
Signal |
Should agree on preferred URL |
|---|---|
|
Canonical tag |
Yes |
|
301 redirect target (if URL moved) |
Yes |
|
Internal links from nav and body |
Yes |
|
Sitemap entries |
Yes |
|
Google-selected canonical (Search Console) |
Ideally yes |
If redirects say /new-url but canonicals still say /old-url, Google gets mixed messages. Pick the post-update URL everywhere.
Old paths still reachable without redirect, new paths live, canonicals only on new theme. Fix: redirect map + template canonicals same release.
/services/seo and /services/seo/ both 200. Fix: redirect one to the other; canonical matches.
Staging canonical still points at staging.example.com. Fix: find-replace in DB or template before launch checklist.
Thin archives compete with service pages. Fix: noindex or canonical to parent hub, depending on strategy.
If Google-selected canonical differs from user-declared on important URLs, escalate. That is not a "wait and see" item four weeks post-launch.
When URLs change, redirects carry users and most signals. Canonicals on the new URL should self-reference.
Do not rely on canonical alone to replace 301s from old URLs. Use both in their roles:
Full redesign transitions belong in a broader website redesign and SEO transition plan with redirect maps and coverage monitoring.
After any site update, verify host consistency, self-referencing canonicals on key templates, parameter policy, and alignment with redirects and sitemaps. Fix template-level bugs before rewriting blog posts.
Which check caught an issue on your last launch: HTTPS split, missing canonical, or redirect map gaps?