Most SEO problems after a website migration were preventable.
The rankings drop. The traffic disappears. The development team says everything went fine technically. And they’re right — the build was clean. But no one mapped the redirects properly. No one checked whether Google could still crawl the new site. No one verified the metadata carried over.
This checklist exists so that doesn’t happen to you.
Use it before you start the build, during staging, on launch day, and for 30 days after. Every item on this list represents something that has caused real ranking damage on real migrations when it was skipped.
If you’re working with a developer who doesn’t have a migration SEO process, share this with them. If you want someone to run this process for you, that’s what we do at FlintHorn.
Before You Build Anything — Pre-Migration SEO Audit
Do this before a single page of the new site is designed.
Crawl and document your current site
Crawl your existing site with Screaming Frog, Ahrefs, or Sitebulb
Export every URL that returns a 200 status code
Note every URL’s current title tag, meta description, H1, and canonical tag
Identify your top 20 pages by organic traffic (use Google Search Console or Google Analytics)
Identify your top 20 pages by backlinks (use Ahrefs or Semrush)
Flag any pages with structured data / schema markup — these need to be recreated
Audit your current technical SEO baseline
Record your current Core Web Vitals scores (use PageSpeed Insights or GSC)
Document your current sitemap location and structure
Check your robots.txt — note anything blocked
Confirm which pages are indexed in Google (site:yourdomain.com search)
Screenshot your Google Search Console coverage report — you’ll compare this post-launch
Identify what’s worth keeping vs. rebuilding
Flag pages with strong backlinks — these URLs should be preserved exactly if possible
Flag pages with strong organic traffic — same
Identify thin, duplicate, or low-value pages — migration is a good time to consolidate or remove these deliberately rather than carrying over dead weight
URL Mapping and Redirect Planning
This is where most migrations go wrong. Every URL needs a destination.
Build your redirect map
Create a spreadsheet with two columns: old URL → new URL
Every URL from your crawl needs a row — no exceptions
For pages that are being kept: map old URL to new URL (even if the slug changes slightly)
For pages that are being consolidated: map old URL to the new consolidated page
For pages that are being removed: map old URL to the most relevant remaining page (not just the homepage)
Flag any URLs with significant backlinks — double-check their redirect destination is correct
Redirect rules
All redirects must be 301 (permanent) — not 302, not meta refresh
No redirect chains — old URL should point directly to new URL, not through intermediate URLs
No redirect loops
www and non-www variants both redirect correctly to your chosen canonical version
HTTP redirects to HTTPS on every URL
Test before launch
Load your redirect map into a redirect checker tool and test a sample of 50+ URLs
Verify top-traffic and top-backlink URLs manually in a browser
Check for chains using a tool like Redirect Checker or Screaming Frog
Staging Site SEO Review
Do this before you show the new site to anyone. Before the client signs off. Before go-live.
Block staging from search engines
Confirm robots.txt on staging disallows all crawlers (Disallow: /)
Or confirm staging is password protected
Do NOT let Google index your staging site — it creates duplicate content issues
Technical SEO audit of staging
Crawl the staging site — check for 404s, redirect errors, and broken internal links
Verify every page has a unique title tag (no duplicates, no placeholders)
Verify every page has a unique meta description
Verify H1 tags are present and correct on every page
Check canonical tags — every page should self-canonical or point to the correct canonical URL
Verify structured data / schema markup has been recreated (use Google’s Rich Results Test)
Verify XML sitemap exists and includes all intended pages
Verify robots.txt is correct for production (you’ll swap it on launch)
Run Core Web Vitals on staging — flag any regressions vs. your baseline
Content audit
Spot-check 20+ pages — verify body content carried over correctly
Verify all images have alt text
Check internal links — none should point to old domain or staging URL
Verify blog posts, case studies, and other content pages exist and are accessible
Launch Day Checklist
Launch day is not the time to discover problems. Work through this in order.
Pre-launch (do before DNS switch)
Redirect map is loaded and ready to deploy
New sitemap is ready to submit
Google Search Console is verified on the new site (add new property if domain changes)
Analytics tracking is confirmed working on staging
At launch (immediately after DNS propagates)
Deploy all 301 redirects
Update robots.txt to allow crawling (remove staging disallow)
Submit new XML sitemap in Google Search Console
Request indexing on your top 10 most important pages via GSC URL Inspection
Verify HTTPS is working on the live domain
Spot-check 10–20 redirects manually on the live site
Confirm analytics is firing on live site
Within 24 hours of launch
Crawl the live site — compare to staging crawl, flag any new errors
Check Google Search Console for immediate crawl errors or coverage issues
Verify Core Web Vitals on live site (PageSpeed Insights)
Check that old domain/URLs are redirecting correctly (test from an external tool)
Post-Launch Monitoring (Days 1–30)
The work isn’t done at launch. This is the window where issues surface and compound if you’re not watching.
Week 1 (Days 1–7)
Check Google Search Console daily — watch for spikes in crawl errors or coverage drops
Monitor organic traffic in GA4 — compare to same period prior year or prior month
Watch for any ranking drops on your top 20 keyword targets
Fix any crawl errors immediately — do not let them sit
Weeks 2–4 (Days 8–30)
Continue weekly GSC and analytics checks
Monitor backlink profile — verify referring domains aren’t pointing to 404s
Check that Google is indexing new URLs (not old ones) using site: search
Recheck Core Web Vitals at day 30
Confirm structured data is being recognized (GSC Enhancements report)
Day 30 review
Compare current indexed pages to pre-migration baseline
Compare organic traffic to pre-migration baseline
Compare keyword rankings to pre-migration baseline
Document any unresolved issues with a remediation plan
If traffic is meaningfully down after 30 days, escalate — do not wait for it to "recover on its own"
Common Migration SEO Mistakes to Avoid
A quick reference for the things that cause the most damage.
Redirecting everything to the homepage. This is the most common mistake. If you can’t find a relevant destination for an old URL, find the closest topically relevant page — not the homepage.
Forgetting URL parameter variations. Your crawl should capture ?utm_, ?ref=, and other parameter variants. Make sure these redirect cleanly.
Launching with a staging robots.txt. It happens more than you’d think. The new site launches with Disallow: / still in place and Google can’t crawl anything. Check this first on launch day.
Skipping the post-launch monitoring. Most clients and developers move on after launch day. The 30-day window is when issues surface in GSC — crawl errors, coverage drops, unresolved redirect chains. Watch it.
Treating a domain migration and a CMS migration as the same thing. A CMS migration (same domain, new platform) is lower risk than a domain migration (new domain). Both need this checklist. Domain migrations need extra attention on the backlink redirect verification step.
Need Someone to Run This Process for You?
This checklist covers what needs to happen. Running it properly on a real site — especially one with thousands of URLs, a complex backlink profile, or a tight launch window — takes experience and the right tools.
FlintHorn manages website migrations with SEO built into every step. We run this exact process on every project we take on.
See our Website Migration SEO service →
Or if you want a second opinion on an upcoming migration before you start: book a free migration audit →