SEO migration: how to replace your website without losing rankings

Upgrading or replacing your website doesn't have to cost you rankings. A structured SEO migration, with a full map of every old URL to its new one, page-to-page 301 redirects, preservation of your strong content and systematic checks before and after launch, is designed to keep the organic traffic you've spent years building. In this guide we'll break the process down into five practical stages, from the first inventory to monitoring in the weeks after launch, including the mistakes worth preventing in advance, so that your investment in organic SEO doesn't reset to zero on launch day.

Why a new site wipes out rankings when there's no structured process

Google doesn't rank a "site" as a single unit; it ranks specific URLs. Every page on your old site has built up assets over the years: inbound links, click history, stable indexing and semantic context with the rest of the site's pages. The moment the new site goes live with a different URL structure and no one has set up redirects, all those assets suddenly point to 404 pages. As far as Google is concerned, the pages that ranked simply disappeared, and the new pages start building trust almost from scratch.

The damage doesn't come only from broken URLs. Swapping templates, deleting "old" content that the designer thought was irrelevant, changing headings in passing and an entirely new internal linking setup also change the signals Google reads from the site. A sharp drop after launch doesn't have to come from the new design itself. Three common causes you can prevent in advance are missing redirects, strong content that was deleted or cut short, and settings such as a robots.txt file or noindex tags that were carried over by mistake from the development environment to the live site.

And the good news: when the process is managed correctly, a migration is also a real opportunity. You can fix a problematic site structure, improve speed, consolidate pages that compete with each other and start out with a stronger foundation than the one you had before.

Stage 1: A full inventory and URL mapping

Before you touch the design or the code, build a complete picture of the existing site. URL mapping is the foundation for all the other stages, and you can't map what you don't know exists. Collect URLs from four sources in parallel:

• A full crawl of the site with a tool like Screaming Frog, which finds every page that can be reached through internal links.
• Google Search Console: every page that got impressions or clicks in the last 12 to 16 months, including pages that are no longer linked internally.
• Google Analytics: landing pages that bring traffic from every channel, not just from organic search.
• Link tools like Ahrefs or Semrush: every page that gets external inbound links, even if it's old and forgotten.

Also watch for URLs with parameters, pagination pages and old versions that live only in Google's memory. They won't always show up in a crawl, but they will show up in the Search Console reports, so you have to work with both sources together.

Merge everything into one table and remove duplicates. Now build the map itself: next to every old URL, write the most suitable new URL, page for page. An old service page is redirected to the matching service page, an article to its updated version, a category to the new category. When there's no real equivalent, choose the closest page in terms of topic and search intent, not the home page by default.

It's also worth prioritizing: in the table, mark your money pages, the pages with the most organic traffic and the pages with inbound links. These are the pages you check first after launch, and they're where any mistake costs the most.

Stage 2: 301 redirects and the rules you must not break

A 301 redirect tells Google the page has moved permanently, and it passes most of the accumulated authority on to the new URL. It's the central mechanism that preserves rankings in a migration, so the rules here are strict:

• 301, not 302. A 302 redirect signals a temporary move and doesn't pass along all the signals. In a permanent migration, always use 301 or 308.
• Page to page, not everything to the home page. A blanket redirect of the whole old site to the home page is treated by Google as a Soft 404 error, and the relevance of every inner page is lost.
• No chains. An old URL should reach the final URL in a single hop. If there are historical redirects from earlier versions of the site, update them too so they point directly to the new destination.
• No loops. Check that no redirect eventually leads back to the URL it started from.
• Full consistency of protocol and version: https only, with or without www, with or without a trailing slash. One canonical version of every page.
• For the long term. Keep the redirects active for at least a year, and preferably permanently. External links will keep pointing to the old URLs for years.

In terms of implementation, prefer redirects at the server or CDN level: a _redirects file on Netlify, an .htaccess file on Apache servers or rewrite rules on Nginx servers. Redirects done on the client side, in JavaScript or with a meta refresh tag, are less reliable and slower, so keep them as a last resort only.

If the migration also includes a domain move, add the new domain to Search Console and use the Change of Address tool, which helps Google connect the two domains and speed up the transfer of signals.

Stage 3: Preserving your strong content

A new design makes it tempting to delete. "The new site is cleaner." "The old blog doesn't fit the new look." "Let's shorten the copy." This is exactly where rankings quietly disappear, with no 404 error to give the problem away. A page that keeps existing but has lost most of its content also loses the reason it ranked in the first place.

Before you decide what goes onto the new site, identify the strong content: pages that rank for important keywords, pages that attract inbound links, and pages that actually convert. Preserve these pages almost exactly as they are:

• Keep the title tag and the H1, or change them carefully and deliberately, not as a side effect of a new template.
• Keep the structure of the internal headings and the depth of the content. Aggressive shortening "for the sake of the design" is one of the most common reasons for drops after launch.
• Don't merge pages without checking. Combining two overlapping articles can actually make them stronger, but only when the destination page truly answers both search intents and gets a 301 redirect from the page being closed.
• Update every internal link on the new site so it points directly to the new URLs, without going through redirects.

Content is the cumulative asset of SEO, and as we covered in more depth in our complete guide to organic SEO, Google rewards depth, consistency and credibility built over time. A good migration carries that asset over in full, and upgrades it only where there's a solid reason to.

Stage 4: Pre-launch checks in a staging environment

Test the new site in a closed testing environment, not live. The staging environment must be blocked from indexing, preferably with a password and not just a noindex tag, but open to your crawling tools. This is the checklist we go through before every launch:

• A full crawl of the new site to confirm there are no broken internal links, orphan pages or redirect loops.
• Comparing the title, meta description and H1 with the old site, at least on the prioritized pages from the table.
• Correct canonical tags that point to the final new URLs, not to staging URLs.
• Running the redirect file: run the whole mapping table against the staging environment and confirm that every row returns a 301 to the right destination in a single hop.
• A new sitemap that includes only new, valid URLs, and a robots.txt that doesn't block important areas by mistake.
• Structured data (schema) that carried over in full, including FAQs, articles and business details.
• Images and files: if the image paths change, set up redirects for them too. Traffic from image search is an asset that's easy to forget.
• Performance and mobile: make sure the new site isn't slower than the old one and that the mobile experience is complete and working.

Finally, record a baseline: export the impressions, clicks and main keywords of recent months from Search Console, and save a snapshot of your important rankings. Without a baseline, you won't know after launch whether you dropped, by how much and in which area of the site.

Stage 5: Launch day and the weeks after

On launch day itself, go through a short, critical list:

• Remove the indexing block and the password, and check manually that noindex tags haven't "leaked" from the development environment to the live pages.
• Make sure robots.txt is the production version and not the staging block version.
• Submit the new sitemap in Search Console, and temporarily keep the old one as well, so Google reaches the old URLs quickly and discovers the redirects.
• Go through the most important pages manually: they load properly, redirect correctly and look right on mobile.

In the weeks after, monitor daily at first and then weekly: the coverage report in Search Console, where an unusual rise in 404 errors is an immediate red flag; the Performance report against the baseline you recorded; and Google's actual crawl rate. Every 404 error found on a page with traffic or links gets a redirect the same day.

It's also important to manage expectations: even in a precise migration, it's normal to see fluctuations in rankings and traffic while Google reprocesses the site. Even when the mapping and the redirects were done right, that reprocessing takes time, and the pace depends on the size of the site and the scope of the change. Real red flags are a sharp drop that persists and deepens, money pages that disappear from the index, or main keywords that plunged and aren't recovering. In cases like these, go back to the mapping table and look for where the chain broke: you'll almost always find a missing redirect, content that was cut or a wrong tag.

Frequently asked questions

How long does it take for rankings to stabilize after a site migration?

There's no fixed timeline; it depends on the size of the site and the scope of the change. A structured migration with full mapping and redirects stabilizes faster than one done without planning, and large sites or a full domain move can take longer. The key is close monitoring against a baseline and quickly fixing every problem that comes up.

Do I have to change my URLs when I redesign my website?

No, and if you can keep the existing URL structure, that's the safest option, because it removes most of the risks of a migration. Change URLs only when there's a real reason, such as an illogical structure or a move to another platform, and then pair every change with a precise 301 redirect.

How long should I keep 301 redirects in place?

At least a year, and in practice it's recommended to keep them permanently. External links, bookmarks and mentions will keep pointing to the old URLs for years, and as long as the redirect is live, their value keeps flowing to the new site.

Is there an SEO risk in a redesign that keeps the same URLs?

Yes, a smaller one, but it's definitely there. A new template can change headings, delete text, break internal links or slow the site down, and each of these affects rankings. Run the same staging checks: comparing tags, crawling links and checking performance before launch.

What to do next

Planning to upgrade or replace your website and want to get through it without losing what you've built? VeloLinx's organic SEO service guides migrations end to end: URL mapping, redirects, content preservation and close monitoring after launch, until the new site is stable and keeps moving forward. Talk to us before the new site goes live, not after.