SEO Website Migration Checklist

A migration is any change that moves or rebuilds URLs: a new domain, a new platform (WordPress to something else, for example), a redesign with a new URL structure, or a switch to HTTPS. Done carefully, it can be a chance to clean up. Done in a rush, it's one of the fastest ways to lose search traffic. Here's the full checklist I work through, from planning to the first year after launch.

Types of migration and how risky each one is

Migration	What changes	Main SEO risk
Domain move	Every URL gets a new address (oldname.com to newname.com)	Highest. All signals have to transfer through redirects
Platform or CMS change	The software behind the site, and often its URL patterns	URL patterns, titles, schema and redirects that don't carry over
Redesign with new URLs	Navigation, page structure and URLs	Missing redirects and pages that lose content or internal links
Structure change	Folders, such as /services/implants/ to /dental-implants/	Redirect gaps and broken internal links
HTTP to HTTPS, or www changes	The protocol or hostname	Lower if every variant redirects in one hop
Hosting or server move	Where the site runs; URLs stay the same	Downtime, slower responses and lost server settings such as redirects

Google announced HTTPS as a lightweight ranking signal in 2014 (Google Search Central). The bigger reasons to move are security and user trust. If you can, avoid stacking several types at once, such as a new domain, new platform and new content in the same week. When something drops, you won't know why.

Phase 1: Plan the migration

1. Write down the goal and the scope

One paragraph is enough: why you're moving, what's changing (domain, platform, URLs, content, design) and what must not change. This becomes the test for every decision later. "Faster site on a new platform, same URLs where possible" leads to very different work than "new brand, new domain".

2. Pick a quiet launch window

Launch in your slowest season and on a weekday morning when someone can fix problems, not on a Friday evening. For an HVAC company, that's usually spring or fall rather than a heat wave. For many practices, it's not the week before the holidays. Leave a buffer of a few days after launch for fixes.

3. Agree who does what

List who owns the redirects, the content, tracking, Search Console and the final go-live decision. On small sites that might be two people. Write it down anyway.

4. Back up and plan a rollback

Take a full backup of the old site, including files, database and server configuration such as existing redirects. Decide in advance what would make you roll back, and how you'd do it.

Phase 2: Before launch

5. Benchmark everything

Before anything changes, save a snapshot you can compare against later:

• Search Console Performance exports by page and by query, for the last three months and the last 16 months.
• Google Analytics 4 landing pages with organic sessions and key events (Google renamed GA4 "conversions" to "key events" in March 2024).
• Your Google Business Profile performance: calls, direction requests and website clicks.
• A full crawl of the old site: every URL with its status code, title, meta description, main heading, canonical and word count.

6. Build a complete URL inventory

No single source has every URL, so combine them:

• The crawl from step 5.
• Your XML sitemaps.
• The Pages tab in Search Console's Performance report.
• Analytics landing pages.
• Pages with links from other sites, from the Links report in Search Console.
• Files people link to directly: PDFs, images and downloads.

Remove duplicates, then mark each URL's priority. Pages with clicks, links or conversions are high priority. Old tag pages with no traffic are low.

7. Decide what happens to each URL

• Keep: the page moves to a new URL with the same purpose. It gets a redirect.
• Merge: two thin pages become one. Both old URLs redirect to the new one.
• Remove: the page has no traffic, no links and no replacement. Return a 410 (gone) or 404. Don't redirect it to the home page. Google says redirecting many old URLs to one unrelated page like that might be treated as a soft 404.

8. Build the redirect map

Make a spreadsheet with these columns: old URL, new URL, status code (301, or 410 for removals), priority and notes. Then apply these rules:

• One hop. Each old URL goes straight to its final new URL. Fix existing redirects too, so an old A to B redirect doesn't become A to B to C.
• Server-side, permanent redirects. Google's site-move guide recommends server-side 301 or 308 redirects from old to new URLs (Google Search Central).
• Closest match. Send each page to the new page that serves the same need, not to a category or the home page.
• Every variant. Cover http and https, www and non-www, trailing slash and no trailing slash, and old URLs with tracking parameters.
• Patterns where possible. If a whole folder moves, one rule can handle it. Keep one-to-one rules for pages that changed names.

9. Set up and lock down staging

Build the new site on a staging copy and password-protect it. That keeps out both people and crawlers. A noindex tag or a robots.txt block on staging is a reasonable backup, but put "remove staging blocks" on your launch-day list now. Leftover blocks are one of the most common causes of a post-launch collapse.

10. Carry over what already works

For each page you're keeping, move the title, meta description, main heading, body content, image alt text, internal links and structured data, unless you're deliberately improving them. Bring images and PDFs across with redirects if their URLs change. Validate structured data with the Rich Results Test or the Schema Markup Validator (the old Structured Data Testing Tool is no longer Google's tool for this).

11. Compare the two crawls

Crawl the staging site and line it up against your old crawl, page by page. Look for:

• Pages in the old crawl with no match in the new one.
• Titles, meta descriptions or main headings that went missing or changed by accident.
• Pages whose word count dropped sharply, which often means content didn't migrate.
• Canonical tags that point to the old domain or the staging domain.
• Internal links that point at old URLs and would now go through a redirect.
• Orphan pages, meaning pages that nothing links to.
• Structured data that disappeared.

12. Rebuild tracking

Install your Google Analytics 4 tag or Google Tag Manager container on staging and confirm that the key events (calls, form submissions, bookings) fire. Check call tracking numbers, Google Ads conversion tags and any chat or booking widgets.

13. Test the redirects before launch

Run your whole redirect map against staging, or against a test hostname, and check that each old URL returns one 301 to the right page, which then returns a 200. My guide on how to check if a link redirects shows quick ways to test single URLs. For the full list, use a crawler in list mode.

Phase 3: Launch day

1. Put the site live and switch on the redirects.
2. Remove the staging password, noindex tags and robots.txt blocks from the live site. Then check a few page sources yourself to confirm.
3. Test your top 20 to 50 old URLs by hand.
4. Make sure internal links, navigation and canonical tags point straight at the new URLs, not through redirects.
5. Publish a new XML sitemap that lists only live, indexable URLs.
6. In Search Console:
   • Verify the new property, including every hostname variant you use.
   • Submit the new sitemap.
   • Use URL Inspection on your most important pages and request indexing.
   • Check the robots.txt report in Settings. It replaced the old robots.txt Tester in late 2023.
   • For a domain or subdomain move, submit a Change of Address from the old property. Google says you don't need it for HTTPS or www changes, or for moving paths within the same domain.
7. Repeat the sitemap and site setup in Bing Webmaster Tools.
8. Update your website link in your Google Business Profile, ad final URLs, social profiles and main directory listings.
9. Add an annotation in Google Analytics 4 for the launch date, so anyone reading the reports later can see when the move happened.
10. Confirm that key events are recording on the live site.

Phase 4: After launch

The first 48 hours

• Crawl the live site and compare it with your old crawl again. Fix any 404s, redirect chains or missing pages right away.
• Watch your server logs or hosting dashboard for spikes in 404 or 5xx errors.
• Check that forms, calls and bookings still reach the right people.

Weeks 1 to 8

• Page indexing report: watch the "Not found (404)", "Page with redirect", "Excluded by 'noindex' tag" and "Blocked by robots.txt" reasons. Old URLs moving into "Page with redirect" is normal and expected.
• Performance report: compare clicks and impressions by page against your benchmark using the date comparison. Look at the new URLs and the old ones side by side.
• Crawl stats report (in Settings): check that Googlebot is crawling the new site and that response times and errors look normal.
• Sitemaps report: confirm the new sitemap was read. Google says you can remove the old sitemap once you've submitted the new one.
• Old URLs still showing: a site: search on the old domain or old folders gives a rough view of what's still indexed. My guide to Google search operators explains the limits of that search.

Expect some movement. Google's guide says rankings can fluctuate during a move, and that for a medium-sized site it "can take a few weeks or more" for the new URLs to replace the old ones in search results.

Months 3 to 12

• Ask the sites with your most valuable links to update them to the new URLs.
• Run a monthly crawl to catch new broken links and redirect chains.
• Keep the redirects. Google advises keeping them "for as long as possible, generally at least 1 year." I keep them permanently where I can, and I keep the old domain registered.

If traffic drops after a migration

What you see	Likely cause	What to check
Most pages drop out of Google	A leftover noindex tag or robots.txt block	Page source, the robots.txt report and URL Inspection
Some important pages drop	Missing or wrong redirects, or lost content	Redirect map against the live site, and the crawl comparison
Old URLs still ranking weeks later	Redirect chains, or internal links and canonicals still pointing at old URLs	A crawl of internal links and canonical tags
Traffic is fine but leads fell	Broken tracking, forms or call numbers	Key events in GA4, test calls and test forms

Common migration mistakes

• Redirecting every old URL to the home page.
• Leaving noindex or a robots.txt block from staging on the live site.
• Forgetting old image, PDF and blog URLs that had links.
• Changing the design, content and URLs all at once, so you can't tell what caused a drop.
• Letting the old domain expire while redirects still depend on it.

Planning a migration?

Migration planning and redirect mapping are part of my SEO consulting work, and I'm happy to review a plan before you launch. The free audit is a quick way to get a baseline of how your current site shows up in Google, Google Maps and AI answers.

Get a free audit · Book a 30-minute strategy call

Related guides

• How to check if a link redirects
• On-page SEO: a practical checklist
• SEO basics: a beginner's guide

FAQ

Will I lose rankings when I migrate my website?

Some movement for a few weeks is normal while Google recrawls. A complete redirect map, carried-over content and careful launch checks reduce the risk of a lasting drop. Large drops usually come from missing redirects, leftover noindex tags or removed content.

Should I use 301 or 302 redirects for a migration?

Use permanent, server-side redirects (301 or 308) for pages that have moved for good. A 302 is for temporary moves. Send each old URL straight to its final new URL in one hop.

How long does it take Google to process a site migration?

Google says that for a medium-sized site it can take a few weeks or more for the new URLs to replace the old ones in search results, and longer for large sites. Rankings can fluctuate during that time.

How long should I keep redirects after a migration?

Google advises keeping them for as long as possible, generally at least a year. Keeping them permanently is safest for users and for links from other sites.

Do I need Google's Change of Address tool?

Only when you move to a different domain or subdomain. Google says you don't need it for HTTP to HTTPS moves, www changes or moving paths on the same domain.

What should I do with pages I'm removing?

If a page has a close replacement, redirect it there. If it has no replacement, no traffic and no links, return a 410 or 404 instead of redirecting it to the home page.

---

Khalid Hossen has worked in SEO and Google Ads for 14+ years, with 150+ dental & local service businesses served, and helped scale two dental practices to $5M. No long-term contracts. Get a free audit of how your practice or business shows up in Google, Google Maps and AI answers.