A site migration is any change that alters the addresses your pages live at, the platform serving them, or both. New domain, HTTP to HTTPS, a replatform, a redesign that changes URLs, or a permalink change all count.
Migrations lose traffic when the redirects are wrong and when nobody checks properly afterwards. This covers what Google documents, the order of work, and the verification problem that makes a healthy migration look like a disaster.
What Google actually tells you to do
Google publishes specific guidance for a site move with URL changes. Starting from it saves arguing about opinions.
- Use server-side permanent redirects where technically possible, meaning 301 or 308. Client-side redirects are a last resort.
- Redirect each old URL straight to its final destination. Google advises going directly rather than through chains.
- Do not funnel old URLs to the homepage. In Google’s words, you should not “redirect many old URLs to one irrelevant single URL destination”, which can be treated as a soft 404.
- Keep the redirects for as long as possible, and generally at least a year, so signals transfer. Google also notes that permanent redirects do not reduce PageRank.
- Submit a new sitemap listing the new URLs. The old sitemap can be removed, since Google will use the new one going forward.
- For a domain or subdomain change, file a Change of Address in Search Console for the old site.
- Move small and medium sites all at once. Google recommends moving all URLs simultaneously, and reserves staged moves for large sites, where it suggests testing with a section that changes infrequently.
Source for all of the above: Google Search Central.
What to expect, so you do not panic
Google is explicit that you should “expect temporary fluctuation in site ranking during the move”. For medium-sized sites it says showing the new URLs can take “a few weeks or more”, and larger sites take longer.
That sets the baseline. A dip in the first weeks is the documented normal case, not evidence that something broke. The thing to watch is whether it recovers on that timescale, which is why the baseline you take beforehand matters more than anything you do afterwards.
Before you touch anything
Everything that goes wrong in a migration goes wrong because this part was skipped.
- Export every current URL. Take the sitemap, and separately export Search Console performance by page for the last 12 months. Search Console only retains 16 months, so this is also your only chance to keep the history.
- Record the baseline. Clicks, impressions, average position and indexed page count, with today’s date on it. Without this you cannot tell afterwards whether you lost anything.
- Note your top pages by impressions. These are the ones to check first after the move, rather than checking randomly.
- Export your backlinks, or at least the pages that have them. An old URL with external links is the one redirect you cannot afford to get wrong.
- Build the redirect map. Old URL to new URL, one to one, every row filled in. This is the deliverable the whole migration depends on.
The redirect map is where to spend your time. A spreadsheet with a row for every old URL and a named destination is worth more than any tool.
WordPress specifics
Most migration guides are platform agnostic. If you are on WordPress, a few things behave in ways worth knowing in advance.
A permalink change is a full migration. Changing Settings then Permalinks rewrites every post URL at once. It takes one click and it is not a settings tweak, so treat it with the same process as a domain move.
WordPress will not redirect for you. After a permalink change the old URLs simply 404 unless you add redirects, through a plugin or at the server. Decide which before you change the setting, not after.
Caching will lie to you. Page caches serve the response they stored earlier, so a correctly redirecting URL can still show you the old page, and a fixed page can still serve a cached error. Purge the cache fully before you verify anything, and purge it again if a result looks wrong. More migrations are declared broken because of a stale cache than because of a bad redirect.
Check your internal links in the database, not just in the menu. Old absolute URLs sit inside post content and will keep pointing at redirects until you update them.
Verifying it, properly
This is where migrations are actually won or lost, because the reports you would naturally check are the slowest things to tell you the truth.
Check the response codes yourself, immediately. Take twenty old URLs spread across sections, including your top pages by impressions, and confirm each returns a 301 to the right destination. Do this from the command line or a redirect checker rather than a browser, because a browser shows you the destination without showing you the status code or the chain.
Watch for chains. An old URL redirecting to another old URL that then redirects again is the most common defect, and it appears whenever a site has been migrated before.
Then wait before judging Search Console. Its reports reflect the last time Google crawled each URL, which can be weeks or months old, so an error list after a migration is partly describing the site as it was. Treat a spike in Not found as a prompt to check the live response, not as proof of a problem.
In the following weeks the signals worth tracking are the indexed count for new URLs rising, the Not found count falling, and impressions returning to the baseline you recorded. Judge the move on those rather than on day-three traffic.
The mistakes that cost the most
- Redirecting everything to the homepage. Google names this specifically, and it converts your entire old site into soft 404s.
- 302 instead of 301. A temporary redirect tells Google the old URL is coming back.
- Removing redirects after a few months. Google says keep them at least a year, and external links never expire.
- No baseline. Without one, every conversation afterwards is an argument about whether things got worse.
- Migrating during your busiest period. The documented fluctuation lands at the worst possible time.
- Changing design and URLs together. When something drops you will not know which change caused it. Separate them if you can.
- Forgetting the Change of Address when the domain changes.
A short sequence
- Export URLs, performance data and backlinks. Record the dated baseline.
- Build and review the one-to-one redirect map.
- Make the change, all at once for a small or medium site.
- Purge every cache completely.
- Test twenty old URLs for status code and destination, including your top pages.
- Submit the new sitemap, and file a Change of Address if the domain moved.
- Update internal links to point at the new URLs directly.
- Watch indexed count, Not found count and impressions against the baseline for a month.
Afterwards, run the whole site through a content audit once things settle. A migration is the moment pages quietly lose their internal links, so it is also worth re-checking for orphan pages.
Frequently asked questions
What counts as a site migration?
Any change that alters the addresses your pages live at, the platform serving them, or both. That includes a new domain, moving from HTTP to HTTPS, changing platform, a redesign that changes URLs, and on WordPress a permalink structure change. The last one is often underestimated, because it rewrites every post URL from a single settings screen.
How long does it take to recover from a site migration?
Google says to expect temporary fluctuation in rankings during a move, and that for medium-sized sites it can take a few weeks or more before the new URLs are showing, with larger sites taking longer. A dip in the first weeks is the documented normal case. What matters is whether it recovers on that timescale, measured against the baseline you recorded beforehand.
Should I use 301 or 302 redirects for a migration?
301, or 308, because both are permanent. Google recommends server-side permanent redirects where technically possible and treats client-side redirects as a last resort. A 302 tells Google the old URL is coming back, which is not what you mean during a migration.
How long should I keep the redirects?
Google advises keeping them as long as possible and generally at least a year, so signals transfer to the new URLs. There is a practical case for keeping them indefinitely, since external links never expire. Google also notes that redirects slow visits down, so update your internal links and any high-traffic external links to point at the new URLs directly.
Can I redirect all old pages to my new homepage?
No. Google says not to redirect many old URLs to one irrelevant destination, and states that doing so can be treated as a soft 404. Each old URL should go directly to its closest genuine equivalent, and where there is no equivalent it is better to let the URL return a proper 404.
Why does my migrated site still show errors in Search Console?
Because those reports reflect the last time Google crawled each URL, which can be weeks or months earlier, so the list is partly describing your site as it was before the move. Check the live response for a sample of the reported URLs before assuming anything is broken. Caching is the other common culprit, since a page cache can keep serving a stored response long after the underlying redirect is correct.