In a migration, canonical tags frequently break, and because they break quietly, the damage often shows up weeks later as duplicate content or pages that will not rank. There are three common failures, and each confuses search engines about which version of a page should rank. First, the new platform drops the canonical tag entirely, so pages lose the signal that tells search which URL is the real one. Second, the canonical is carried over but still points at the old URL, so every new page credits an address that now returns 404. Third, a template sets the same canonical on every page, often the homepage, so the whole site declares itself duplicates of one URL. The fix is the same in each case: every page should carry a self referencing canonical that points to its own new URL, and genuine duplicates should point to the chosen original. WPBuildAI scans your site and returns each page with its current canonical, so you can confirm the new site points every page at the right URL.
Canonicals and host variants are the same problem seen from two angles, which is why Google’s June 2026 guidance asks you to declare the move for every subdomain and both the www and non-www form: a variant still serving its own copy will compete with your canonical however correct the tag is.
What a canonical tag is for
A canonical tag is a small line in a page’s head that names the preferred URL for that content. When the same or similar content is reachable at more than one address, the canonical tells search engines which one to index and credit, as described in Google’s guide to consolidating duplicate URLs. On a healthy site, most pages simply point their canonical at themselves, which declares each page the original version of its own content. The tag is quiet and invisible to visitors, but it carries real weight, because it decides where ranking signals accumulate. That quietness is exactly why a migration can damage it without anyone noticing.
Failure one: the canonical is dropped
The first failure is absence. A new theme or platform may not output a canonical tag at all, either because the feature is off by default or because the old site relied on a plugin that did not come along. Now no page states its preferred URL. On many sites this is survivable, but where the same content is reachable at several addresses, such as with and without a trailing slash or through query parameters, search engines have to guess which to rank, and they may split signals across versions or pick the wrong one. The cure is to restore a self referencing canonical on every page so each one again declares itself the original.
Failure two: the canonical still points at old URLs
The second failure is the most damaging and the easiest to miss. The migration copies the old canonical value into the new page, so a page now living at a new URL tells search that its real version is the old URL. After the old URLs are retired, those canonicals point at addresses that return 404. In effect every page disowns itself and credits a dead address. This is closely tied to redirects: the new URL needs a self referencing canonical, and the old URL needs a 301 to the new one, as the guides on site moves and redirects describe. Get either wrong and ranking signals leak away.
Failure three: one canonical for the whole site
The third failure comes from a template applied too broadly. A theme sets a single canonical value, often the homepage, on every page through a shared header. Now the entire site tells search that all of its pages are duplicates of one URL. Search engines respond by consolidating everything onto that one page and ignoring the rest, so deep pages stop ranking even though their content is intact. This one is dangerous because the site looks fine to a visitor and even to a quick glance at the homepage; only an inspection of inner pages reveals that they all point at the same canonical.
Why canonicals do not survive on their own
Underlying all three failures is one fact: canonical tags do not move themselves. They are generated by the platform, theme, or an SEO plugin, and when any of those changes, the output changes with it. A migration replaces exactly those layers, so unless someone deliberately carries the canonical intent across, the new site ships with whatever its template happens to produce. Treating canonicals as something to verify, not assume, is the whole discipline. Web Almanac 2024 (HTTP Archive) is a reminder of how many URLs a site has, which is also how many canonicals can quietly go wrong at once.
How to carry canonicals across correctly
- Inventory the current canonicals for every page before you migrate.
- Set self referencing canonicals so each new page points at its own new URL.
- Point genuine duplicates at the single original you want to rank.
- Pair every changed URL with a 301, so canonical and redirect agree.
- Never apply one canonical sitewide through a shared template.
- Inspect inner pages after launch, not just the homepage.
Worked example: a clean canonical migration
Imagine a blog of three hundred posts moving to a new platform. Before the move, the team exports each page with its current canonical and notes that nearly all are self referencing. On the new platform they confirm the theme outputs a self referencing canonical per page rather than one template value, and they spot check inner posts to prove it. For the handful of tag and archive pages that duplicate post content, they set the canonical to the main post. Each old URL gets a 301 to its new self. After launch they inspect a sample of deep pages and confirm every canonical points at its own new URL. No duplicate content warnings appear, because canonical and redirect tell the same story. The same care applies when you change permalink structure without losing SEO.
Limitation: canonicals are a hint, not a command
It is honest to note what canonicals can and cannot do. A canonical is a strong hint to search engines, not an order; if your canonical contradicts your redirects, your internal links, or your sitemap, search may ignore the tag and choose a different URL. So a correct canonical only helps when the rest of your signals agree with it. A canonical also cannot rescue thin or duplicated content on its own, and it cannot replace a 301 for a moved page. Think of it as one voice in a chorus that must sing in tune with redirects and links, a theme covered more broadly in avoid duplicate content in a redesign.
Common mistakes
- Assuming the new platform outputs correct canonicals without checking.
- Letting migrated pages keep canonicals that point at old, now dead URLs.
- Applying one sitewide canonical, often the homepage, to every page.
- Setting canonicals that disagree with the site’s 301 redirects.
- Checking only the homepage and never inspecting inner pages.
Key points
After a migration, canonical tags often break in one of three ways: dropped entirely, left pointing at old URLs, or set sitewide to a single page. Each error confuses search engines about which version of a page should rank, and because the tag is invisible, the damage surfaces late. The fix is consistent: give every page a self referencing canonical pointing at its own new URL, point real duplicates at the chosen original, and make sure canonicals agree with your 301 redirects. Inspect inner pages after launch, not just the homepage, since a sitewide canonical hides in plain sight. Because platform changes also affect other invisible signals, see does changing platform affect schema markup and what changing a site URL does to SEO. WPBuildAI scans your site and returns each page with its current canonical, so you can confirm the new site points every page at the right URL. Send your web address for a free analysis.
Not affiliated with WordPress, Lovable, Webflow, Shopify, Wix, or Squarespace.