Website Migration SEO Checklist: Move Sites Without Losing Rankings

The Short Version

A website migration protects your SEO when every old URL either stays exactly the same or 301-redirects to its closest equivalent on the new site, the page titles, headings, and content stay substantially similar, and you tell Google about the change through your sitemap and Search Console. Miss any of those and rankings drop, sometimes for months.

This checklist walks through the process in order: before you build, at launch, and the 30 days after. It applies whether you're changing domains, moving platforms (Wix to WordPress, WordPress to a custom build), restructuring URLs, or all three at once. The goal is simple to state and easy to skip: zero 404s from URLs that used to work.

What Counts as a Website Migration

Any change that alters the URLs Google has indexed is a migration from an SEO point of view:

• Domain change — oldbusiness.com to newbusiness.com
• Protocol or subdomain change — http to https, www to non-www
• Platform change — moving from Squarespace, Wix, or WordPress to another system, which almost always changes URL patterns
• URL restructure — /blog/2023/05/post-name/ becoming /blog/post-name/
• Redesign with consolidation — merging ten thin pages into three strong ones

A visual redesign that keeps every URL identical isn't technically a migration, but the metadata and internal-link steps below still apply, because those usually change alongside the design.

Part 1: Before You Build Anything

1. Inventory every URL on the current site

You cannot redirect what you don't know exists. Build a master list from three sources, because each catches URLs the others miss:

• A full crawl of the live site using a crawler such as Screaming Frog (the free tier handles 500 URLs). This finds everything linked internally.
• Google Search Console — export the Pages report under Indexing (indexed and not-indexed) and the Performance report for the last 16 months. This finds pages Google knows about even if nothing links to them anymore.
• Google Analytics — export all landing pages from the last 12 months. This finds pages that get traffic from sources you may not have considered.

Also collect PDFs, image URLs if they rank in image search, and any pages linked from your Google Business Profile, social profiles, or printed materials. Put everything in a spreadsheet with one row per URL. This becomes your redirect map.

2. Record baseline metrics

Take a snapshot before you touch anything so you have something to compare against later:

Save these as exports, not screenshots. You'll want to sort and filter them later.

3. Decide what happens to every page

Mark each URL in the inventory with one of four outcomes:

• Keep — same URL on the new site, content unchanged or lightly updated
• Move — new URL, same or similar content, gets a 301 redirect
• Merge — content folded into another page, 301 to that page
• Retire — no equivalent exists; either 301 to the closest relevant parent page or let it return 410/404 deliberately

Anything with traffic or backlinks should be kept or moved, not retired. Anything with neither is a candidate for merging, which often improves the site rather than hurting it.

4. Build the 301 redirect map

For every Move and Merge row, add the destination URL. A few rules that prevent most problems:

• One-to-one wherever possible. Redirect the old about page to the new about page, not to the homepage. Google treats mass redirects to the homepage as soft 404s, and the authority doesn't transfer.
• Redirect to the closest equivalent. If a blog post about "winter HVAC maintenance" is being retired, redirect it to your HVAC maintenance service page, not to the blog index.
• No chains. Old URL to new URL in one hop. If the site already has redirects from a previous migration, update those rules to point directly at the final destination.
• Match trailing slashes, case, and query strings. Pick one canonical format for the new site and make sure redirects land on it, not on a URL that then redirects again.

If you're changing domains, map at the path level (old-domain.com/services/ to new-domain.com/services/), not with a single blanket rule that sends everything to the new homepage.

5. Plan metadata and content parity

Google evaluates the new page against what it knew about the old one. The more that changes at once, the more the page has to re-earn its position. For every Keep and Move page, carry over:

• Title tag — same or a close revision, with the same primary keyword
• Meta description — can be rewritten, but keep it topical
• H1 and H2 structure — same topics in roughly the same order
• Body content — same substance, even if the design around it changes completely
• Image alt text and file names — easy to lose during a platform move
• Structured data — LocalBusiness, FAQ, Product, or Article schema should be rebuilt, not dropped
• Canonical tags — pointing to the page's own new URL

If you also want to rewrite content, the safest sequence is migrate first, stabilize, then improve. If you must do both at once, at minimum keep titles and H1s close to the originals on your top-traffic pages.

Part 2: During the Build

6. Keep the staging site out of Google

While the new site is being built, block it from indexing (a noindex tag, password protection, or both) so Google doesn't index staging URLs and treat the launch as duplicate content.

Then set a reminder to remove the block at launch. Launching with noindex still in place is one of the most common and painful migration mistakes, and it's easy to do because the tag is invisible to visitors.

7. Rebuild internal links to point at new URLs

Every link inside the new site should point directly to the final URL, not to an old URL that redirects. Redirected internal links work, but they waste crawl budget and make your structure harder for Google to read. Crawl the staging site and fix any internal link that returns a 3xx, including navigation, footer, and hard-coded links in blog posts.

8. Test the redirect map on staging

Before launch, test the redirect rules against the full URL inventory, not a sample. Most crawlers can take a list of URLs and report the status code and final destination for each. You're looking for:

• Every old URL returns 301 (not 302, not 200, not 404)
• Every 301 lands on a page that returns 200
• No redirect chains (A to B to C)
• No redirect loops
• Destination pages are the correct equivalents, not the homepage

Fix everything before launch day. A redirect map that's 95% right still leaves 5% of your URLs broken.

9. Prepare the new XML sitemap

The new sitemap should list only final, canonical, indexable URLs that return 200. No redirected URLs, no noindexed pages, no staging URLs.

Part 3: Launch Day

10. Go live and remove the indexing block

Deploy the new site, remove the noindex or password protection, and confirm robots.txt allows crawling. View the source of the homepage and a few deep pages to confirm no noindex tag survived.

11. Verify redirects on the live site

Run the full URL inventory through a crawler again, this time against production. Staging and production hosts sometimes handle redirects differently. Then manually spot-check the top 20 old URLs by traffic and backlinks and confirm each lands where it should.

12. Update Search Console

• Same domain, new URLs: submit the new sitemap and request indexing on your most important pages through URL Inspection.
• New domain: verify the new domain as a property first, then use the Change of Address tool in the old property. This tells Google explicitly that the site has moved.
• Keep the old sitemap submitted for a few weeks. It helps Google recrawl the old URLs and discover the redirects faster. Remove it once those URLs have dropped out of the index.

13. Update everything that points at you

Google's index isn't the only place your old URLs live. Update your Google Business Profile website link, social profiles, email signatures, directory listings and citations, and any ad campaigns (a landing page that redirects can hurt Google Ads Quality Score).

14. Check analytics and tracking

Confirm Google Analytics, Search Console verification, conversion tracking, and any call- or form-tracking scripts made it to the new site and fire correctly. Plenty of migrations look like a traffic crash when the tracking code was simply left behind.

Part 4: The 30 Days After Launch

15. Daily for the first week

• Search Console Pages report — watch for a spike in "Not found (404)" errors
• Server logs or hosting 404 reports — this is where you find URLs your inventory missed
• Performance report — impressions usually dip briefly and recover; a sharp drop that continues past day 5 to 7 usually means a redirect or noindex problem

Add redirects for any missed URLs immediately. Every day a URL 404s is a day its backlinks pass nothing.

16. Weekly for the first month

Compare against the baseline you saved in step 2:

If the new build is slower than the old one, that's a separate ranking problem layered on top of the migration. Our Core Web Vitals guide covers what to check.

17. Chase the stragglers

Around week two, pull the backlink report again and look for links pointing at old URLs. Where you have a relationship with the linking site, ask them to update the link to the new URL directly. Redirects pass most of the value, but a direct link is cleaner and permanent.

18. Don't panic, but don't ignore

Some fluctuation for two to four weeks is normal even on a perfect migration. A sustained drop with no recovery trend by week four is not. If that's what you're seeing, go back through steps 10 to 14 in order; the usual culprits are a leftover noindex, a redirect landing on the wrong page, or a batch of URLs that never made it into the inventory. Our guide on why a website isn't showing up on Google covers the other diagnostic steps.

The Whole Checklist in One Place

Before you build

1. Inventory every URL (crawl + Search Console + Analytics)
2. Record baseline metrics
3. Decide keep / move / merge / retire for every page
4. Build a one-to-one 301 redirect map with no chains
5. Plan title, heading, content, schema, and canonical parity

During the build

6. Block staging from indexing
7. Point all internal links at final URLs
8. Test the full redirect map on staging
9. Prepare a clean XML sitemap

Launch day

10. Go live and remove the indexing block
11. Verify redirects on production
12. Submit sitemap and update Search Console (Change of Address if the domain changed)
13. Update GBP, social, directories, ads, and email links
14. Confirm analytics and conversion tracking

First 30 days

15. Daily: check 404s, index coverage, and impressions
16. Weekly: compare against baseline
17. Ask linking sites to update old links
18. Investigate any drop that hasn't turned by week four

Where Built For Rank Fits

If you're planning a rebuild, our website redesign service treats the migration as part of the job, not an add-on: the SEO migration plan, 301 redirect map, and post-launch monitoring are included in the $1,500 build, and you own the site, content, and domain when it's done. You can see the full process on how it works. That said, if your current site is small and you're comfortable with a spreadsheet and a crawler, this checklist is enough to do it yourself. If you'd rather have someone check your redirect map before launch, or handle the whole move, request a free consultation and we'll tell you honestly which option makes sense.