How to Migrate a Website Without Losing SEO

A website migration is any change that moves pages to new URLs, such as a new domain, a switch to https or a new URL structure. To migrate without losing SEO, you map every old URL to its new equivalent, redirect each one permanently, update everything that points at the old addresses and watch closely until search engines catch up. This guide covers each step in order and is part of our website design best practices guide.

You'll need Search Console access for both the old and new sites, a crawler that can export URLs and status codes, and access to your server or platform's redirect settings. Rankings can still move for a while during any big change. The aim is to keep that short and avoid lasting losses.

What counts as a site migration

Google's site move guide covers three kinds of change that alter URLs: moving from http to https, changing domain name or merging domains, and changing URL paths, such as from page.php?id=1 to /widget. Each one needs the full process in this guide.

Some changes don't touch URLs at all, such as moving to a new host or CDN. Google treats those separately, and they need less work: keep the same URLs and content, and watch for crawl errors while the change settles.

A redesign or a new CMS is often both. If any URL changes during the rebuild, it's a migration, even if the domain stays the same. Run our website redesign checklist alongside this guide.

What a redirect map looks like

The redirect map is the core document of any migration. It lists every old URL, where it goes on the new site and what should happen to it. A spreadsheet works for most sites. Here's a hypothetical example:

Every row gets the closest relevant new page. Don't send old URLs in bulk to the home page: Google says that can confuse users and be treated as a soft 404.

Steps

1. 01
   Take a baseline before anything changes.

   Export Search Console performance data for at least the last year, with queries and pages. Export analytics for landing pages and conversions. Save the current sitemap and a full crawl with status codes. You'll compare against these after launch, and you can't recreate them once the old site is gone.

2. 02
   List every old URL, including files.

   Start with the URLs that matter most: those in your sitemaps, those with the most traffic in analytics or server logs, and those with links in Search Console's Links report. Then add everything your CMS and the crawl can list. Include images, PDFs, videos, CSS and JavaScript, which Google's guide says need moving like any other content.

3. 03
   Map each old URL to its closest new page.

   Fill in the redirect map. Keep URLs unchanged where the page still exists. Where content was merged, point the old URL to the page that replaced it. Where content is gone with no equivalent, plan a 404 or 410 response instead of a redirect.

4. 04
   Build and test the new site on staging.

   Block the staging site from search with a password, robots.txt or noindex, and write down every block you add. Make sure the Search Console verification method will still work after launch. Verify both the old and new sites, including www and non-www versions.

5. 05
   Update canonicals, internal links and sitemaps.

   Give every new page a self-referencing canonical tag. Change internal links so they point straight at new URLs, not at redirects. Update hreflang annotations if you have them. Generate a sitemap of the new URLs, and save a copy of the old sitemap for monitoring.

6. 06
   Pick a quiet launch window and change one thing at a time.

   Launch when your traffic is usually lower. Google advises against changing domain, CMS and design all at once, so split them if you can. For small and medium sites, Google recommends moving all URLs together. Larger sites can move one section at a time.

7. 07
   Turn on server-side permanent redirects.

   Use 301 or 308 redirects from each old URL straight to its final new URL, set in the server, hosting platform or CMS. Avoid chains. Google's crawler follows up to 10 hops, but its guide asks you to redirect directly where possible. Our 301 redirects guide covers the setup.

8. 08
   Remove staging blocks and tell Google.

   Take off every noindex rule, password and robots.txt block from your list. Submit the new sitemap in Search Console. If the domain or subdomain changed, submit a Change of Address request for each verified variant of the old site. You don't need it for an http to https move or a path change.

9. 09
   Test the redirects at scale.

   Run every old URL from your map through a script or crawler, and check that each returns one permanent redirect to the right page, then a 200. Use Search Console's URL Inspection tool for a few key pages. A short loop like this checks a list of URLs:

   bash

   while read -r url; do
     curl -s -o /dev/null -w "%{http_code} %{redirect_url} $url\n" "$url"
   done < old-urls.txt

10. 10
    Monitor, update links and keep the redirects.

    Check Search Console every few days for errors, and compare indexing of the old and new sitemaps. Update links you control: social profiles, listings, ads and email signatures. Ask sites that send you visitors to update their links. Keep the redirects for at least a year, and ideally for good.

For the files and tags involved, see our robots.txt and sitemap.xml guide and canonical tags and duplicate content.

If you'd rather have a migration planned and run for you, our in-house web team builds new sites with SEO foundations such as metadata, structured data and sitemaps built in.

Carry accessibility across the move

Migrations tend to lose small things that matter a great deal to some visitors. Content gets copied without its alt text, video embeds lose their captions, and headings are flattened when text is pasted into a new editor. Check these as part of the content move, not afterwards.

Move text alternatives with the content. Export alt text with images, and captions and transcripts with video. WCAG's Non-text Content criterion asks for text alternatives for meaningful images, and its Captions (Prerecorded) criterion asks for captions on prerecorded video with sound.

Keep the structure. Check that headings come across as real headings in the right order, not bold text. Give every page a title that describes it, as WCAG's Page Titled criterion asks.

Avoid delayed redirects. A page that says "we've moved" and forwards visitors after a few seconds can interrupt screen reader users mid-sentence. W3C lists a timed meta refresh redirect as a failure technique, F40. Server-side redirects avoid the problem entirely.

Make the 404 page useful. Some old links will still miss. A 404 page with a clear heading, the site navigation and a search box gives everyone a way forward. WCAG's Multiple Ways criterion asks for more than one way to find pages within a site.

Troubleshooting

Old URLs return 404 after launch

Cause: some old URLs never made it into the redirect map. The usual gaps are URLs with query strings, old blog date paths, uppercase or trailing-slash variants, image and PDF files, and pages that were only linked from other sites. Redirects can also point to new URLs that don't exist, which Google's guide lists as one of the most frequent migration mistakes.

Fix: check Search Console for a rise in "Not found" errors, and look at your server logs for old URLs that still get requests. Add each one to the redirect map with its closest new page, then test again. Use pattern rules for whole sections where the structure is predictable, such as an old blog folder. Recrawl the old sitemap you saved and confirm every URL now returns a redirect.

New pages aren't being indexed

Cause: the most common reason is a staging block left in place after launch: a noindex rule, a robots.txt disallow or a password. Others include canonical tags that still point at the old URLs or at the staging domain, a sitemap still listing old addresses, or internal links that go through redirects instead of straight to the new pages.

Fix: view the source of a few live pages and check the robots meta tag and canonical. Open the live robots.txt file. Use URL Inspection on a key page to see what Google found. Once the blocks are gone, resubmit the new sitemap. Then watch the indexing report: indexed old URLs should fall over time as indexed new URLs rise.

Search traffic dropped after the move

Cause: some movement is normal while Google recrawls and processes the redirects. Google says a small to medium-sized site can take a few weeks for most pages to move. A drop that lasts longer usually has a specific cause: content that was cut or thinned during the rebuild, lost internal links, missing redirects or slower pages.

Fix: compare page-level data with your baseline to find which pages lost clicks, rather than looking at the site total. For each one, check that its old URL redirects to an equivalent page with similar content and internal links. Restore content that was removed but still earned traffic. Check Core Web Vitals on the new templates, since a redesign can change them.