How to Diagnose Canonical and Redirect Conflicts After a Website Migration
Canonical and redirect conflicts are among the most damaging problems that appear after a website migration, and among the least visible. Pages load normally for visitors, so nobody notices. Meanwhile, search engines receive mixed signals: a redirect says “this page moved here”, while the canonical on the new page says “the real version is somewhere else”. The result can be dropped rankings, the wrong URLs in search results and lost citations in AI answers. This is a migration-focused diagnostic, not a general SEO audit. It covers how to find these conflicts, what each pattern means and how to fix it.
Why Migrations Create Conflicts
During a migration, several systems change at once: URL structure, CMS, templates, server configuration, CDN rules and sometimes domains or protocols. Redirects are often managed by developers in server or CDN rules, while canonicals come from CMS templates or SEO plugins. When these two systems are configured separately, they can disagree. Common triggers include:
- Canonical tags still pointing to old URLs copied from the previous CMS
- Templates generating canonicals from a hard-coded staging or old domain
- Redirect rules sending users to a page whose canonical points elsewhere
- Trailing slash, uppercase or www rules applied in redirects but not in canonicals
- HTTP to HTTPS redirects missing on some paths
Common Canonical and Redirect Conflicts
| Pattern | What happens | Typical result |
|---|---|---|
| Canonical to a redirecting URL | New page canonicalises to an old URL that redirects back | Signals loop, Google may choose its own canonical |
| Redirect chain | Old URL → interim URL → final URL | Slower crawling and diluted signals |
| Redirect loop | A → B → A | Page unreachable |
| Canonical to a 404 | Canonical points to a URL that no longer exists | Canonical ignored, possible deindexing confusion |
| Canonical to a non-equivalent page | Product page canonicalises to category | Product page dropped from index |
| Mixed protocol or host | Canonical uses http or non-www, redirect uses https and www | Duplicate versions indexed |
Step 1: Gather the URL Lists
You need three lists:
- Old URLs: from the pre-migration crawl, sitemap, analytics landing pages, Search Console top pages and backlink exports.
- Redirect map: the intended old-to-new mapping agreed before launch.
- New URLs: from a fresh crawl of the live site and the new XML sitemaps.
If you did not crawl before migrating, rebuild the old list from Search Console, analytics and archived sitemaps.
Step 2: Crawl Old URLs and Follow Redirects
Crawl the old URL list in list mode with redirect following enabled. For each URL, record the full redirect path, final status code and final URL. Flag:
- Chains with more than one hop
- Loops
- Final status codes other than 200
- Redirects to the homepage or a generic category instead of an equivalent page
- Temporary redirects (302 or 307) where permanent ones (301 or 308) were intended
Compare final URLs with your redirect map. Any mismatch is either a configuration error or an undocumented decision that needs review.
Step 3: Audit Canonicals on the Destination Pages
Crawl the new site and extract the canonical tag and any canonical HTTP header for every page. Then check:
- Does each page’s canonical point to itself, or to a deliberate equivalent?
- Does any canonical point to an old URL, a redirecting URL or a non-200 URL?
- Do canonicals use the same protocol, host, case and trailing slash as the live URL?
- Is the canonical in the raw HTML, not only added by JavaScript?
- Are there multiple canonical tags on one page?
Join this data with the redirect crawl. The dangerous cases are where the redirect target and the canonical disagree.
Step 4: Check How Search Engines Interpreted the Signals
In Google Search Console, use URL Inspection on a sample of affected pages and compare “User-declared canonical” with “Google-selected canonical”. When they differ, Google has decided your signals are unreliable. Review the Page indexing report for “Duplicate, Google chose different canonical than user” and “Page with redirect”. Rising counts after launch point directly at canonical and redirect conflicts.
Watch for Signals in Other Places
Canonical intent is also expressed through hreflang annotations, pagination links, Open Graph URLs and sitemaps. After a migration, any of these may still reference old URLs. Search engines combine all of these signals, so a perfect canonical tag can still be overruled if hreflang and sitemaps disagree with it. Extract them in the same crawl and check that every reference points to a final, indexable URL.
Step 5: Fix in the Right Order
- Remove redirect loops first, because they make pages unreachable.
- Collapse redirect chains so every old URL points directly to its final destination.
- Update canonicals to self-reference the final live URL, using the same format as your redirects.
- Update internal links to point straight to final URLs, so crawlers do not need redirects at all.
- Update XML sitemaps to list only final, canonical, 200-status URLs.
- Request recrawling of key pages and monitor the indexing reports.
Fixing internal links is often overlooked, yet it is one of the strongest consistency signals you can send. If the migration also changed navigation or templates, review whether important pages lost links entirely, and use a data-driven SEO strategy to decide which pages deserve the strongest internal support.
Document Every Decision
Keep the redirect map, the canonical rules and the list of fixes in one shared document. Future developers will otherwise repeat the same mistakes during the next redesign. Strong on-page SEO optimization keeps these signals aligned.
Why This Matters for AI Search
AI search systems that rely on search indexes inherit these problems. If Google or Bing selects the wrong canonical, AI answers may cite an outdated URL, a redirecting page or a competitor’s duplicate content. Pages that previously earned citations can disappear from answers after migration. Our AI traffic drop recovery service often begins by fixing exactly these conflicts.
Frequently Asked Questions
How Long Should Redirects Stay in Place After a Migration?
Keep them for at least a year, and permanently for URLs with backlinks or ongoing traffic.
Can a Canonical Replace a Redirect?
No. A canonical is a hint for duplicate content. When a page has moved, use a permanent redirect.
How Soon Will Rankings Recover After Fixes?
Small fixes can show results within weeks. Large sites may take several months for search engines to reprocess all URLs.
Diagnosing canonical and redirect conflicts early protects the value you built before migration. If you are planning or recovering from a migration, book a technical SEO audit, explore our international SEO services for multi-domain moves, read our AI indexing case study, review website maintenance services, see our SEO services, learn how to fix AI search visibility, or understand why your website is not ranking in AI search.