How to Migrate a Website Without Losing SEO

The Redesign That Cost 40%

A company I worked with launched a beautiful redesign last year. New brand, new CMS, new everything. The site looked incredible. Two weeks later, organic traffic had dropped 40%.

Nobody panicked on launch day. The site was faster, the design was better, the content was stronger. Everything that was visible had improved. But search engines don’t evaluate what’s visible. They evaluate what’s addressable.

Every URL had changed. No redirects were in place. The meta descriptions were gone. The structured data had been stripped out during the migration. The XML sitemap still pointed to the old URLs.

The site was new. But to Google, it had simply disappeared.

Why Migrations Fail

Most teams treat a website migration as a design project with a technical step at the end. Move the content over, point the domain, done.

That’s not a migration. That’s an amputation.

A website’s SEO value lives in its URLs. Every page that ranks has built authority over months or years through backlinks, user engagement signals, and indexing history. When you change a URL without telling search engines where the new one lives, you don’t transfer that authority. You abandon it.

The common mistakes are predictable: URLs change without 301 redirects. Meta titles and descriptions aren’t carried over. Schema markup is lost because the new CMS doesn’t support it. The XML sitemap isn’t updated or resubmitted. Nobody notifies Google Search Console. Internal links break because the content structure changed.

Each one of these is a small cut. Together, they bleed out your traffic.

The Systems Checklist

Migration is infrastructure work. Not design, not content, not development. Infrastructure. It requires the same discipline you’d apply to moving a physical office — you don’t just carry the furniture, you transfer the phone lines, update the address with every vendor, and make sure the mail gets forwarded.

Here’s what that looks like for a website:

Before launch: Build a complete URL map. Old URL on the left, new URL on the right. Every single page. Not just the ones you think matter — every page that has ever been indexed. Export your sitemap, crawl it, and map it. Set up 301 redirects for every entry in that map. Not 302s. Permanent 301 redirects that tell search engines this move is final.

On launch: Transfer all meta titles, descriptions, and canonical tags. Verify that structured data (Schema.org markup) is present on every page that had it before. Submit the new XML sitemap to Google Search Console and Bing Webmaster Tools. Request indexing for your most important pages. Set up monitoring for crawl errors from day one.

After launch: This is where most teams walk away. Don’t. Monitor Search Console daily for the first two weeks. Watch for 404 errors, crawl anomalies, and indexing drops. Check that your redirects are actually working — not just returning 200 status codes, but landing on the correct pages. Watch your traffic patterns. The dip is coming. The question is whether it’s a dip or a cliff.

The Timeline Nobody Tells You About

Google takes two to six months to fully re-crawl and re-index a migrated site. This is not negotiable. You cannot speed it up meaningfully. You can slow it down by making mistakes, but you cannot accelerate it beyond Google’s own crawl schedule.

This means there will be a traffic dip. Even with perfect redirects, perfect meta data, perfect schema transfer. The re-indexing process introduces uncertainty, and uncertainty means fluctuation.

With proper infrastructure, the dip is 5-15% over two to four weeks, followed by recovery to baseline or better. Without it, you’re looking at 30-60% loss that can take six months to a year to recover from — if it recovers at all.

The difference between those two outcomes is not talent. It’s discipline.

The Maintenance Period

A migration isn’t done on launch day. It’s done when the data stabilizes.

For the first 30 days, someone needs to be watching crawl errors in Search Console every day. Broken links need to be fixed within 24 hours. Redirect chains — where one redirect points to another redirect — need to be flattened. Pages that were supposed to be indexed but aren’t need to be investigated.

Between 30 and 90 days, the monitoring shifts to weekly. Traffic patterns start to normalize. You can begin comparing pre-migration and post-migration performance on a page-by-page basis. This is where you find the pages that fell through the cracks — the ones that had authority but didn’t get properly redirected.

After 90 days, you should be at or above your pre-migration traffic. If you’re not, something structural was missed.

Infrastructure, Not Decoration

The company that lost 40% of their traffic eventually recovered. It took seven months. Seven months of fixing redirects, resubmitting sitemaps, rebuilding internal links, and waiting for Google to re-evaluate what it had already written off.

If they’d treated the migration as a systems problem from the start — URL mapping, redirect infrastructure, schema transfer, monitoring plan — they would have lost 5-10% temporarily and recovered within six weeks.

Not a design project with a migration step. A migration project with a design step.

The site would have looked exactly the same either way. The difference is invisible. That’s the point.