Site Migration SEO Checklist: Save Your Traffic

The most common SEO disaster is an avoidable one: a site migration that loses 30–50% of organic traffic in the first month.

The losses aren't caused by the new design or the new platform. They're caused by broken redirects, missing meta data, and indexing gaps that nobody caught before launch. A site that took 18 months to build to 50,000 monthly visitors can lose half that traffic in 30 days when the migration runs sloppy. The traffic often takes 6–12 months to fully recover. Some never does.

This post is the pre-migration, migration-day, and post-migration checklist that protects what you've built. Findings draw on Brass-SEO's audits of post-migration sites in 2026 and Google's published migration guidance.

Why Migrations Go Wrong
The 30 Days Before Migration
The Week of Migration
Migration Day
The First 7 Days After
The First 90 Days After
Common Migration Disasters and Recovery
Frequently Asked Questions

Why Migrations Go Wrong

Site migrations fail SEO for one of four reasons:

Missing or broken redirects. Old URLs return 404 instead of 301-redirecting to the new equivalent.
Lost metadata. Title tags, meta descriptions, and structured data don't carry over to the new platform.
Indexing gaps. Robots.txt accidentally blocks the new site, or noindex tags persist from the staging environment.
Performance regressions. New site loads slower than old, Core Web Vitals scores drop, mobile experience degrades.

Each one is preventable with explicit checks. The checklists below cover all four.

The 30 Days Before Migration

The most important work happens before migration day. Three checklists:

Inventory the existing site:

Export a full list of indexed URLs from Google Search Console: Performance → Pages, export all pages with impressions over the past 12 months
Crawl the existing site with a tool like Screaming Frog or Sitebulb. Export the full URL list with status codes, titles, and meta descriptions
Identify the top 50–100 pages by impressions. These are the highest-priority pages for redirect mapping and metadata preservation
Pull the top 100 inbound links from GSC: Links → Top linking pages. These are the URLs that absolutely must redirect correctly

Plan the redirect map:

For every old URL on the existing site, identify the new URL it should map to
Old URLs without a clear new equivalent should redirect to the most relevant new page (not the homepage)
Build the redirect map as a spreadsheet with columns: old URL, new URL, redirect type (almost always 301), priority
Plan for at least 1.5x the URLs you initially identified — staging crawls often miss pages

Pre-stage the new site:

Build the new site at a staging URL with noindex and password protection
Verify every top-50 page has appropriate metadata configured: title tag, meta description, canonical URL, OpenGraph image
Confirm structured data is configured on the new platform (Article schema, Product schema, LocalBusiness schema as applicable)
Test the redirect logic with at least 20 sample URLs from the redirect map

The Week of Migration

Five days out:

Re-crawl the existing site to catch any pages added since the inventory crawl. Add them to the redirect map
Verify the new site's robots.txt is configured correctly for production (will allow crawling) and that noindex tags are scoped only to the staging environment
Set up monitoring: GSC for both old and new domains (if changing domain), GA4 for the new site, log monitoring for 404 spikes
Notify stakeholders. Migration is not a quiet weekend job. Operations, customer support, and marketing should know the timing

Two days out:

Run the redirect map through a redirect checker to verify the logic. Tools like Screaming Frog can batch-test redirects
Confirm the new site's XML sitemap is generated and accessible at the standard path (/sitemap.xml)
Verify Google Analytics 4 tracking is firing on the new staging site

One day out:

Final QA pass on the new site. Top 20 pages, manually checked
Confirm DNS propagation strategy. If changing hosts, plan the DNS change for low-traffic hours
Backup the old site completely. You may need to roll back if migration day goes wrong

Migration Day

The migration itself happens in a specific order. Don't shortcut the sequence:

Take the old site live as-is until the new site is verified live. Don't break the old site before the new one is confirmed working.
Deploy the new site. Remove noindex and password protection. Verify the production version loads correctly.
Activate the redirect map. Either via server-side configuration (Apache .htaccess, Nginx config, platform-level redirects) or via the new platform's redirect manager (Webflow, WordPress, Shopify all have these).
Test the top 20 redirect mappings manually. Type old URLs into a browser. Verify they 301-redirect to the correct new URLs. Verify the new URLs return 200 with the correct content.
Submit the new sitemap to Google Search Console. Sitemaps report → Add a new sitemap.
Submit a Change of Address in GSC if you're moving to a new domain. Settings → Change of address. This is the official signal to Google that domain authority should transfer.
Run a fresh crawl of the new site. Screaming Frog or Sitebulb. Look for 404s, broken internal links, missing canonical tags, missing metadata. Fix anything found before end of day.

The First 7 Days After

Daily checks for the first week:

GSC Coverage report. Watch for spikes in errors, especially "Soft 404" and "Excluded" categories
GSC Performance report. Compare the new site's impressions against the prior week's baseline. Some drop is normal during reindexing
GA4 sessions. Watch the trend. A 10–20% session drop in the first 3 days is normal as the new URLs propagate. A 50%+ drop is a problem
Server logs for 404 spikes. Pages that show many 404s are URLs missing from the redirect map. Add them
Manual checks of high-priority pages every day. Top 20 pages, top 10 inbound link targets

For the broader question of how to read GSC during a migration window, see How to Read GSC's Search Appearance Report.

The First 90 Days After

Weekly checks for the first 90 days:

GSC Coverage report. Track the "Indexed" page count vs. the pre-migration baseline. Recovery to baseline typically takes 30–60 days
GSC Performance report. Total impressions and clicks should recover to within 90%+ of pre-migration levels by day 30. Faster recovery is possible; slower recovery suggests an unresolved issue
GA4 organic sessions. Same trend. Compare against pre-migration baselines weekly
Top 10 keywords by rank. If specific high-value rankings dropped, investigate the corresponding pages for missing metadata or redirect issues
Backlink retention. Pull GSC's Top linking sites report monthly for the first 3 months. Inbound links to old URLs should be flowing through the 301 redirects to new URLs

By day 90, traffic should be at or above pre-migration levels. If it's still 20%+ below, the migration has unresolved issues — typically broken redirects on inbound-link URLs or missed metadata on high-traffic pages.

For more on the timeline patterns, see How Long Does SEO Take? What the Data Shows.

Common Migration Disasters and Recovery

Five disasters Brass-SEO has seen most often:

Robots.txt left at staging configuration. Site goes live with User-agent: * / Disallow: /. Google de-indexes everything within a week. Recovery: fix robots.txt, request re-crawl in GSC. Full recovery usually 30–60 days.
Redirect chain instead of single redirect. Old URL → intermediate URL → new URL. Each chain hop loses a small amount of link equity. Recovery: collapse chains to single 301 redirects.
301 redirects done as 302 (temporary). 302s don't pass link equity. Recovery: change all migration redirects to 301 in the server or platform config.
Lost meta descriptions on hundreds of pages. The new platform doesn't migrate the meta description field. Pages show Google-generated snippets instead of curated meta descriptions. Recovery: bulk-import metadata from the old site's export.
Sitemap submitted with old URLs. New sitemap accidentally points to old URLs. Recovery: regenerate sitemap from new platform, resubmit to GSC, request re-crawl.

Each one is recoverable. None should happen if the checklists above are followed.

For the broader Brass-SEO approach to post-migration page audits, see Brass-SEO page audits. To run a pre-migration audit on your current site, start a trial.

Frequently Asked Questions

Should I migrate during a low-traffic period?

Yes when possible. Off-hours migration reduces user impact. Off-season migration (for seasonal businesses) limits the revenue exposure of any unexpected issues. Avoid migrating during peak revenue periods.

How long should I keep old redirects active?

Indefinitely for high-traffic and high-link-equity URLs. The cost of maintaining 301 redirects is trivial; the cost of losing inbound link equity from a removed redirect is significant. Some businesses keep migration redirects active for the life of the new site.

What if I'm changing domains as well as platforms?

The work doubles in complexity. Add Change of Address in GSC for the domain change, plus all the standard migration checklist items. Plan for a longer recovery window (90–120 days instead of 30–60). Consider migrating the platform first and the domain second (or vice versa) rather than both at once.

Does Brass-SEO help with migration?

Brass-SEO surfaces post-migration traffic data and helps identify pages losing traffic so you can investigate redirect or metadata issues quickly. It doesn't execute the migration itself. For active migration planning, use Brass-SEO alongside dedicated migration tools (Screaming Frog for crawling, GSC for monitoring).

What's the biggest mistake teams make on migration day?

Cutting the QA pass short to hit a launch deadline. Migrations that ship at 70% QA-complete reliably produce post-launch traffic disasters that take months to recover. Delay launch by 2–4 days if needed to finish QA. The delay is cheaper than the recovery.