How to Manage Canonical and Hreflang Tags During a Site Migration
Both of these are instructions your site gives about which version of a page is the one that counts. Both survive migrations badly for the same mechanical reason. They contain addresses. Change the addresses and leave these behind, then the site starts telling crawlers two different things at once.
Both Of These Contain Addresses
Anything on a site that contains an address has to be updated when addresses change. That sounds obvious. These two get missed constantly, because they are completely invisible to anybody looking at the page.
Why invisibility matters so much. Nothing prompts a check.
A broken image is noticed. A missing paragraph is noticed. An instruction embedded in the page that quietly names an address nobody uses any more looks exactly like a working page, from every angle a person can see.
Who these instructions are for. Not visitors.
They exist entirely to tell crawlers something about the page. Visitors never encounter them, which means visitor testing never touches them and a full round of user acceptance testing can pass with both completely wrong.
Why they are grouped here. Same failure, same fix.
One is about duplicate versions of a page and the other about language versions. Mechanically they fail identically. Both are verified at the same moment by the same person, which is block eight.
What most readers need. The first half.
Canonicals affect nearly every site. Language declarations affect a minority, which is why blocks six and seven are shorter and can be skipped by anybody without them.
What A Canonical Actually Says
A canonical annotation is a page naming which address is the real one for its content. When several addresses show the same thing, it settles which of them counts.
Why duplicates exist at all. Rarely on purpose.
The same page can be reachable with and without a trailing slash, with tracking information attached to the address, through a filter, perhaps as part of a paginated set. Nobody created those deliberately. They are how sites work.
What the annotation resolves. The ambiguity.
Without it, a crawler encountering four addresses showing identical content has to decide which represents the page. The annotation makes that statement explicit instead of leaving it to be inferred.
Why that matters commercially. Concentration.
Whatever a page has earned should attach to one address rather than being spread across several versions of itself. That is the entire purpose. It is also why a wrong annotation is worse than a missing one.
What it is not. A redirect.
All four addresses still work and still serve content. This is a statement about which one is authoritative rather than an instruction to send anybody anywhere.
The Migration Failure
A new page carrying an annotation that names its old address is telling crawlers the old page is the real one. That undoes the migration for that page completely, while everything looks correct.
What the site is saying. Two contradictory things.
The redirect says the content has permanently moved to the new address. The annotation on the new page says the authoritative version is the old address. Those cannot both be acted on.
Where it comes from. The content itself.
On a platform move, annotations are frequently stored alongside the content rather than generated fresh. Export the content, import it into the new system, then the old addresses arrive inside it, embedded in every page.
Why nobody catches it. The content transferred perfectly.
That is the point. The transfer worked exactly as intended, which is why nobody suspects it. The annotation came across as faithfully as the words did.
How widespread it can be. Every page at once.
This is not a stray error on one template. Where it happens it usually affects everything that was exported, which makes it one of the more consequential things to check.
Self-Referencing Is The Safe Default
In the ordinary case, a page should name itself as the authoritative version. That sounds circular and it is the sensible starting position for almost every page on almost every site.
Why naming yourself helps. It removes the ambiguity.
A page stating plainly which address represents it settles the question for every variant that might exist, including ones nobody anticipated. Filters, tracking parameters and alternative paths all resolve to the same answer.
When it should point elsewhere. Genuine duplication.
Where a page really is a variant of another, naming the original is correct. A print version, a filtered view of a category or a syndicated copy are the standard cases.
Why the default matters during a migration. It fails safely.
A page naming itself cannot point at a stale address, because its own address is whatever it currently is. That single habit removes the entire failure described in block three.
What we will not publish. How to set it.
This is a decision to agree with whoever builds the site rather than something to edit. The useful question to ask them is whether pages self-reference by default and what happens when they do not.
Canonicals And Redirects Should Agree
When a redirect says one thing and an annotation says another, the decision is left to whoever is reading. Consistency is the entire job. It is checkable in minutes.
What the documentation says. Checked August 2026.
The vendor's own site move guidance instructs that once the redirects are active, the canonical annotations on the new site should be using the new addresses. It pairs that instruction directly with updating any do-not-index rules that were added during building.
Why that pairing is notable. Same origin, same moment.
Both are things added or inherited during a build that need changing at launch. Both are invisible afterwards. Treating them as one check rather than two is how the vendor presents it and how it should be handled.
What agreement looks like. One story.
Old addresses redirect to new ones. New pages name themselves. Nothing anywhere still refers to an address that no longer serves content.
What disagreement produces. An unpredictable outcome.
Not necessarily a disaster, nor something anybody can forecast. The point of consistency is that it removes the question rather than gambling on how it gets resolved.
Hreflang
This applies only to sites with language or regional versions of the same content. If that is not you, block eight is where to go next.
What it does. Connects equivalents.
It declares that a page has counterparts intended for different languages or countries, identifying which is which. A visitor in one place can then be shown the version meant for them rather than a version they cannot read.
What problem it solves. Confusion between near-identical pages.
Two English pages written for different countries can be almost the same, differing in currency, spelling and contact details. Without a declaration connecting them, they look like duplicates competing with each other.
Why it belongs in a migration guide. It contains addresses.
Every declaration names the addresses of the counterpart versions. Change any address on any version and every declaration referring to it is now naming something that has moved.
Why it deserves care rather than length. The failure is severe.
It is a minority subject with a majority-sized consequence for the sites that use it, which is block seven.
Hreflang Is Reciprocal And That Is Where It Breaks
These declarations have to agree in both directions. If one page names another as its counterpart, the second has to name the first in return. A migration changing addresses on one side breaks the pair.
Why reciprocity is required. Anybody could claim anything.
Without it, one site could declare itself the counterpart of another site's page unilaterally. Requiring both sides to agree means the relationship is confirmed by both rather than asserted by one.
How a migration breaks it. One side moves.
Move the UK version and update its declarations. The other versions still name the old UK address. Their declarations now point at something that has moved. The confirmation each pair needs no longer exists.
Why it fails silently. Nothing reports it.
No error appears. Every page loads. The declarations are still present and look complete. The relationship they were meant to establish has simply stopped being confirmed, with no symptom at all.
What this means practically. Update every version together.
A migration touching one language version is a migration touching all of them, which is a scoping point worth raising before anybody estimates the work. The types page covers where this sits, in types of site migration.
Check These Before Launch And Again After
Both of these take minutes to verify and both are among the more damaging things to get wrong, which is an unusually favourable ratio and the reason they belong on the launch checklist rather than in a later review.
What to check before launch. On the staging build.
Whether pages name themselves or something else, plus whether any address named anywhere belongs to the old site. Where language versions exist, whether every pair still agrees in both directions.
What to check immediately after. The same thing, live.
Environments differ, so what was correct on staging can arrive differently once live. This is the same reason redirects are tested twice.
Who does it. Somebody who can read the page source.
This is not a task for a visual review. It needs whoever is responsible for the technical side, working from the mapping, which is why it belongs with the crawling and indexing checks rather than with the design review.
Where this sits in the sequence. Alongside the other invisible checks.
Together with the two failures in crawling and indexing during a site migration. If something has already gone wrong, diagnosis is in redirect errors and recovery after migration. The full series is on the website migration guide.
Invisible on
the page.
Checked anyway.
Pages set to name themselves so they cannot point at a stale address, annotations checked against the redirects so the site tells one story, language pairs updated on every version together rather than one at a time, both verified on staging and again live, with no markup published that anybody could edit unsupported.
What a migration engagement covers:
A migration is a one-off project rather than a monthly service, so it is scoped and quoted against the size of the site and how much is changing at once.
Every guide.
One practice.
What a migration is, the types, when to do it, planning, the checklist, auditing, mapping, redirects, internal links, tags, downtime, crawling, structured data, performance, notifying, monitoring, recovery and the mistakes.
