What counts as a migration
More things than people expect, and the risk is roughly proportional to how many of these are true at once.
- A redesign that changes URLs — the most common and the most underestimated, because it does not feel like a migration.
- A platform change: WordPress to Shopify, Shopify to WooCommerce, anything to anything.
- A domain change, including a rebrand or moving from .co.uk to .com.
- Moving from http to https, or from a subdomain to a subfolder, or merging two sites into one.
- A restructure that keeps the platform and changes the hierarchy — often the highest-value change and the one that most needs redirects.
A redesign that keeps every URL identical is not a migration and carries almost none of this risk. That is worth knowing, because it is also the cheapest way to redesign: if the structure is sound, leave the addresses alone and change everything else.
The checklist, in order
Order matters here more than in most technical work, because several of these are impossible to do properly after launch.
Before anything is designed
- Export every URL you have. From your sitemap, from the platform, and — this is the one people skip — from Search Console, which knows about pages your sitemap has forgotten.
- Export performance per URL for the last twelve months: clicks, impressions, queries. This tells you which pages actually earn, and it is rarely the ones anybody expects. Protect those first.
- Export your backlinks, or at least the referring domains. A page with links pointing at it is worth more than its traffic suggests, and losing it loses the links too.
- Crawl the current site so you have a record of titles, headings and internal links to compare against afterwards.
While it is being built
- Map old URL to new URL, one row per page, as a spreadsheet somebody owns. This document is the migration; everything else is implementation.
- Keep URLs identical wherever you possibly can. Every one you keep is a redirect you do not need and a risk you do not take. Changing URLs for tidiness is the most common self-inflicted wound in this whole exercise.
- Move the content, not just the pages. A redesign that halves the words on a page that was ranking will usually halve what it ranks for.
- Rebuild the internal links to point at the new destinations directly, rather than relying on the redirects to carry them.
- Keep the site on a staging environment that is noindexed and password-protected, and check that it is before you put anything on it.
At launch
- Put the redirects live at the same moment as the site, not the following morning.
- Every redirect is a single permanent (301) hop to the closest equivalent page. Not a chain, not a temporary redirect, and not everything to the homepage.
- Submit the new sitemap in Search Console and leave the old one in place for a few weeks so Google is reminded of what moved.
- Check the robots file has not shipped with the staging rules. This is a genuinely common, genuinely catastrophic mistake and it takes ten seconds to check.
- Verify the new property in Search Console if the domain changed, and use the change of address tool.
For a month afterwards
- Watch the Search Console coverage report weekly. Rising "not found" or "redirect error" counts are the early warning.
- Compare clicks and impressions week on week against the same period before. A dip in the first fortnight is normal; a sustained drop after a month is a fault.
- Watch the 404 log and fix anything real. Some of what appears will be old junk URLs and can be ignored — the ones with traffic or links cannot.
- Re-crawl and compare titles and headings against your pre-launch record. Things get dropped in the last week of a build and nobody notices.
The four ways it goes wrong
Nearly every migration disaster is one of these, and all four are avoidable in advance and expensive afterwards.
| Mistake | What happens | Fix |
|---|---|---|
| Everything redirected to the homepage | Google treats a mass redirect to an unrelated page as a soft 404 and discards the equity entirely | One-to-one, to the closest equivalent page |
| No redirects at all | Every ranking page becomes a 404. Rankings and links both go | The URL map, made before the build |
| Redirect chains | Old → interim → new dilutes and slows. Long chains stop being followed | Point every old URL at the final destination |
| Content cut to fit the design | Pages keep their URLs and lose what made them rank | Design around the content, not the other way round |
A fifth, rarer and worse: shipping the staging robots file, which tells Google not to index anything. It is usually caught within days, and those days cost more than the rest of the migration.
E-commerce migrations are harder, and here is why
A brochure site has tens of URLs. A shop has thousands, and three extra things that can break.
- Product URLs change format between platforms, and the mapping has to be generated rather than typed. This is a script, not an afternoon.
- Category pages are usually where the ranking lives, and their descriptions are the first thing dropped in a rebuild. Move them.
- The shopping feed has to be rebuilt deliberately. A default platform export on a large catalogue will silently omit items, and the first sign is a quiet month rather than an error.
On Beds.ie — a 17,000-product catalogue — the feed sits at 94.5% approval, 16,281 of 17,233 items live, precisely because the sync reports its rejections instead of dropping them. After any migration, the first thing to check is the gap between items submitted and items active. Most retailers have never seen those two numbers next to each other.
Do not migrate a shop in your peak trading month. It sounds obvious and it is proposed constantly.
What recovery actually looks like
| When | What is normal |
|---|---|
| Week 1 | Crawling spikes. Impressions wobble. Some rankings move in both directions. |
| Weeks 2–4 | Most of the old URLs have been re-crawled and consolidated. Traffic returns toward the previous level. |
| Weeks 4–8 | Back to baseline, and often above it if the structure improved. |
| After 8 weeks | A sustained shortfall is a fault, not a settling period. Go back to the redirects. |
The dangerous belief is that a drop will recover on its own given enough time. Sometimes it does. Often the cause is a redirect that was never made, and every week it stays broken is a week of a page being treated as gone.
