Canonical tag issues that appear after migrations | Lillian purge

Canonical tag issues that appear after migrations

From experience, canonical tag issues are one of the most common, least understood, and most damaging problems that appear after a site migration. I have been brought into countless migrations weeks or months after launch where everything looked fine on the surface, pages loaded, redirects were in place, design was approved, yet traffic was quietly declining and rankings were slipping without any obvious error.

In many of those cases, the culprit was not broken redirects, missing pages, or technical downtime, it was canonical tags quietly telling Google to ignore the very pages the business wanted to rank.

In my opinion, canonical issues are so dangerous after migrations because they rarely cause dramatic failures. Instead, they cause slow erosion of visibility, diluted relevance, and confused indexing. By the time someone notices the impact, Google has already learned the wrong version of the site.

This article explains canonical tag issues that appear after migrations, why they happen so frequently, how they manifest in real-world performance, and how to think about canonicals properly rather than treating them as a box to tick. Everything here is based on hands-on migration audits, post-migration recoveries, and years of diagnosing SEO problems that only made sense once canonicals were understood correctly.

What a canonical tag is supposed to do

Before talking about issues, it is important to be clear about intent.

A canonical tag is a signal to search engines that says this is the preferred version of this content. It exists to help Google understand which URL should be treated as authoritative when multiple URLs contain similar or identical content.

From experience, canonicals work best when they are simple, consistent, and aligned with reality. They are not directives in the strictest sense, but Google usually respects them when they make sense.

The problems begin when canonicals are treated as technical decoration rather than strategic signals.

Why migrations create the perfect conditions for canonical errors

Migrations change everything that canonicals depend on.

From experience, during a migration URLs change, templates change, CMS logic changes, pagination behaviour changes, and often multiple environments are involved such as staging, pre-production, and live.

Canonicals are often inherited from old templates, copied blindly into new ones, or auto-generated by CMS rules that no longer make sense in the new structure.

Because canonicals rarely break pages outright, they are often overlooked during testing.

In my opinion, migrations do not create canonical problems intentionally, they expose assumptions that were never revisited.

The most dangerous canonical issue of all, pointing to the old domain

This is more common than most people expect.

From experience, one of the most damaging post-migration issues is canonicals that still point to the old domain. This often happens when templates are copied over or when CMS settings are not updated correctly.

The result is that every new page tells Google that the old URL is the preferred version. Even with correct redirects in place, this creates a conflict.

Google is forced to choose between redirects and canonicals, and that choice does not always favour the new site.

Traffic declines slowly as Google continues to associate authority with URLs that no longer exist.

Why redirects do not automatically fix bad canonicals

This is a critical misunderstanding.

From experience, many people assume that because redirects are in place, canonicals do not matter. That is not true.

Redirects tell Google where a URL has moved. Canonicals tell Google which version of content is preferred. When they contradict each other, Google has to decide which signal to trust.

If every page says the old domain is canonical, Google may continue consolidating signals there even after crawling the redirect.

This slows down or weakens migration recovery.

Self-referencing canonicals that are no longer correct

Self-referencing canonicals are usually good practice.

From experience, after migrations they often become wrong without anyone noticing. This happens when URL parameters change, trailing slashes are introduced or removed, or URL casing rules change.

A page may canonicalise to a version of itself that no longer exists or that redirects.

This creates unnecessary loops and confusion.

Google may index the wrong version or treat the page as duplicate content.

Canonicals pointing to redirected URLs

This issue appears frequently after migrations.

From experience, canonicals are often left pointing at URLs that now redirect. While Google can follow this chain, it weakens the signal.

Canonicals should point directly to the final preferred URL, not to an intermediate redirect.

When canonicals point to redirected URLs, Google may delay consolidation or choose an alternative version instead.

Over time, this leads to unstable rankings.

Canonicals removed entirely during redesigns

Some redesigns remove canonicals by accident.

From experience, this often happens when templates are simplified or when developers assume canonicals are unnecessary.

On large sites or ecommerce platforms, removing canonicals can explode duplicate content issues overnight.

Google suddenly sees many URLs with similar content and no guidance on preference.

After migrations, this can cause rapid index bloat and ranking dilution.

Over-canonicalisation to top-level pages

Another common mistake is excessive consolidation.

From experience, some migrations introduce rules that canonicalise many pages to a single top-level page, such as a category or homepage.

This is often done to reduce duplication or simplify structure, but it backfires badly.

When important pages canonicalise away their own relevance, Google removes them from consideration for their specific queries.

Traffic drops because Google no longer sees those pages as valid landing pages.

Why homepage canonicals are especially dangerous

Homepage canonicals are rarely appropriate.

From experience, migrations sometimes accidentally set homepage as the canonical for every page due to a misconfigured template variable.

This effectively tells Google that all content is the same as the homepage.

The result is catastrophic for SEO, but not immediately obvious because pages still load and redirect correctly.

By the time rankings collapse, weeks or months may have passed.

Canonicalising paginated content incorrectly

Pagination behaviour often changes during migrations.

From experience, paginated pages may suddenly canonicalise to page one or to the root category without careful consideration.

This removes pagination pages from the index and can significantly reduce long-tail visibility.

For content heavy sites or ecommerce listings, this leads to lost impressions and reduced crawl coverage.

Pagination canonicals must reflect strategy, not convenience.

Canonicals conflicting with hreflang after migrations

International sites face compounded risk.

From experience, migrations that affect domain structure or language folders often break the relationship between canonical and hreflang tags.

Canonicals may point to one language version while hreflang references another.

Google may ignore both signals or choose one arbitrarily.

This leads to incorrect geo targeting and lost international visibility.

Canonicals generated dynamically without validation

Modern CMS platforms often generate canonicals automatically.

From experience, these systems make assumptions that may not align with SEO strategy after a migration.

For example, canonicals may strip parameters that are actually meaningful, or include parameters that should not be indexed.

Without manual validation, dynamic canonicals often create silent SEO damage.

Canonical tags pointing to non-indexable pages

This happens more often than people realise.

From experience, canonicals sometimes point to pages that are blocked by robots.txt or marked noindex.

This creates a logical contradiction, the preferred version is not allowed to be indexed.

Google may then ignore the canonical entirely or choose another URL.

After migrations, this often happens when staging rules leak into production.

Staging environment canonicals leaking into live sites

This is a classic migration error.

From experience, staging environments often use canonicals pointing to the live domain to avoid duplicate indexing during development.

If this logic is reversed or left unchanged at launch, live pages may canonicalise to staging or vice versa.

This can remove live pages from the index completely.

It is one of the fastest ways to destroy organic visibility.

Canonical chains that grow over time

Canonicals can form chains just like redirects.

From experience, migrations often introduce canonical chains where page A canonicalises to page B which canonicalises to page C.

Google does not always follow long chains reliably.

Over time, signals weaken and indexing becomes unpredictable.

Canonicals should always resolve in one step to the final preferred URL.

CMS migrations that change trailing slash behaviour

Trailing slash changes are common in migrations.

From experience, moving from non-slash to slash URLs or the reverse often creates canonical confusion.

Pages may canonicalise to one format while internal links use another.

Google sees duplication and inconsistent preference signals.

Consistency is essential for canonical reliability.

Canonicals and query parameter handling

Query parameters often change after migrations.

From experience, canonicals may strip parameters that were previously indexed or preserve parameters that should now be ignored.

This affects faceted navigation, filtering, and tracking parameters.

Poor parameter canonicalisation can either flood the index or starve it.

After migrations, parameter rules must be re-audited.

Why canonical errors rarely show as errors

This is what makes them dangerous.

From experience, canonical issues do not usually appear as errors in tools. Pages are accessible, they load correctly, and there are no server failures.

Search Console may show indexed pages declining, but not explain why.

Unless someone inspects canonicals directly, the issue remains hidden.

How canonical issues appear in Search Console

The signs are indirect.

From experience, you may see pages marked as duplicate without user-selected canonical, or Google chose different canonical than user.

These messages are not always treated seriously, but after migrations they are critical clues.

They indicate Google does not agree with your canonical strategy.

Why Google sometimes ignores your canonical tags

Google ignores canonicals when they do not make sense.

From experience, if a canonical points to a page with different content, lower quality, or conflicting signals, Google will choose its own.

After migrations, content changes can invalidate old canonical assumptions.

Google prioritises consistency and usefulness over declared preference.

Canonicals versus internal linking signals

Internal links are powerful.

From experience, when internal linking contradicts canonical tags, Google may trust links more than canonicals.

If every internal link points to a different URL than the canonical, the canonical signal weakens.

After migrations, internal linking structures often change and canonicals must be reviewed alongside them.

Canonicals and sitemap conflicts

Sitemaps matter.

From experience, when sitemaps list URLs that are not canonical, Google receives mixed messages.

Sitemaps should list canonical URLs only.

After migrations, outdated sitemaps are a common source of canonical confusion.

Canonical handling in ecommerce migrations

Ecommerce migrations are especially risky.

From experience, product variants, filters, and sorting options often generate complex canonical rules.

When these rules change during migration, entire product ranges can disappear from search.

Canonical strategy must be defined clearly before migration, not patched after.

Content consolidation and canonical misuse

Content consolidation is often part of migrations.

From experience, merging pages without updating canonicals correctly leads to pages still canonicalising to removed or merged URLs.

This prevents new consolidated pages from gaining authority.

Consolidation must include canonical re-mapping as well as redirects.

When canonicals cause partial deindexation

Partial deindexation is common.

From experience, only some sections of a site lose visibility because canonicals behave differently across templates.

This makes diagnosis harder.

It often looks like random traffic loss when the underlying cause is systematic.

Why canonical audits should be manual not automated

Automated tools help but are not enough.

From experience, canonical intent must be understood contextually. Tools can flag mismatches, but they cannot judge whether a canonical makes sense strategically.

Manual review of key templates and representative pages is essential after migrations.

The role of SEO in defining canonical strategy

Canonical strategy is not a developer decision.

From experience, developers implement canonicals, but SEO defines what they should express.

Without SEO input, canonicals are often generic or copied from defaults.

This disconnect causes many migration failures.

Canonicals and AI driven search interpretation

AI systems look for consistency.

From experience, AI search relies on canonical clarity to summarise and attribute content.

Confused canonicals reduce confidence and visibility in AI responses.

As AI becomes more influential, canonical accuracy matters even more.

How long canonical issues take to cause damage

Damage is gradual.

From experience, it often takes weeks or months for canonical errors to fully affect rankings.

This delay makes cause and effect hard to link.

By the time the impact is obvious, Google has already learned the wrong signals.

How long recovery takes once fixed

Recovery also takes time.

From experience, even after canonicals are corrected, Google needs to recrawl, reassess, and reconsolidate signals.

Improvements may lag behind fixes.

Patience is required, but correct canonicals are a prerequisite for recovery.

Why canonicals should be reviewed at every migration stage

Canonicals should be reviewed multiple times.

From experience, checks are needed during planning, staging, pre-launch, and post-launch.

Assuming they are correct because they were correct before is a mistake.

Every structural change can affect canonical logic.

A practical mindset for canonicals after migrations

Canonicals should answer one question clearly.

Which URL do you want Google to treat as the authoritative version of this content.

If the answer is unclear, the canonical is likely wrong.

Simplicity beats cleverness every time.

Final reflections from experience

From experience, canonical tag issues that appear after migrations are one of the most common causes of silent SEO failure.

They do not crash sites, they do not trigger alarms, and they do not break user journeys. Instead, they quietly tell Google to devalue or ignore the very pages you need to succeed.

In my opinion, canonicals deserve far more respect than they usually get during migrations. They are not optional, and they are not technical trivia.

Handled correctly, canonicals protect relevance, authority, and long-term visibility. Handled poorly, they undermine everything else you do.

If there is one lesson to take away, it is this, after a migration, never assume your canonicals are fine. Always verify them, because by the time Google shows you the consequences, the damage is already underway.