How to Maintain SEO During a Website Migration

What Is a Website Migration (and Why Should You Care)?

A website migration is any significant change to a website's URL structure, domain name, hosting platform, or underlying technology, such as moving from WordPress to Next.js or restructuring page paths. If not handled correctly, it causes search engines to lose track of your pages, resulting in ranking losses that can take 6 to 12 months to recover from.

If you have been running a business website for more than a year, you have likely accumulated something incredibly valuable without realizing it: organic search authority. This is the trust that Google has built in your domain over time, based on the content you have published, the backlinks other sites have pointed to your pages, and the click behavior of real users finding you in search results.

A website redesign, even a beautiful one, is invisible to this process. When your developer rebuilds the site and changes the URL structure, Google does not automatically follow along. It crawls your old URLs, hits blank error pages, and begins quietly de-indexing everything you have earned.

Think of it like this: imagine you moved your physical shop to a new address but forgot to update Google Maps, your business cards, or any signage. Customers would walk up to an empty building and assume you closed. A website migration without 301 redirects is the digital version of exactly that.

Why Do Websites Lose Traffic After a Redesign?

Websites lose organic traffic after a redesign primarily because legacy URLs are changed or deleted without implementing 301 server redirects. When search engine bots crawl the old links and encounter a 404 Error, they immediately de-index those pages and strip the domain of its accumulated backlink authority. In severe cases, 60 to 80 percent of organic traffic can disappear within two weeks of a botched launch.

You just spent $25,000 on a gorgeous, high-performance new website. It launches, the executive team celebrates, and then the phone stops ringing. You check your analytics dashboard and see that your organic traffic has plummeted by 80%.

This is not a hypothetical. It is one of the most common and expensive mistakes in digital business. It happens frequently when designers and developers focus entirely on aesthetics and front-end code while completely ignoring the underlying technical SEO infrastructure that took years to build.

The irony is that none of this has anything to do with how the website looks. A technically flawless migration can be invisible to the end user. A botched one, however, is immediately felt in revenue.

The Architecture of a Safe SEO Migration

Understanding this process starts with one concept: Google's index is a massive ledger of exact URLs. Each URL in the index carries a score, a measure of how relevant, trustworthy, and authoritative that specific page is. When you build a new website and change your URL structure, those scores do not automatically transfer. You must explicitly instruct Google to move them.

The most common URL changes that trigger traffic loss:

• /our-services.php becomes /services
• /blog/category/marketing/post-title becomes /insights/post-title
• A domain change from oldbrand.com to newbrand.com
• Moving from HTTP to HTTPS (even this requires careful redirect management)
• Removing pages entirely (old products, service areas, old team members)

If you are also switching platforms during the rebuild, for example moving from WordPress to a headless Next.js architecture, the redirect complexity increases but the fundamentals remain the same.

Step 1: The Pre-Launch 301 Redirect Map

A 301 redirect is a server-level HTTP instruction that tells search engines a page has permanently moved to a new URL, transferring approximately 90 to 99 percent of the original page's ranking authority to the new destination. It is the single most important technical action in any website migration.

Before writing a single line of code for your new website, your engineering team must create a Redirect Map. This is a comprehensive spreadsheet that maps every single legacy URL to its new destination.

Here is how to build one correctly:

• Crawl the Legacy Site: Use enterprise tools like Screaming Frog SEO Spider or Ahrefs Site Audit to extract every single URL currently indexed on your old website, including images, PDFs, and any legacy blog posts. Do not rely on memory or a sitemap alone; crawlers find URLs that even your own team has forgotten.
• Pull Your Google Search Console Data: Download the full list of URLs that Google has indexed from Search Console > Index > Pages. This is your official list of what Google cares about. If the report is unfamiliar, our walkthrough on how to read Google Search Console explains exactly where to find it.
• Map Every Row: For each old URL, assign the exact new destination URL. If a page is being discontinued and has no equivalent, map it to the closest relevant category page rather than the homepage.
• Implement Server-Level 301s: Work with your developer to configure these in your next.config.js file (if using Next.js), your .htaccess file (Apache), or your nginx.conf (Nginx). Avoid JavaScript-based redirects, as search engines prefer server-level responses.

Step 2: Staging Environment Isolation

A staging environment is a private copy of your new website hosted at a temporary URL (e.g., staging.yourdomain.com) where developers build and test before going live. If search engines crawl this staging server, they will index it as a separate website, treating your final launch as duplicate content and actively harming rankings.

While your new site is being built on a staging server, you must block it from search engines completely. The correct method is to apply an X-Robots-Tag: noindex HTTP header at the server level. This is more reliable than a robots.txt disallow rule, which can be ignored by some bots.

Verify the block is working by using the URL Inspection tool in Google Search Console to test your staging URLs before launch. You want to see a "URL is not on Google" result.

Step 3: The Post-Launch Technical Audit

Never launch a major website on a Friday afternoon. When you push the new site live, you must have an engineering team standing by to immediately crawl the live domain and verify everything is functioning correctly.

The post-launch checklist:

• Verify all 301 redirects fire correctly using a bulk redirect checker. Screaming Frog's List Crawl mode is excellent for this.
• Audit for "redirect chains," where Page A redirects to Page B, which then redirects to Page C. Each hop bleeds ranking authority. All chains must be collapsed to a single direct jump.
• Confirm the noindex tags are removed from the production environment. It is shockingly common for staging noindex rules to survive the launch accidentally.
• Submit the new XML sitemap directly to Google Search Console to trigger an immediate re-crawl of the new architecture. Go to Search Console > Sitemaps and submit the new URL.
• Monitor Google Search Console's Coverage report daily for the first two weeks. Any spike in 404 errors requires immediate investigation.

Common Migration Mistakes That Destroy Rankings

Even well-intentioned teams make these errors. Knowing them in advance is your best protection.

Mistake 1: Redirecting everything to the homepage. This is called a "Soft 404." Google recognizes it as unhelpful user experience and strips ranking authority anyway. Always map old URLs to their topically equivalent new page.

Mistake 2: Forgetting canonical tags. If your new website has slight URL variations (with and without trailing slashes, or HTTP and HTTPS versions of the same page), you need a canonical tag on every page pointing to the preferred version. Duplicate content without canonicals can split your ranking authority.

Mistake 3: Changing content alongside URL structure. If you are rewriting all your page copy at the same time as restructuring your URLs, Google has no clear signal about what the new page is about. Where possible, migrate the URL structure first, then improve content in a second phase.

Mistake 4: Ignoring internal links. After a migration, update all internal links on the new site to point directly to the new URLs rather than through the redirect chain. Internal links pointing through redirects are slower and dilute SEO value.

Post-Launch: The 90-Day Monitoring Plan

A migration is not complete on launch day. Organic rankings fluctuate for 8 to 12 weeks after any major migration as Google re-processes your entire site architecture. Here is what to track:

A fluctuation of 5 to 10 percent in organic traffic during the first 3 to 4 weeks is normal as Google re-crawls and re-ranks the new structure. Any sudden drop of 20 percent or more is a red flag requiring immediate engineering investigation.

Frequently Asked Questions