Website Migration SEO Checklist (From Real Client Rebuilds)

Last updated October 23, 2026: added what changes for a domain move and a hosting move, how to spot and recover from a bad migration, and when to hire help.

Website migration SEO is the work that keeps your Google rankings, links and leads intact when your site moves to a new design, platform, domain or URL structure. Most of it happens before launch day, and most of it is invisible once it is done right.

We have done this on sites with a handful of pages and on a dental group’s site with more than 400 pages and 52 office locations. This guide walks through the process we use, with real examples from our client projects, including the messy parts most checklists leave out.

What is website migration SEO?

Website migration SEO is planning and checking a site move so search engines can find every important page at its new address and keep ranking it.

A “migration” covers more than a new domain. Any of these count:

• A redesign that changes page addresses, page structure or content.
• A platform change, such as a custom PHP site moving to WordPress, or a store moving themes on Shopify.
• A domain change, including moving a finished staging site onto the live domain.
• A hosting move, which can break things like email, caching and SSL even when no URL changes.

The SEO risk in all of them is the same: Google has spent years learning where your pages are and what they are about. A migration can quietly throw that away if old addresses stop working or the content Google trusted disappears. Our small business website redesign guide covers the design side of a rebuild; this post is about protecting what you have already earned in search.

How does a website migration affect your Google rankings?

Rankings usually wobble for a few weeks while Google recrawls the site. They drop for good when old pages vanish, redirects are missing or the content that ranked is gone.

Google says plainly that a move takes time to settle. In its guide to site moves with URL changes, it notes that for medium-sized websites “it can take a few weeks or more for Google to gradually start showing the new URLs instead of the old ones (and for larger sites, even longer).”

The lasting damage comes from avoidable mistakes:

• Old URLs that return a 404 error instead of pointing to the new page.
• Pages that ranked well getting cut or merged without anyone checking what they ranked for.
• Page titles and meta descriptions reset to generic defaults.
• A staging site left open to Google, so it indexes a second copy of everything.
• Redirects that loop or chain through several hops.

Every step below exists to prevent one of those.

How do you do an SEO migration?

Work in three phases. Before launch, list every URL and map its redirect. On launch day, test everything. After launch, watch Search Console and fix problems fast.

Here is how the rest of this guide breaks down:

1. Before launch: inventory the old site, decide what happens to each page, build the redirect map, carry over titles and content, and build on a hidden staging site (steps 1 to 5 below).
2. Launch day: crawl every URL, test redirects, forms and tracking, and clear every cache.
3. After launch: submit the sitemap, watch for errors, and keep the redirects for at least a year. If the new site doesn’t show up at all, work through why a website isn’t showing up on Google.

Do it in one move if you can. For small and medium sites, Google recommends “moving all URLs on your site simultaneously instead of moving one section at a time.” Very large sites can move in sections. Domain changes and hosting moves add a few steps of their own, covered further down.

Step 1: How do you inventory a website before migrating?

List every URL the old site has, from its sitemap, a crawl and Search Console, then put them in one shared spreadsheet before anyone builds anything.

When we rebuilt the website for Lane & Associates Family Dentistry, a practice with 52 offices across North Carolina, the old site’s sitemap listed 1,173 URLs. Some were core pages. Many were not: old contests, expired promotions, cart and account pages, a COVID-19 notice, an archived careers page and test pages that had been published by mistake.

We put every one of those URLs in a shared spreadsheet that the practice’s marketing team could see and comment on. Each row got a decision: keep and rebuild, redirect, or retire. That sheet became the build plan. 238 pages were marked to keep, alongside more than 240 blog posts, 52 office pages and 111 doctor profiles, so the rebuild covered well over 400 pages of real content.

The spreadsheet matters because migrations are team decisions. A developer can tell you a page looks unused. Only the business knows that a page is printed on a flyer or tied to an ad campaign.

Step 2: What do you do with old pages you no longer need?

Do not just delete them. Redirect them to the closest matching page, keep them if they still serve visitors, or point duplicates at one main version.

Older sites collect clutter. Lane’s site had seasonal promotion pages with names like Pumpkin Spice and Freebie Friday, contest voting pages and a set of Education Center question pages that were full copies of their main topic pages. None of that fit the new design, but some of it still had links pointing at it and visitors arriving from search.

Here is how we handled the different kinds of clutter:

• Promotions and campaigns: rebuilt the ones the practice still runs, and redirected the expired ones so anyone following an old link still lands somewhere useful.
• Old blog posts that moved: redirected one to one. Lane’s old blog URLs now point to the matching Education Center topics.
• Duplicate pages: kept live, with a canonical tag telling Google which version is the main one. We did this for 27 Education Center copies after launch, which keeps them working for visitors without splitting ranking signals.
• Misspelled addresses: kept on purpose. The old site had a couple of URLs with typos in them. Existing links pointed at those exact spellings, and fixing the typos would have broken every one of them.
• True junk such as test pages and backups: removed from the site and the sitemap.

Which old pages look useless but still bring in visitors?

Short, odd-looking pages often belong to ad campaigns, QR codes or print materials. Check traffic sources and ask the business before retiring any of them.

This was the hardest lesson on the Lane rebuild. Two pages looked like leftovers during the cleanup: one called simply /welcome/ and one called /new-patient-special/. Both were swept into broad redirects that sent unmatched old URLs to the blog.

They were not leftovers. The first was the landing page for a radio advertising campaign. The second was the destination for QR codes printed in a partner publication. Neither showed up as important in a page list, because their visitors came from outside the website. When the practice flagged them, we rebuilt both pages at their original addresses.

What we do differently now:

• Check Search Console and analytics for every page before retiring it, including referral and campaign traffic, not just organic search.
• Ask the client directly about print, QR codes, ads, email campaigns and partner links.
• Avoid catch-all redirects for anything that might be a campaign page. A page-by-page redirect is slower, but it is honest about where each visitor ends up.

Step 3: How do you build a redirect map?

Match every old URL that matters to its closest new URL, use permanent 301 redirects, and send each one straight to its final destination with no chains.

Google’s advice is to keep redirects “for as long as possible, generally at least 1 year,” and to avoid chains: “we advise redirecting to the final destination directly.” Two days after Lane’s launch, the site had 617 redirect rules with no chains and no loops, and the www, http and staging versions of the domain all pointed to the one live address.

Smaller sites need the same care. When we redesigned BioSafe Waste Services, a medical waste disposal company in Raleigh, the new site changed how blog posts were addressed. We added redirects for the old post URLs into the new blog section and pointed the old map page at the new service areas page, so nothing that had earned a link went to a dead end.

A good redirect map:

1. Uses a 301 (permanent) redirect, not a 302.
2. Points to the most relevant page, not the homepage. Sending everything home is treated much like a missing page.
3. Has no chains, where A goes to B which goes to C.
4. Gets tested by crawling every old URL after launch, not just a sample.

Step 4: How do you keep titles, descriptions and content when you rebuild?

Copy the old page titles and meta descriptions onto the matching new pages, keep the content that ranked, and save anything only the old pages held.

A new design should not mean new wording for every search snippet. Before Lane’s launch we copied the existing page titles and meta descriptions onto 554 matching pages and posts on the new build, so the search results people already recognized stayed the same. Pages with no old version got their own titles and descriptions as part of the post-launch cleanup.

On a store, the details live in different places. When we redesigned ducks-n-stuff, a Raleigh gift shop on Shopify, every product and collection kept its address through the new theme. Before the old pages were rebuilt, we pulled out the real business details only they held, including the shop’s address, phone number, return policy and list of stockists, and carried them into the new pages.

The same rule applies to a single page. When we rebuilt the customer success stories page for SmartSign2Go, a digital signage software company, we launched the new version at the same address, so it kept its search title and its history. The test copy we built it on now redirects to the live page so the two never compete in search.

Step 5: Should you build on a staging site and keep the old site?

Yes. Build on a staging copy hidden from Google, and keep a private, noindexed copy of the old site after launch as a reference.

Lane’s new site was built at a staging address while the old site kept serving patients. On launch day the staging build moved onto the live domain, and the staging address now redirects to the live site.

We kept the old site running on its own subdomain, blocked from search engines. That decision paid off within days. After launch, 24 media files turned out to be missing because they had never been copied into the new build. We restored them straight from the old copy instead of asking the practice to dig up the originals.

BioSafe went live the same way: the finished staging site became the live site on launch day.

What changes when you move to a new domain?

Everything above still applies. Add a 301 redirect from every old URL to its new address, then file a Change of Address request in Search Console.

The Change of Address tool tells Google the whole site has moved. Google says you “only need this tool when moving from one domain or subdomain to another.” You don’t need it for a move from http to https, a switch between www and non-www, or new page paths on the same domain. If your old domain has several verified versions in Search Console, Google asks you to submit the request for each of them.

After the move:

• Keep the old domain registered. The redirects only work while you still own it. Google’s advice is to keep them “for as long as possible, generally at least 1 year,” and from a visitor’s point of view, indefinitely.
• Point redirects at pages that exist. Google lists redirects to “the wrong (non-existent) URLs on the new site” as a mistake it sees often.
• Expect the handoff in your reports. Traffic drops on the old domain and rises on the new one. That is the move working.

Does changing web hosting affect SEO?

Not when every URL stays the same and the new server is fast and reliable. Lower your DNS TTL a week early and keep the old host running until its traffic stops.

A hosting move changes where the site lives, not its addresses, so there are no redirects to map. Google has a separate guide for moves without URL changes. The main points:

• Lower your DNS TTL “to a conservative low value (for example, a few hours)” at least a week before the move, so the switch spreads quickly.
• Expect a short dip in how often Google crawls you right after the switch. Google calls that normal.
• Make sure your new firewall or bot protection is not blocking Googlebot.
• Keep the old host until “the traffic to the old provider reaches zero,” then shut it down.

When we move a WordPress site onto our hosting (free for clients moving to us), the URLs never change, so search impact is rarely the issue. What breaks is usually less obvious. The saved password that sends form emails can stop working, because email plugins encrypt it with WordPress security keys that can change in a move. Caches on the server and at Cloudflare can keep serving the old copy. So we re-enter the email login and send a test, clear every cache layer, and check that forms and tracking still fire before we call a move done.

What should you check on launch day?

Crawl every URL, test redirects and forms, confirm tracking fires once, clear every cache layer, and confirm the live site is indexable while staging is not.

Launch day on a large site always turns something up. On the Lane launch we crawled all 675 URLs in the new sitemap and checked every link and image the same day. That pass found and fixed:

• A redirect rule that was sending every blog category to the main blog page.
• Five redirect loops, including one on the online payment page.
• 82 office phone links that did not open the phone dialer.
• Seven test pages that had been published by mistake and were in the sitemap.
• 97 links that still pointed nowhere, left over from the build.
• 442 database entries still loading images from the staging address.

Two problems had nothing to do with pages at all. Cloudflare was still serving visitors a cached copy of the pre-launch site, so we purged it. And moving the database had wiped the tracking scripts and broken the saved email password that sends the site’s form emails, so we restored the tracking, confirmed each script loaded once, and sent test emails until form messages were arriving. Our guide on how to increase website conversion rate covers how to confirm that tracking counts real leads after a launch.

Our launch-day list for every migration:

1. The live site allows indexing; the staging site does not.
2. Every old URL redirects once, to the right page.
3. Every form submits and the email arrives at the right inbox.
4. Analytics and ad tracking load once per page, not zero times or twice.
5. Server, plugin and CDN caches are all cleared.
6. The XML sitemap lists only real, live pages.
7. Phone links, maps and payment pages work on a phone.

What should you do in the first weeks after a migration?

Submit the new sitemap, watch Search Console for errors, fix structure issues quickly, and keep the redirects in place for at least a year.

The first week after Lane’s launch went to structure. We made sure 628 of the 671 sitemap URLs had exactly one main heading, added canonical tags to the duplicate Education Center pages, added structured business data to all 52 office pages and wrote 54 missing meta descriptions. Over the following weeks, when the practice reported the two campaign pages that had been redirected, we restored them.

Then watch the numbers. On BioSafe, comparing the 40 days after launch with the 60 days before it, Google impressions went from about 2,600 a month to about 4,900, and clicks from about 40 a month to about 55. On ducks-n-stuff, the DCUK wooden duck collection now brings in more search clicks than any other page, and the store shows on the first page of Google for “wooden ducks.”

Give Google time. A few weeks of movement is normal. A steady slide after the first month is a signal to recheck redirects, missing pages and Search Console’s indexing report.

What does a bad site migration look like, and can you recover?

Search traffic that keeps sliding past the first month, a jump in errors in Search Console, and old URLs that land on 404 pages. Most of it can be fixed if you act quickly.

Some movement in the first few weeks is expected. Google says to “expect temporary fluctuation in site ranking during the move.” The warning signs are different:

• Search clicks and impressions still falling after the first month, instead of leveling off.
• A spike in errors in the Page indexing report. Google tells site owners to check it for “a spike in other errors on your new site during migration events.”
• Pages from the sitemap that never get indexed.
• A noindex tag or robots.txt block left over from staging. Google lists forgetting to remove these as a common mistake.

To recover, go back to the inventory from step 1. That is why you keep it. Crawl every old URL again. Point each 404 at its closest new page with a 301. Remove any leftover noindex or robots.txt blocks. Bring back content that ranked and was cut. Then resubmit the sitemap. On the Lane rebuild, the two campaign pages that had been swept into a catch-all redirect came back at their original addresses as soon as the practice flagged them. The faster you fix redirects, the less ranking history you lose.

Website migration SEO checklist

Use this website migration checklist on any move: inventory, decide, redirect, carry over, stage, launch and monitor, in that order.

It works as an SEO site migration checklist for a redesign, a platform change, a domain change or a hosting move. Skip the redirect step only when no URL changes.

1. Inventory: list every URL from the sitemap, a crawl and Search Console in one shared sheet.
2. Decide: keep, redirect or retire each page, with the business signing off.
3. Protect hidden traffic: check campaign, QR code, print and referral traffic before retiring anything.
4. Redirect: one 301 per old URL, to the closest new page, with no chains.
5. Carry over: titles, descriptions, ranking content and business details.
6. Stage: build on a hidden staging site and keep a noindexed copy of the old site.
7. Launch: crawl everything, test forms and tracking, clear every cache.
8. Monitor: submit the sitemap, watch Search Console, keep redirects for at least a year.

Frequently asked questions

When should you hire help for an SEO migration?

Get help when URLs change across more than a handful of pages, when you change domains or platforms, or when search leads pay a real share of the bills.

A five-page site that keeps its addresses can follow the checklist above in an afternoon. A site with hundreds of pages, years of blog posts, location pages or a store is different. The redirect map alone can run to hundreds of rules, and Lane’s ended up with 617. Hidden campaign pages and broken form email are easy to miss when you are doing this for the first time.

If you hire an SEO migration service, ask for these three things in writing, and be wary of anyone who won’t commit to them:

1. The full redirect map, as a spreadsheet you keep.
2. A crawl of every old URL after launch, not a sample.
3. Someone watching Search Console for the first month and fixing what turns up.

Planning a redesign or a move?

A migration is where a lot of hard-won search traffic gets lost, usually through small things nobody checked. We plan the move, build on staging, map every redirect and stay with the site after launch to catch what launch day turns up.

See what else we do on our services page, read more about what a maintenance plan covers after launch, or book a free consultation and tell us about the site you are moving.