The phone call always arrives about three weeks after launch, which is roughly how long it takes for a month-on-month comparison to look alarming. The new site is better in every way anybody can see. Traffic is down forty per cent.
It is almost never the design. It is that the old site had URLs, those URLs had rankings and links pointing at them, and somewhere in the rebuild a few hundred of them stopped resolving to anything. Google is not punishing the redesign. It is responding to a site that threw away its addresses.
Migrations are one of the few pieces of SEO work where the difference between doing it properly and doing it carelessly is enormous, immediate and measurable. They are also mostly a development job rather than a marketing one, which is why they get handed to whoever is building the site and treated as an afterthought.
Make the list before you delete anything
The single most important step happens before the new site exists, and it cannot be done afterwards. You need a complete inventory of every URL the old site serves.
Not the URLs in the navigation. Every URL. Old campaign landing pages, PDFs, category pages nobody links to any more, the blog post from 2019 that quietly earns a third of your organic traffic. Pull them from the sitemap, from a crawl of the live site, from your analytics, and from Search Console's page report, then combine them. Each source misses something different: a crawl misses orphaned pages, analytics misses pages with no traffic but real backlinks, and the sitemap misses anything that was never in it.
Once the old site is switched off, this list is unobtainable. That is what makes it urgent rather than merely important.
Map every one of them to a destination
Now go through the list and decide, for each URL, where it should go. There are only three honest answers:
- It has an equivalent on the new site. Redirect it there with a 301. This is most of them.
- It has no equivalent and never will. Let it 404 — properly, with a real 404 status.
- It has no equivalent but the topic still matters. Redirect to the closest genuinely relevant page, not the homepage.
That last distinction is where most migrations go wrong. Bulk-redirecting everything to the homepage looks tidy and preserves nothing. Google treats a redirect to an irrelevant page as a soft 404, so you get the ranking loss of a dead page plus a confusing signal about your homepage. A relevant redirect passes something. A lazy one passes nothing and costs you a page.
Redirect to the final destination directly. Chains — old URL to intermediate to new — lose a little at each hop and break entirely if one link in the chain is later removed. If you are migrating for the second time, flatten the first migration's redirects into the new map rather than stacking them.
The failure that returns 200
Here is the one I want to warn about specifically, because I found it on my own site and it is invisible from the browser.
This site used to run WordPress. When I replaced it with static pages, the rewrite rules from that install were still in the .htaccess file, and they did what WordPress rules do: any URL that did not match a file on disk was handed to index.php. WordPress looked at it, found nothing, and rendered a page.
The result was that every misspelled URL on the domain returned a 200 status with a page of content. Not a 404. A successful response. From a crawler's point of view I had an infinite number of valid pages, all of them duplicates, none of them intentional.
You cannot see this in a browser, because the browser shows you a page that looks vaguely like a not-found page and you move on. You can only see it by checking the status code. It took one command to find and one line to fix, and it had been true for months.
The general lesson: after a migration, request a URL you know does not exist and check the actual status code, not what the page looks like. curl -I and read the first line. A 404 should be a 404. This is the same family of problem as a site returning 200 while serving nothing — a server confidently reporting success for something that failed.
Decide the small things once, and be consistent
Migrations are a good moment to settle the URL details that are annoying to change later, because you are already redirecting everything.
Pick one canonical form for each of these and enforce it with redirects: https not http; one of www or bare domain; trailing slash or no trailing slash, consistently; lowercase paths. Each of these can otherwise serve the same content at two addresses, and while canonical tags will usually sort it out, they are a hint rather than an instruction. A redirect is not a hint.
Keep the URL structure descriptive and stable. The best argument for a slug like /blog/website-migration/ over /p?id=482 is not that Google prefers it — it is that you will still be able to read your own redirect map in three years.
The order to do it in
- Inventory the old URLs from crawl, sitemap, analytics and Search Console. Save it somewhere permanent.
- Record a baseline: rankings, impressions, clicks and top landing pages for the four weeks before launch. Without this you cannot tell a migration problem from a seasonal dip, and you will spend a fortnight arguing about which it is.
- Build the redirect map and have somebody who knows the content check the destinations, not just that the rules parse.
- Test the map against staging before launch. Every old URL, one request each, expecting a 301 to a 200. This is a loop, not an afternoon of clicking.
- Launch, then immediately crawl the new site from the old URL list.
- Submit the new sitemap and, if the domain changed, use the change of address tool.
- Watch the 404 log for a fortnight. Real visitors and real crawlers will find the URLs you forgot. This is where the last five per cent gets recovered.
Step seven is the one people skip, and it is the cheapest. A 404 log after a migration is not a list of errors, it is a list of pages somebody still wants.
What to expect afterwards
Even a well-run migration usually dips. Google has to recrawl everything, follow every redirect, and re-establish which page is which. A few weeks of movement is normal and not a reason to start changing things, which is the main way a small dip becomes a large one.
What is not normal is a sustained fall after a month, or a fall concentrated in specific pages rather than spread across the site. Concentrated losses almost always trace back to specific URLs that lost their redirect, which is why the inventory matters so much: with the list you can diff old rankings against new destinations and find the gap in an hour. Without it you are guessing.
If a site was already struggling to be indexed before the move, a migration will not fix that and may expose it. The underlying reasons are the ones I set out in why most Nepali business websites are invisible on Google, and the recurring technical faults are in technical SEO mistakes that hurt growing websites.
Migrations reward preparation more than skill. Almost all of the value is in the list you make before you turn the old site off — and that is an hour's work that becomes impossible the moment you skip it. If you are planning a move and want the map checked before you launch rather than after, that is the kind of work I do.