SEO · 11 min read
Six kinds of website migration, and the checks that differ between them
A redesign, a domain change and a subdomain consolidation are all called migrations and share almost none of their risk. This is the taxonomy: what dominates each kind of move, which checks are specific to it, and where the Change of Address tool does and does not apply.
Written by Zubair Afzal, FounderUpdated
Definition first
A migration is any change to what lives at an address
The word covers at least six genuinely different projects, and the reason generic checklists disappoint is that they average across all of them. A protocol change and a two-brand consolidation share a redirect map and almost nothing else. One is a configuration exercise; the other is a content architecture problem with a redirect map attached.
Sorting by type first is what turns a list into a plan. It tells you which risk dominates, which checks are load-bearing for your particular move, which are ceremony, and whether the tools you have been told to use apply at all.
One thing is constant across all six. The value that has accumulated is attached to addresses, and the project is fundamentally about carrying it from an old set to a new set without dropping any. Everything else — the design, the platform, the content model — is a separate project that happens to be running at the same time, and treating them as one project is why so many launches produce a fall nobody can explain.
From the documentation
What Google actually publishes about site moves
Six statements worth quoting in a project plan, because they settle arguments that otherwise run on opinion.
- Keep redirects in place for as long as possible, and generally for at least a year. Site moves with URL changes says so directly.
- A small to medium-sized site can take a few weeks for most pages to move, and larger sites take longer. The speed depends on the number of addresses and on server speed.
- Visibility may fluctuate temporarily during a move, and rankings settle over time. A dip is expected; a dip that does not begin recovering is a fault.
- The Change of Address tool is only for moves between domains or subdomains. It is documented as unnecessary for HTTP to HTTPS, for www changes on the same domain, and for path changes within a domain.
- The tool works on domain-level properties only. Both properties must be verified under the same account, and moving a domain with subdomains means using it for each of them.
- Redirecting a page to an irrelevant destination is treated as a soft not-found rather than as a move, which is what makes bulk redirects to the homepage worse than useless.
The taxonomy
Six kinds of move, and what dominates each one
Find your row first. The checks in it are the ones that decide the outcome; the rest of any generic list is secondary for your project.
| Dimension | What dominates the risk | The check that decides it | Change of Address tool |
|---|---|---|---|
| Redesign on the same addresses | Template and content loss. Nothing moved, so nobody built a map, and the pages quietly got thinner. | Compare word count, internal links and structured data per template, old against new, before launch. | Not applicable. |
| Replatform with new addresses | The map itself, plus the content model changing shape at the same time as the addresses. | Every old address of value resolves in one hop to a page that answers the same question. | Not applicable — same domain. |
| Domain change or rebrand | Everything at once: addresses, brand recognition, existing links, and search results still naming the old brand. | Both properties verified, redirects live, and the Change of Address submitted for every subdomain. | Yes. This is what the tool is for. |
| HTTP to HTTPS | Mixed content and half-migrated internal links, which leaves two live copies of the site. | Every internal link, canonical, sitemap entry and hard-coded asset uses the secure address. | No. Documented as unnecessary. |
| Subdomain to subfolder, or the reverse | Analytics and reporting continuity, and the assumption that a folder inherits authority immediately. | Redirects plus a full rewrite of internal links, and tracking configured before the move rather than after. | Yes for a subdomain change, if it is a domain-level property. |
| Merging two sites, or splitting one | Two pages now competing for one search, or one audience split across two sites that each look thinner. | A page-level decision for every duplicate pair: which survives, which redirects, and what the survivor must absorb. | Only if a domain is being retired. |
Unrecognised migrations
Four projects nobody calls a migration, which are one
These arrive without a project plan, a benchmark or a redirect map, because nobody involved used the word. They produce exactly the same failure.
- The URL pattern is tidied up across a whole section.
- Someone decides the dated blog addresses look old-fashioned, or that a category level should be removed from product paths. It is presented as a cosmetic change and implemented in an afternoon. Every address in that section has changed, which makes it a migration of everything you publish, usually without a benchmark to compare against afterwards.
- A second language is added to the site.
- Adding a language usually means the existing pages acquire a prefix, which moves every one of them. It also introduces alternate-version declarations that have to be reciprocal to be honoured. Two changes at once, on every address, described in the plan as a content project.
- The blog is moved onto the main domain.
- Frequently the right decision, and rarely treated as a move. The content changes address, the internal link graph changes shape, analytics splits at the boundary, and if the blog carried the majority of the site’s external links, the site’s entire link profile is being re-pointed in one release.
- A section is retired without deciding what happens to its addresses.
- Discontinuing a product line or closing a service removes pages that may hold external links and steady search demand. Deleting them without a decision leaves a set of not-found pages where value used to sit. The right answer is often a redirect to the nearest relevant page, and sometimes a deliberate gone response, but it should be a decision rather than a side effect.
The map
How to decide what each old address becomes
Apply these in order to every address in the inventory. The rule is the deliverable — a map built by judgement alone cannot be reviewed by anybody else.
Is there a page that answers the same question?
If yes, redirect to it permanently, in a single hop, and stop. This covers the large majority of addresses and it is the only case where nothing is lost. The test is the reader’s question, not the page title: a product replaced by its successor answers the same question, while a product page redirected to the category does not.
You get: A one-to-one mapping for every address with a genuine equivalent
Does it have value but no equivalent?
Value means external links, steady search clicks, or revenue attributed to it. Redirect these to the nearest genuinely relevant page — the parent category, the replacing service, the successor article — and record the decision with the reason. Never to the homepage: a redirect to an irrelevant destination is treated as a soft not-found, so the value is not carried anyway.
You get: A mapping with a written justification per address, reviewable by somebody else
Is it noise the site generated?
Filter combinations, sort parameters, session identifiers, internal search results and paginated variants beyond the first page rarely deserve a rule each. Handle them with a pattern, and take the opportunity to stop generating them. This is usually where the address count collapses from an alarming number to a manageable one.
You get: Pattern-level rules covering the generated address space
Is it genuinely finished?
A page for a discontinued product with no successor, an event that has happened, a role that is filled. Return gone rather than not-found where you are certain, because it is a clearer statement and it stops the address being retried indefinitely. Check first that nothing valuable links to it, because an external link pointing at a gone page is value being discarded.
You get: A retirement list, checked against external links before it is executed
Verify the map against the live site, not the plan
Take the highest-value addresses by clicks, by revenue and by external links, and request each one on the live site after launch. Check the status, the number of hops and the destination. A rule that behaves correctly on staging can meet a different set of rewrite rules in production, and the first hour after launch is when that is cheap to fix.
You get: A tested sample of the highest-value addresses, run against production on launch day
Questions
Questions asked before and after a move
How long should redirects stay in place?
Google’s documentation on site moves says to keep the redirects for as long as possible, generally at least a year. That is a longer commitment than most launch plans assume.
The practical reading is that the redirect layer is part of the site, not a temporary scaffold. It needs to survive the next platform change, which means it should live somewhere version-controlled and documented rather than in whichever plugin was convenient on launch day.
Do we need the Change of Address tool?
Only for a move between domains or subdomains. Search Console documents it as unnecessary for HTTP to HTTPS moves, for switching between www and non-www on the same domain, and for moving paths within one domain.
It also only works on domain-level properties, both old and new must be verified under the same account, and the redirects have to be in place first. If you are moving between domains that have subdomains, the tool has to be used for each one.
How long does a site move take to settle?
Google states as a general rule that a small to medium-sized site can take a few weeks for most pages to move, and that larger sites take longer, with the speed depending on the number of addresses and the server. It also notes that visibility may fluctuate temporarily during the move and that this is normal.
What that does not license is an indefinite wait. If clicks have not begun recovering on your highest-value pages within a few weeks, that is a signal to investigate rather than to be patient.
The developers are handling the redirects. What is left?
The map. Developers implement rules; the difficult work is deciding what each old address should point to, and that requires knowing which addresses had value, which links point at them and which have no equivalent on the new site.
The other thing left is verification. A rule that works on staging can behave differently against live data, so the highest-value addresses need testing against the live site on launch day rather than the morning after.
We are keeping every URL identical. Do we still need any of this?
Less of it, but not none. A same-address move puts the risk in the templates rather than the map: content that got shorter because the design looked better that way, internal links that no longer exist, structured data that did not survive the rebuild, and staging directives that shipped with the site.
The other frequent casualty is measurement. If analytics or conversion tracking changes at the same time, you lose the ability to tell whether anything went wrong, which is worse than a problem you can see.
Can we redirect everything to the homepage instead?
No. Google treats redirects to an irrelevant destination as a kind of not-found, so the value of the old page is not carried across and the visitor lands somewhere that does not answer their question.
Where there genuinely is no equivalent page, the honest options are the nearest relevant parent — a category rather than the homepage — or letting the address return gone. A deliberate 410 is a better outcome than a misleading redirect.
Tell us which kind of move you are planning
The type decides most of the plan. Describe the change and the launch date, and we will tell you what the dominant risk is and what has to be settled before the date is agreed.
Last updated