Three years ago I got handed a migration that was already live. No staging environment. No redirect map. A 22,000-page e-commerce catalogue that someone had just pointed at a new domain and called it "done." Organic traffic dropped 74% inside six weeks. The client rang me in a mild panic, and I spent the better part of four months untangling it.
That experience — painful as it was — is basically why this checklist exists. I've since migrated sites ranging from 800-page brochureware to a 31,000-page publisher with regional subdomains, and the fundamentals are the same every time. Get the order wrong, skip one step, and Google will tell you about it in Search Console in the most unpleasant way possible.
So here it is. The actual checklist I use atSeahawk Media, not a theoretical framework.
---
1. Start With a Full Crawl Before You Touch Anything
Obvious? Yes. Skipped? Constantly.
Before a single file moves, I crawl the entire live site withScreaming Frog SEO Spider. On a 20,000-page site this takes a couple of hours — I usually kick it off overnight with the crawl stored to database mode so memory doesn't become an issue. What I'm capturing:
- Every indexable URL (the canonical version, not pagination noise)
- Response codes across the board — 200s, 301s, 302s, 404s, everything
- Existing internal link structure
- Canonical tags, hreflang attributes if applicable
- Page titles and meta descriptions (so I can verify they survive the migration)
I export the full crawl to CSV and keep it. This is my baseline. It's the document I'll compare against three weeks after the new site goes live.
A lot of people skip this step because "we already know the site." You don't. I thought I knew a travel client's site back in 2021 — turned out they had 4,000 URLs that were being served from a legacy CMS subdirectory that nobody had mentioned in the brief. Found it in the crawl. Would have been a disaster.
Don't Forget Google's Own Data
Pull everything fromGoogle Search Console— performance data for the last 16 months minimum, the index coverage report, any manual actions, all sitemaps. And pull from Google Analytics (GA4 now, obviously) so you have your organic traffic benchmarks locked down before anything changes. Screenshots work fine here; I also export the raw CSVs.
---
2. Build the Redirect Map. Then Check It Again.
This is where migrations live or die. On large sites, the redirect map is an actual spreadsheet — usually shared in Google Sheets with the client, their dev team, and anyone else who might accidentally overwrite a formula at 11pm.
The structure is simple:
- Column A: Old URL (exact, including trailing slash or lack thereof)
- Column B: New URL (exact)
- Column C: Redirect type (301 in almost every case)
- Column D: Status (mapped, verified, live)
- Column E: Notes (catch-all redirects, category consolidations, intentional drops)
On a 20,000-page site you obviously can't map every URL individually. Here's the order I work through:
- Map all top-performing URLs first (by organic traffic from GSC — the top 500 usually drive 80%+ of traffic)
- Map category and taxonomy pages
- Map any URL that has meaningful backlinks (useAhrefsfor this — filter by referring domains, not just raw links)
- Handle pattern-based redirects for everything else (e.g.,
/product/old-slug/→/shop/old-slug/) - Document intentional 410s for pages you're retiring
Pattern-based redirects are the thing most junior developers get wrong. They'll write a wildcard rule that's too broad and accidentally swallow URLs they didn't mean to redirect. Test every pattern rule on staging before it goes anywhere near production.
---
3. Staging Is Not Optional
I'll keep this short because it shouldn't need much explanation. Every migration gets a staging environment. Full stop.
Seahawk had a fintech client in 2022 who pushed back on this — wanted to "just do it on live because the site is small." The site had 6,000 pages. We did it on staging. Found a plugin conflict that was stripping canonical tags from all product pages. Would have been invisible until Google recrawled everything, which on a low-authority domain can take weeks.
On staging you're checking:
- All redirects fire correctly (I use Screaming Frog again, pointed at staging, to verify the redirect map in bulk)
- Robots.txt is blocking the staging environment from indexing (important — use
Disallow: /but also add a noindex header for double protection) - The new sitemap is accurate and doesn't contain staging URLs
- Canonical tags point to the correct production URLs
- Page speed baselines withPageSpeed Insights— migrations are often used as redesign opportunities, and redesigns frequently destroy Core Web Vitals
---
4. The Go-Live Sequence (Order Matters More Than You Think)
This is the part where people freestyle and cause themselves problems. There's a specific order. I don't deviate from it.
Step 1: Pre-launch (48 hours before)
- Reduce TTL on all DNS records to 300 seconds (5 minutes). Speeds up propagation significantly.
- Brief the client: no content changes, no new pages, no plugin updates during the migration window.
- Notify any third-party integrations (CDNs, ad platforms, monitoring tools) of the upcoming change.
Step 2: Launch window
- Update DNS
- Deploy redirects before the new content is fully propagated — redirects should be live at the server level, not just in WordPress
- Enable the new sitemap, disable the old one
- Verify robots.txt is correct (production file, not the staging one)
Step 3: Immediately post-launch
- Crawl the new site within two hours. Screaming Frog, pointed at production, respecting redirects. I'm looking for unexpected 404s, redirect chains longer than two hops, and any page that should be indexable showing a noindex tag.
- Submit the new sitemap in Search Console
- Fetch the homepage via GSC's URL Inspection tool to prompt Googlebot to visit
One thing I always flag to clients: Google will not immediately reflect the new URLs in search results. There's a crawl and reprocessing lag. On a large site, budget two to six weeks before you have a clear picture. Panicking at day four because rankings shifted is normal — it doesn't mean something is broken.
---
5. Redirect Chain Auditing (The Step Most Agencies Bill For Separately)
Redirect chains are a slow bleed. A URL that goes A → B → C → D is making Googlebot do extra work, and it's also diluting link equity across multiple hops. On a site that's had multiple previous migrations or platform switches, chains can get surprisingly deep.
Post-launch, I export the full Screaming Frog crawl and filter for redirect chains. Anything beyond two hops gets collapsed. If the original URL was on the redirect map, I update it to point directly to the final destination. If it was a legacy chain from a migration nobody documented, I add it.
This step alone — on a client we migrated from Magento to WooCommerce in early 2023 — took two days. They'd had three migrations over eight years. Some URLs were going through five redirects before landing on the correct page. Collapsed the lot, and their crawl budget metrics in Search Console improved noticeably within a month.
---
6. Content Verification at Scale
You can't manually review 20,000 pages. But you can systematically verify the things that matter.
Here's what I check in the first two weeks post-launch:
- Title tags and meta descriptions: Compare a random 200-page sample against the pre-migration Screaming Frog export. Mismatches get flagged immediately.
- Structured data: Run a sample of product pages, article pages, and the homepage through Google'sRich Results Test. Migrations break schema markup more often than you'd think, especially if the new theme uses a different plugin.
- Internal linking: Screaming Frog crawl, filter for inlinks. High-value pages should still have strong internal link counts. If a category page that previously had 400 internal links now has 12, something went wrong in the template.
- Images and alt text: Not strictly SEO-critical, but broken images hurt user experience signals and they're easy to miss on templated sites.
---
7. Monitoring for the 90 Days After
Migration isn't over on go-live day. It runs for 90 days minimum.
I set up weekly reporting cadences with the client for the first month, then fortnightly after that. Here's what I'm watching:
- GSC Index Coverage: Is the number of indexed pages recovering toward the pre-migration count? A significant drop that persists beyond three weeks needs investigation.
- Organic traffic vs. baseline: Segmented by landing page type (product, category, blog). Traffic drops are often uneven — sometimes category pages tank while product pages hold.
- Crawl budget: GSC's crawl stats report shows average pages crawled per day and server response times. If Googlebot is hitting a lot of 404s, it shows here.
- Ranking position tracking: I use a combination of Ahrefs rank tracking and Google Search Console's performance report. Ranking volatility in the first two to three weeks is common and not necessarily a problem. Sustained drops beyond week four warrant action.
- Backlink profile: Using Ahrefs, verify that high-value backlinks pointing to old URLs are either already redirected correctly or flagged for outreach to update.
The honest truth? Most migration SEO problems are detectable within 30 days if you're watching the right metrics. The ones that bite people are the ones where nobody set up monitoring and the client notices eight months later.
---
8. The Things I've Gotten Wrong (So You Don't Have To)
Back in 2019, I missed a hreflang implementation on a migration for a client with UK, Australian, and Canadian subfolders. The canonical tags were correct. The redirects were fine. But the hreflang annotations on the new site had the wrong region codes —en-auinstead ofen-AU(case matters, apparently, in some implementations). Google started serving the UK pages to Australian searchers. Took us six weeks to figure out why Australian organic traffic had halved. We've had a hreflang validation step in every international migration since.
Another one: XML sitemaps that contain noindexed URLs. This sounds like a minor inconsistency but it sends conflicting signals and is genuinely worth cleaning up. Screaming Frog can audit your sitemap and flag any URL in it that returns a noindex tag.
And probably the most expensive lesson: not having a rollback plan. On a migration that's going wrong, the ability to flip DNS back to the old server within an hour is worth its weight. I always insist the old environment stays live and intact for at least 30 days post-migration. Clients sometimes balk at the hosting cost. I explain what a 70% traffic drop costs in revenue and they stop balking.
---
FAQ
How long does a 20,000-page site migration actually take to plan?
Realistically? Six to ten weeks of preparation before the go-live date. The redirect map alone on a site of that size can take two to three weeks to build properly, especially if you're auditing backlinks for every URL. Rushing preparation is how you end up spending months in recovery.
Do I need to submit a disavow file after a migration?
Usually not, unless the old domain had toxic links and you're migrating specifically to escape them. If you're migrating to a new domain and want a clean link profile, handle the disavow on the new property in GSC. But for most platform or redesign migrations on the same domain, disavow is irrelevant.
What's the biggest mistake you see agencies make on large migrations?
Treating the redirect map as a dev task. Redirects are an SEO task that a developer implements. The SEO team — or whoever owns the search strategy — should own the map, review it, and sign it off. I've seen developers build technically correct redirect rules that were SEO-wrong because nobody told them which URL variant was canonical.
Does site speed affect migration SEO?
Yes, more than most people account for. Core Web Vitals are a ranking factor, and redesigns — which often accompany migrations — frequently introduce heavier JavaScript or unoptimised images. Always run a PageSpeed Insights comparison between the old and new site before launch. If the new site is meaningfully slower on mobile, fix it before you flip the switch.
How do you handle migrations for sites with lots of user-generated content?
Carefully. UGC pages are often low-quality individually but collectively drive long-tail traffic. I usually recommend a crawl-and-analyse step: identify which UGC URLs have any organic traffic at all, redirect those specifically, and 410 the rest rather than leaving them as 404s. A 410 tells Google the page is intentionally gone; a 404 is ambiguous.
---
Migrations are one of those things where the difference between good and catastrophic is almost entirely in the preparation. The technical implementation is usually the easy part. Getting the pre-launch work right — the crawl, the redirect map, the staging verification — is where the real work happens. And if you're ever handed a migration that's already live and already broken, the checklist still applies. You're just doing it in reverse.