Migrate a Site Without Losing Your Rankings

Most of the damage done during a website migration is done quietly, by people who meant well. The new site looks better, loads faster and finally works on a phone. Three weeks later enquiries have halved, and nobody can say exactly when it started.

The cause is almost always the same. The old site had a few hundred addresses that Google knew about and people had bookmarked. The new site has different addresses. Nothing connects the two. Every one of those old addresses now returns a 404 — the HTTP status code a server sends when a page does not exist — and the ranking, the links pointing at it and the person who typed it in all hit a dead end.

This is preventable. It is also unglamorous work, mostly done in a spreadsheet before anyone touches the design.

What actually carries over

It helps to be precise about what you are trying to protect, because it is not "your rankings" as a single object.

What carries over, if you do the work:

• Links from other websites. A directory listing, a news mention, a supplier's partner page. These point at specific old addresses. If those addresses redirect properly, the value follows. If they 404, it does not.
• Google's accumulated understanding of a page. Google has decided your borewell-cleaning-services page is about borewell cleaning in your area. A redirect tells it the new address is the same thing.
• Bookmarks, old emails, WhatsApp forwards, printed material. Nobody thinks about this one. People genuinely do have your old URLs saved.

What does not carry over, no matter how careful you are:

• Content you deleted. If the old site had forty blog posts and the new one has six, the thirty-four you dropped take their traffic with them. That may be a fine trade. Make it on purpose, not by accident.
• Thin or duplicated signals. A redirect does not upgrade a weak page.
• Certainty. Google re-evaluates a migrated site rather than simply transferring a file. Movement in both directions for a few weeks is normal and not, by itself, evidence that something is broken.

Building the redirect map

A redirect map is a two-column list: every address on the old site, and the address on the new site that replaces it. That is the entire deliverable. Building it properly takes a day or two for a small site.

Step one: get a complete list of old addresses. Not from memory. Pull it from three sources and merge them — a crawl of the live old site, your XML sitemap, and Google Search Console's page indexing report, which shows what Google actually knows about. The third source matters most, because it will contain old pages you forgot existed and which still earn visits.

Step two: add traffic and links. Export the last twelve months of landing-page data from your analytics. A page that brought four hundred visits needs a thoughtful destination. A page that brought none can be handled quickly.

Step three: pick a destination for each row. The rule is closest equivalent page. The old services page goes to the new services page. The old post about GST invoicing goes to the new post about GST invoicing. Where there is no equivalent, go up one level — a discontinued product goes to its category, not to the homepage.

Here is a sample of what a map looks like in practice:

Step four: use the right code. A 301 is a permanent redirect and is what you want for almost every row. A 302 is temporary and tells search engines to keep the old address in the index, which is not what you mean. A 410 ("gone") is a deliberate statement that a page has been removed on purpose — useful for genuinely expired content, and faster for Google to act on than a 404.

What not to buy

Three things are commonly sold in this category and none of them does the job.

The blanket redirect to the homepage. A plugin that catches every 404 and sends it to the homepage. It makes your error report look clean. Google's own documentation describes redirecting large numbers of unrelated pages to a homepage as producing soft 404s — treated as errors, not as redirects. You have hidden the problem from yourself, not solved it.

"Guaranteed no ranking loss." Nobody can guarantee this, because nobody controls the index. What an honest agency can promise is a complete map, correct status codes, and a monitoring plan. Anyone promising the outcome is either naive or selling.

The migration audit delivered after launch. A redirect map built after the old site is switched off is built from guesswork, because the source of truth is gone. Insist the map exists, is reviewed and is tested on staging before cutover. If your developer cannot show it to you, the migration is not ready. Our web development work treats this as part of the build, not an add-on.

The checks to run on launch day

Set aside two hours immediately after the switch. In order:

1. robots.txt. Staging sites are usually blocked from search engines. The single most common migration disaster is that block going live. Open yoursite.com/robots.txt and confirm it does not say Disallow: /.
2. Spot-check twenty redirects. Take your top twenty old addresses by traffic. Paste each into a browser. Confirm it lands on the right new page and that the status was a 301, not a chain of three hops or a 302.
3. Check for redirect chains. Old A to old B to new C wastes crawl effort and is easy to collapse into a single hop.
4. Submit the new XML sitemap in Search Console. Leave the old sitemap accessible for a while — it helps Google find the redirects.
5. If the domain changed, use Search Console's Change of Address tool. It only applies to domain moves, not redesigns on the same domain.
6. Confirm analytics is firing on the new pages, and that conversion tracking — form submissions, calls, WhatsApp clicks — still works. Tracking usually breaks on migration because the thank-you page address changed.
7. Test the forms. Actually submit one. Check it arrives in the inbox and, if you have one, in your CRM.
8. Check HTTPS and the certificate covers both the www and non-www versions, and that one redirects to the other.

The first fortnight

Migration monitoring is mostly watching one report. In Search Console, the page indexing report will show "Not found (404)" climbing. Some rise is normal — Google is rechecking old addresses. What matters is which addresses. Export the list weekly. Any 404 that used to earn traffic is a missing row in your map. Add the redirect, and the page usually recovers.

Watch your server logs too, if you can get them. They show every request including ones from people and bots that never reach analytics, and they surface 404s faster than Search Console does.

On performance: a new site is a good moment to check Core Web Vitals, Google's published page-experience measures. The documented thresholds for a "good" rating are Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1. A redesign that looks better but ships uncompressed hero images can easily be slower than what it replaced.

Expect fluctuation. Rankings commonly wobble for a few weeks after a migration as Google recrawls and reassesses. The honest position is that nobody can tell you precisely how long settling takes — it depends on site size, crawl frequency and how much actually changed. What you can judge is whether the mechanics are correct: redirects resolving in one hop, no unexpected 404s on pages that mattered, indexing counts recovering. If those are right and traffic is still down after six to eight weeks, the problem is probably content you dropped, not plumbing.

What to do next

If a migration is planned, do one thing this week: export your page list from Search Console and your top landing pages from analytics, and put them in a spreadsheet. That is the raw material for the map, and it is the thing that becomes impossible to recover once the old site is switched off.

If you have already migrated and traffic dropped, pull the "Not found" export from Search Console and compare it against last year's landing-page report. The overlap is your repair list, and most of it is fixable with redirects you should have had.

If you would rather someone else built and tested the map, that is part of how we handle search work and ongoing technical support. Tell us what you are moving from and to and we will tell you what the risky parts are.

Questions we get asked