Canonical tags matter after a website migration in a specific, unglamorous way: they are the tie-breakers that tell search engines which version of each new page is the real one, and a migration is precisely the moment when versions multiply, http and https, www and bare domain, trailing slashes, parameters, staging leftovers, near-duplicate pages consolidated from the old site. Canonicals do not replace redirects, a live page pointing elsewhere is a suggestion while a 301 is an instruction, but a migration that ships wrong or missing canonicals splits its ranking signals across duplicates at exactly the moment those signals are being re-evaluated. The correct state is boringly simple, every new page self-canonical at its final URL, every consolidation expressed as a redirect rather than a canonical hint, and it is part of the metadata parity that a crawl-first rebuild like WPBuildAI’s carries by construction: the pre-migration scan records the old canonicals, and the build emits the correct new ones on every page.
What canonicals do, and what migrations do to them
A canonical tag is the page’s own statement of its preferred address, which search engines use as a strong hint when consolidating duplicate URLs: among several versions serving the same content, the canonical nominates the one that should hold the rankings and receive the signals. In steady state most sites barely think about this, the CMS emits self-referencing canonicals and life goes on. A migration destabilizes it from three directions at once: the URL space changes, so every canonical that referenced an old address is suddenly nominating a page that no longer exists; the duplicate surface expands, since new platforms introduce their own parameter, pagination, and protocol variants; and the consolidation decisions, which old pages merge into which new ones, need expressing in the language engines respect, which is redirects for gone pages and canonicals for living variants.
The failure modes are correspondingly specific: new pages still canonicalizing to old URLs, an entire template canonicalizing to the homepage after a theme misconfiguration, staging or preview domains getting indexed because nothing claimed the production URL, and consolidated near-duplicates left live with cross-canonicals where a redirect was the honest signal. Every one of these splits or misdirects equity during the weeks engines are re-mapping the site, which is the costliest possible timing.
Canonicals versus redirects: the division of labor
| Situation after migration | Right tool | Why | Verdict |
|---|---|---|---|
| Old URL replaced by new URL | 301 redirect | The old page is gone; instruction, not hint | Never canonical alone |
| Same page at protocol/www/slash variants | Redirect to one form, self-canonical on it | One address serves, others forward | Belt and braces |
| Parameter and tracking variants of a live page | Self-canonical on the clean URL | Variants must serve, engines consolidate | The canonical’s home turf |
| Two old pages merged into one new page | 301 both to the survivor | Consolidation is a redirect decision | Canonicals cannot merge gone pages |
| Staging or preview domains | Block indexing entirely | Nothing there should compete | Canonical is not access control |
The table’s pattern is the principle: redirects instruct, canonicals suggest, so anything that should stop existing gets a redirect, and anything that must keep serving in multiple forms gets a canonical electing one form. Migrations go wrong when the two swap jobs, canonicals doing the work of redirects on dead URLs, or redirect chains stacked where a self-canonical would have quietly settled a variant.
The migration canonical checklist, stage by stage
Before the move, record the current state: the crawl that inventories the old site captures each page’s canonical alongside its title and meta description, which preserves the consolidation decisions someone already made, the paginated series canonicalizing to page one, the tracking-parameter cleanups, the near-duplicates already pointing at a preferred version. This record is part of what the crawl-first method means by metadata parity: the new site should reproduce not just the content but the relationships.
During the build, enforce the two defaults: every page self-canonical at its final production URL, absolute, protocol-correct, in the form the site actually serves; and canonicals emitted server-side in the initial HTML, since a canonical injected by JavaScript is invisible to the crawlers that skip rendering. Map the recorded old-state decisions onto the new structure deliberately, consolidations become redirect rows, variant preferences become the new self-canonicals, rather than trusting a new platform’s defaults to rediscover them.
At launch, verify as mechanically as redirects get verified: crawl the new site and grade every page on three conditions, a canonical present, pointing at itself in the final URL form, and consistent with the sitemap, because a sitemap listing one URL form while pages canonicalize to another sends engines contradictory nominations. Then the specific hunts: any canonical still containing the old domain, any template-wide canonical pointing at one URL, and the staging domain checked for accidental indexability.
The weeks after: reading the consolidation
Post-launch, canonicals are monitored through the same lens as the rest of the migration, in Search Console, where the page-indexing report speaks canonical fluently: “Duplicate without user-selected canonical” flags pages where engines chose for you, “Duplicate, Google chose different canonical than user” flags disagreements worth reading closely, and the URL inspection tool shows, per page, which canonical Google actually selected versus the one you declared. Disagreements in the first weeks are usually the old URLs still winning while signals transfer, which resolves as redirects get processed; disagreements that persist past the settling period point at real problems, most often a declared canonical contradicted by internal links and sitemaps still referencing another form. The fix is alignment: links, sitemap, and canonical all nominating the same URL, which is the consistency the site-move process is designed to ship on day one.
One honest calibration: canonicals are a small share of migration outcomes compared to redirect coverage and content parity, and a site with perfect 301s and sloppy canonicals will mostly settle fine, slowly. The reason to get them right anyway is that the cost is near zero at build time, a template decision, and distinctly nonzero later, when a quarter of split signals and a Search Console full of duplicate warnings has to be diagnosed page by page. Cheap at construction, expensive as archaeology is the general shape of migration metadata, and canonicals are its cleanest example.
The e-commerce multiplier
One site category deserves its own paragraph, because it is where canonical stakes stop being marginal: online stores. Faceted navigation, size and color parameters, sort orders, and session identifiers can spin a two-hundred-product catalog into tens of thousands of crawlable URL variants, and a migration re-rolls all of them at once, new parameter conventions, new pagination, new filter URLs. Without deliberate canonical policy, the crawl budget scatters across variants, thin duplicates compete with category pages, and the product URLs that earn revenue dilute their own signals; with it, every variant nominates its clean parent, engines spend their attention on the pages that convert, and the product-page rankings that pay the bills transfer intact. Store migrations are also where the sitemap-canonical-link alignment gets tested hardest, because platforms generate all three from different subsystems, and where the verification crawl earns its keep most visibly: on catalogs, the duplicate surface is the majority of the site.
Where this fits in the platform story
Canonical hygiene is one more line in the argument that migrations are architecture projects rather than content moves. On a plugin-assembled WordPress site, canonicals are typically owned by an SEO plugin, occasionally fought over by two, and vulnerable to every theme and plugin update; the audits that find schema conflicts find canonical conflicts in the same pass, two plugins nominating different URL forms on the same page. On a generated static build, the canonical is a template line computed from the page’s own address, it cannot drift from the URL it lives on, cannot be contradicted by a second emitter, and ships in the initial HTML where every crawler generation, JavaScript-skipping AI fetchers included, reads it. That by-construction correctness is the quiet pattern across the whole metadata layer, canonicals, schema, titles, sitemaps, and it is why the WPBuildAI rebuild treats parity as a build output rather than a checklist item: the same inventory that drives the redirect map drives the canonical emission, and the launch verification confirms both with the same crawl.
Key takeaways: canonical tags after a migration
Canonicals matter as tie-breakers at the exact moment versions multiply: the correct post-migration state is every page self-canonical at its final URL, server-rendered, consistent with sitemap and internal links, with consolidations expressed as 301s rather than canonical hints, because redirects instruct and canonicals only suggest. Record the old site’s canonical decisions in the pre-migration crawl, reproduce the relationships in the build, verify mechanically at launch, and read Search Console’s duplicate reports through the settling weeks, chasing only the disagreements that persist. Keep the calibration honest, redirect coverage and content parity outrank canonicals, and get them right anyway, since they cost a template line at build time and a quarter of archaeology later. The crawl-first rebuild ships this by construction, which is the point of doing migrations that way.
Quick answers
How much do canonical tags matter after a website migration?
Yes, as tie-breakers at the moment your URL versions multiply: migrations spawn protocol, www, slash, and parameter variants while re-mapping every page, and canonicals nominate which version holds the rankings. They do not replace redirects, gone pages need 301s, but wrong or missing canonicals split signals across duplicates during the re-evaluation weeks. The correct state is every new page self-canonical at its final URL, server-rendered and consistent with the sitemap, which a crawl-first rebuild like WPBuildAI’s emits by construction from the same inventory that drives the redirect map.
Should an old page canonical to the new page instead of redirecting?
No, not when the old page is being replaced: a canonical is a suggestion engines may ignore, especially across domains or dissimilar pages, while a 301 is the instruction the situation calls for, and leaving the old page live with a canonical keeps a competing version in play. Reserve cross-page canonicals for genuinely living variants that must keep serving, parameters, print versions, tracking URLs. The rule of thumb: if the old URL should stop existing, redirect it; canonicals are for choosing among pages that continue to exist.
What canonical mistakes happen most during migrations?
Five recur: new pages still canonicalizing to old-domain URLs after a template carries over; an entire template canonicalizing to the homepage through a misconfiguration; canonicals injected by JavaScript that unrendered crawlers never see; staging or preview domains left indexable, competing with production; and sitemap, internal links, and canonicals nominating different URL forms, sending contradictory signals. All five are caught by the same launch check: crawl the new site, confirm every page’s canonical is present, self-referencing at the final URL form, and aligned with the sitemap.
How do I check which canonical Google actually chose?
Search Console answers it directly: the URL inspection tool shows the Google-selected canonical against your declared one per page, and the page-indexing report’s duplicate categories aggregate the pattern, “duplicate without user-selected canonical” where you never declared, “Google chose different canonical” where you disagreed. Early-weeks disagreements usually reflect signals still transferring from old URLs and settle as redirects process; persistent ones point at misalignment, typically internal links and sitemaps still referencing a different form than the canonical nominates, fixed by making all three agree.
When do canonicals not really matter after a move?
More often than the checklist industry admits: a small site with clean redirect coverage, one URL form consistently served, and no parameter machinery will consolidate fine on redirects alone, because engines resolve the obvious cases without help. Canonicals earn their attention as duplicate surface grows, e-commerce parameters, pagination, faceted navigation, multiple domains, and as the cost of ambiguity rises with traffic. The honest priority order for any migration remains redirects and content parity first, canonicals as the cheap-at-build-time layer you ship correctly because retrofitting them later costs archaeology.
