Website Migration Without Losing SEO: A 6-Step Relaunch Plan

A website migration without losing SEO comes down to one rule: every old URL that has traffic or links must lead, in a single permanent redirect, to the page that replaced it. Do that, keep the content that already ranks and record your numbers before launch, and launch day becomes a planned, measurable event rather than a gamble.

I'm a freelance developer who builds websites, so I have an obvious interest in you hiring help. Most of this guide works with a spreadsheet and Google Search Console, though, and I'll tell you when you don't need a developer at all.

The short answer: how risky is your migration?

The risk has less to do with the new look and more to do with how much changes under the hood. Here's how I'd rate the most common scenarios, including one that's typical for European companies.

My rule of thumb is to change as few things at once as you can. If you switch domain, platform and content on the same day and traffic drops, finding the cause is close to impossible. If you're still deciding whether you need a new website or something bigger with logins and a database, start with my guide to building your own platform.

The rest of this guide is six steps. The first four happen before launch, and they decide how the migration goes.

Steps 1 and 2: map your content before design starts

Content mapping is the dullest part of a relaunch and the part that protects your traffic most. Do it before the design is signed off, so the designer knows which pages and which copy need room.

Step 1: export every URL you have today

You can't redirect pages you don't know exist. Your sitemap rarely shows everything, so build the list from several sources:

1. Your XML sitemap, usually at yourdomain.com/sitemap.xml.
2. The Performance report in Google Search Console, filtered by page. Pick the longest date range available so seasonal pages make the list.
3. Your analytics, exporting every landing page that received visits in the past year.
4. A full crawl of the site. A crawler is a program that follows links through your site the way Google does. Screaming Frog's SEO Spider is free up to 500 URLs, which covers most small business sites, and a paid license currently costs €245 a year.
5. The Links report in Search Console, which shows the pages other sites link to. Those URLs are expensive to lose.

Merge everything into one spreadsheet and remove duplicates. Pay special attention to pages that aren't in the menu: old campaign landing pages, PDFs such as price lists or spec sheets, images that get traffic from image search, and blog posts from years ago that still pull visits. Those are the ones that usually get forgotten.

Running a multilingual site? Export each language version separately. A page in German, French and Danish is three URLs with three sets of rankings, not one.

If your site has thousands of URLs, like an online store with product variants and filters, don't map each one by hand. Write rules for groups of pages and spend the manual effort on the pages that bring the most traffic.

Step 2: decide what happens to each page

Now every row needs a decision. Add columns for clicks over the past year, number of external links, decision and new URL. There are four options:

1. Keep: the page moves over, ideally at the same address. The same address is always the safest choice.
2. Merge: several thin pages on the same topic become one strong page, and the old URLs redirect to it.
3. Rewrite: the page moves over with updated content. Be careful with pages that already rank well.
4. Remove: the page has no traffic, no links and no sensible replacement. It should return a 404 or 410 status. Google's own site move guide says plainly not to redirect lots of old URLs to one irrelevant destination such as the homepage.

A slice of a redirect map might look like this:

Step 3: build the redirect map and test it before launch

A redirect sends both visitors and Google from the old address to the new one. Google recommends server-side permanent redirects, usually with a 301 or 308 status code, because they signal that the new URL has replaced the old one. Four rules prevent most problems:

1. One redirect per old URL, straight to the final destination. If your current site already has old redirects, update them so they don't stack into chains. Google's crawlers follow up to 10 redirect hops, but every hop slows the page down for visitors and adds another place for things to break.
2. Point to the closest match, not the homepage. Sending an old article about gutter maintenance to your homepage helps neither the reader nor your rankings.
3. Cover the variants: www and non-www, http and https, trailing slash or not, and uppercase letters. They're easy to miss because you never type URLs that way yourself.
4. Update internal links. Navigation, buttons and in-text links should point directly to the new URLs rather than through a redirect.

For multilingual sites, add a fifth rule: each language version redirects to its own counterpart, never everything to the English page, and your hreflang tags (which tell Google which language version to show to whom) must reference the new URLs.

Where redirects live depends on your stack: in the server configuration, in the application code or in a CMS plugin. I prefer code or server config under version control, so the rules don't vanish the next time someone swaps a plugin or platform. On a framework like Laravel or Next.js, redirect rules are a normal part of the project. If you're moving off WordPress, read my honest comparison of WordPress and a custom-built website before you lock in the new URL structure.

Finally, test the full list against staging (your test environment). Run every old URL through and check two things: the response is a 301 or 308, and the destination returns a 200. Most crawlers accept a URL list and do this in minutes, so you find the errors on staging rather than in Search Console three weeks after launch.

Step 4: record your baseline before launch

Without pre-launch numbers you can't tell whether a dip comes from the migration, the season or something else entirely. Save these exports somewhere that won't disappear with the old site:

1. Clicks and impressions per page and per query from Search Console, for the last 3 and 12 months.
2. The number of indexed pages in Search Console.
3. Organic landing pages in your analytics, with the actions that matter to you: form submissions, calls and purchases.
4. Average positions for the 20-50 queries that matter most to your business, per market if you sell in several countries.
5. Speed for your key page types (homepage, service page, blog post), measured with PageSpeed Insights.

Write the launch date in the same document. Three months from now, nobody will remember whether it was the 4th or the 14th.

Steps 5 and 6: launch day and the first 12 weeks

The launch itself takes a few hours if the groundwork is done. Monitoring takes three months, and that's where you catch whatever slipped through.

Step 5: launch day, in order

Launch on a regular weekday morning, not Friday afternoon. That leaves time to fix problems while everyone is at work. On the day itself, work through this sequence:

1. Switch on the redirects the moment the new site goes live.
2. Remove the staging blocks: noindex tags, password protection and a robots.txt that disallows everything. It's a classic mistake, and it can wipe the whole site from Google.
3. Run the list of old URLs again, this time against the live site.
4. Crawl the new site and check for 404s, links pointing to staging, and canonical tags (which tell Google the preferred URL) pointing to the wrong place.
5. Submit the new sitemap in Search Console.
6. If the domain changes, use the Change of Address tool in Search Console. You need to own both the old and the new property with the same Google account.
7. Test forms, phone links, checkout and tracking by completing an inquiry yourself.

I keep the complete pre-launch list in my website launch checklist with 40 items. If you're changing hosting at the same time, keep DNS and the old server under control with this plan to migrate hosting without downtime.

Step 6: monitor for the first 12 weeks

A temporary dip is normal. Google's site move guide notes that for medium-sized sites it can take a few weeks or more before the new URLs replace the old ones in results, and longer for large sites.

In week one, check Search Console daily for new 404s and pages that can't be indexed, and add missing redirects straight away. From week 2 to 12, compare clicks per page against your baseline every week. Look at your most important pages individually, not just the total.

Here's how I tell the two apart: if traffic dips evenly across the whole site and recovers gradually, Google is still processing the move. If a handful of important pages drop and stay down, there's usually a specific cause. Many of those causes are technical details that should have been built in from day one, and I've collected them in 12 technical SEO items for developers.

Leave your redirects in place. Google recommends keeping them for at least a year, and longer is better. If you changed domain, keep the old one registered in your name too, so nobody else can pick it up along with the links pointing to it.

Traffic dropped after launch? Symptoms and fixes

Use this table as the starting point for troubleshooting. The first column is what you see, the rest is where to look.

When you don't need a developer for this

Plenty of relaunches don't need a developer for the migration itself. You can handle it yourself when:

• Your site has fewer than 30 pages and you keep the same URLs. Steps 4 and 5 are what matter most.
• You're redesigning within the same system, such as a new theme in WordPress, Wix or Squarespace. URLs usually stay put, so the job is mostly protecting your content.
• An agency or contractor is building the new site. Then the redirect plan is their job. Ask how they handle it in the first meeting, and treat a vague answer as a red flag.

Paying for help makes sense when you have hundreds of URLs, several languages or country domains, a platform or domain change, an online store, or a site that drives a large share of your leads, so a few months of lost traffic costs real money.

Next steps: start the spreadsheet now

Use this checklist as the backbone of your plan, and run through it again the day before launch.

Start step 1 today, even if the new site is six months away. Your URL list and baseline are as useful to whoever designs the new site as to whoever migrates it. If you need the new site built, see how I work on websites built to be found. I'm an EU-based developer working in CET, you deal directly with me as the person writing the code, and you own the code from day one.

Frequently asked questions

Should I change domains at the same time as the redesign?+

Only if you have a strong reason. A new domain adds uncertainty on top of a new site, and if traffic drops you can't tell which change caused it. If it can wait, launch the new site on your current domain first and move domains a few months later, once the numbers are stable. If both must happen together, domain-wide redirects and the Change of Address tool are essential.

Should I merge my country domains into one .com?+

It can make sense, but treat it as its own project. One domain with language or country folders concentrates your links and is simpler to maintain, while separate country domains give a clear local signal and keep markets independent. If you merge, redirect each country domain page by page to its matching folder, set up hreflang properly and monitor each market separately afterwards.

Will I lose my backlinks when I migrate?+

No, not if the old URLs redirect to the right new pages. A permanent redirect tells Google the new page has replaced the old one. Without a redirect, the link lands on an error page and you effectively get nothing from it. For a handful of very valuable links, you can ask the linking sites to update to the new URL, but it isn't required.

Can I keep my old URLs instead of setting up redirects?+

Yes, and it's the safest option if your current structure is sensible. Most modern platforms and frameworks can give pages exactly the URLs you want, including endings like .html. It just has to be decided before the new site is built. Redirects are only needed for the pages whose address actually changes.