Migrating a website without losing search rankings

Owners are told migrations are risky and left there. It sounds like weather. It is not. It is a checklist, and the failures are the same three or four every time.

The reason it matters is that search visibility accumulates. A page that has ranked for four years has history attached to its address. Break the address and you throw the history away, then spend a year earning it back.

Google publishes the procedure. Its Search Central documentation on site moves with URL changes describes exactly this work: map old URLs to new ones, use permanent redirects, keep the old site's redirects in place for a long period, and move in stages when the site is large. There is no proprietary technique here that an agency has and you do not.

What actually causes ranking loss in a migration?

Four things, in order of frequency.

Missing redirects. The old site had eighty addresses. The new one has twelve. The other sixty-eight now return a not-found error, including the ones that were bringing you customers.

Redirecting everything to the homepage. This is the shortcut a lot of developers take and it is nearly as bad as doing nothing. A visitor searching for water heater repair lands on your homepage, gets nothing they asked for, and leaves. Google's own guidance is to redirect each old URL to the page that most closely corresponds to it, precisely because a blanket redirect to the root is not a match.

Content that got shorter. Redesigns delete text. A page that ranked because it answered a question in detail stops ranking when it becomes a headline and a photo. The address survived and the substance did not.

Changing too many variables at once. New domain, new platform, new structure, new copy, all in one weekend. When rankings drop you cannot tell which decision caused it. Move one thing at a time when you can.

The redirect map is not a technical detail. It is the migration.

How do I build the redirect map?

Start before the design work, not the week of launch.

Export every address on the current site. A crawler will do it, or your platform will export a sitemap. You want the complete list, including old pages you forgot existed.

Then add two columns of data. Traffic over the last twelve months, and whether the page produced any inquiries. Now you know which pages are actually assets and which are debris.

Then map each old address to a new one. Same subject to same subject. If the new site genuinely has no equivalent, map it to the closest parent, not the homepage. Pages that were dead anyway can be left to expire, deliberately, with that decision written down.

Then decide what carries over. For your top pages, keep the page title and keep the substance. You can redesign the presentation freely. Changing the words that earned the ranking is a separate decision and should be made on purpose.

What does the map look like in numbers?

What should happen on launch day?

A specific sequence, and someone has to be watching.

Launch, then immediately test the sample above by hand.

Check that the new site is actually allowed to be indexed. Staging sites are usually blocked from search, and shipping that block to production is one of the most common and most damaging launch mistakes. It is invisible to visitors and catastrophic for search.

Submit the new sitemap in Search Console. Google's site move documentation specifically recommends using the Change of Address tool when the domain itself is changing, and leaving the old URLs redirecting for a long period rather than switching them off after a few weeks.

Verify that tracking fires. Test the contact form from a phone and confirm the message arrives. Confirm conversion events register.

Take a speed reading against Google's published thresholds while you are there: Largest Contentful Paint good at 2.5 seconds or below, Interaction to Next Paint at 200 milliseconds or below, Cumulative Layout Shift at 0.1 or below, each at the 75th percentile of visits, all three needing to pass. A new site that is prettier and slower is a real outcome and you want to know in week one.

Then expect a wobble. Rankings commonly move for a few weeks after a migration and settle. Do not start reversing decisions in week two based on noise. This is also the wrong moment to start testing changes, because you have no stable baseline, and in any case A/B testing does not work at most local business traffic levels no matter how calm the site is.

What about my Google listing during a move?

Update it, and do not take the shortcut that gets profiles penalised.

Your profile describes your business to Google independently of your website, and why your Google Business Profile categories are the single strongest local signal is worth reviewing while you are already auditing everything else. Two other items are directly exposed by a migration. Whitespark's 2026 Local Search Ranking Factors report, in which 47 experts scored 187 factors, ranks HTML name, address and phone details matching the profile at 15th with 153 points, and keywords in the profile's landing page title tag at 17th with 146. A migration changes both of those on the same day.

Here is the shortcut to refuse. Pointing your profile's website field at a domain that immediately forwards somewhere else is listed among the new negative factors in that same 2026 report, alongside keyword stuffing the description and setting service areas larger than two hours of driving. Forwarding feels like a tidy way to handle a domain change during a rebrand. It is the version of the move that carries suspension risk. Put the real, final destination in the field, and let the redirects handle the old domain in the background.

Does the platform I move to change the risk?

Somewhat, and less than the sales pitch suggests.

Moving between builders, or from a builder to a custom site, is normal and safe when the map exists. The risk is not the destination platform, it is how much structure changes on the way. A move that keeps your address structure intact is low risk. A move that renames every page is high risk regardless of platform.

Where the platform choice does matter is what happens afterward: whether you can edit pages, whether it can hold the number of pages you need, and whether you own the output. The honest comparison of builders and custom builds is the right conversation to have before the migration, not during it.

One more thing worth carrying across: build the new site so every visitor can use it. Rebuilds are the cheapest moment to fix contrast, headings, tappable targets, and form labels, because you are touching every page anyway. The accessibility basics that also improve conversion cost almost nothing during a build and cost real money to retrofit.

Where does this advice break down?

Three places, and the third is the one that causes arguments.

When the old site had no traffic. Nothing accumulated, so nothing is at risk. Take the export anyway in case you are wrong, then move without ceremony.

When the ranking lived in the content, not the address. A perfect redirect map does not save a page whose substance was cut in half. If your top nine pages are being rewritten as well as moved, you are running two experiments at once and you will not be able to separate them.

When the drop was not yours. Google ships ranking updates constantly, and one landing in your launch month will be blamed on the migration by everyone in the room. The defence is the record: your redirect verification, your indexing status, your before and after speed readings. Without those, the argument is unresolvable and usually ends in reversing good decisions.

What to do this week

Export your full list of current addresses today, whether or not a migration is scheduled. Save it. This list is useful the moment anything changes, and it is much harder to reconstruct after the old site is gone.

Pull twelve months of traffic per page and run the concentration arithmetic. Mark the pages the migration exists to protect.

Confirm you have Search Console access. If you do not, set it up now, because you want history in it before the change, not after.

Then write the map, one row per address. Give it to whoever is building, and make it a launch requirement rather than a suggestion. Feedback given as a specific list gets acted on, which is the same reason using revision rounds well shortens a project rather than extending it.

Questions about a move you are planning?

Email me at eric@seod.com with your current site address and, if you have one, the staging address of the new one. I will pull your current page list, flag the pages I would refuse to lose, and tell you where the redirect map most likely has holes. It is the check I would want done before my own launch.

More on launch planning in the web design and branding library.