Most traffic drops after a migration are not caused by the migration itself. They are caused by skipped steps: a redirect map that missed a few hundred URLs, a staging environment that quietly got indexed, metadata that did not carry over, internal links that still point to the old structure, or analytics tracking that was firing on staging but not production. Each of those is preventable. Each of them costs months of recovery when missed.

This checklist is the one I run when migrating a site, whether it is a redesign on the same CMS, a full replatform, a domain change, or a restructuring of URLs. It is sequenced intentionally. Each phase depends on the work completed in the phase before it. If you skip ahead, you will introduce gaps that show up later as ranking losses or broken tracking that is harder to diagnose after the fact than to prevent up front.

Main Takeaways

  • The single most important deliverable in any migration where URLs are changing is a complete, accurate redirect map. A missing redirect means a URL that held authority, ranking history, and backlinks starts from zero on the new site.
  • Capture baseline data (rankings, traffic, indexation, Core Web Vitals) at least a week before launch. Without it, you cannot tell what recovered and what didn’t.
  • Staging must be invisible to Google. If staging gets indexed, even partially, you create a canonicalization mess that persists after launch.
  • The pre-migration work is where most of the SEO value gets protected. The post-migration work is mostly monitoring and verification. Most of what could go wrong was either prevented or introduced before launch.

How to Use This Checklist

This is two checklists, sequenced. The pre-migration checklist runs from initial planning through the moment before you push live. The post-migration checklist picks up at launch and carries through the first six to eight weeks of recovery. Do not begin a phase until the previous phase is fully complete. Do not launch until every item in the Phase Four launch gate is checked off.

Phase One: Live Site Prep

1.1 URL Inventory

A complete and accurate URL inventory is the foundation of the entire migration. Every downstream decision about what redirects, what gets migrated, and what gets retired depends on this list being comprehensive. Crawls and sitemaps alone are not a sufficient source of truth.

  • Export all URLs directly from the CMS database or backend. A database export captures what a crawl or sitemap might miss:
    • Thank you pages and confirmation pages (post-form submission, non-linked)
    • Noindex pages that exist but are excluded from crawls
    • Orphaned content: pages with no internal links pointing to them
    • Password-protected or gated pages
    • Draft pages or staging holdovers accidentally published
  • Supplement the database export by crawling the live site with Screaming Frog and cross-referencing the XML sitemap. Flag any discrepancies between the three sources.
  • Build a URL inventory spreadsheet to use as the source of truth.

1.2 Baseline Data Capture

Pull these snapshots at least one to two weeks before the migration starts. Pulling them on launch day risks the data already reflecting pre-launch testing or content changes.

  • Acquisition, engagement, and conversion data from GA4
  • Query and landing page data from Google Search Console
  • URL Inspection report for indexation from GSC
  • Keyword rank tracking data
  • Citation and brand visibility from your preferred vendor (consider using Bing Webmaster’s Copilot data as a supplement)
  • Server log files for crawling data
  • Core Web Vitals and PageSpeed Insights scores

Store all baseline data with a clear date stamp in a shared location. You will reference this repeatedly post-launch.

1.3 Audit and Clean Up

Fix what you can on the current site before migrating anything. Carrying technical debt to a new domain or platform will delay the recovery from expected performance volatility.

Crawl the live site with Screaming Frog and export all issues. Look for:

Crawl and rendering errors:

  • Non-200 internal and external links
  • Orphaned content (zero internal links found via export or sitemap)
  • Resources and pages blocked by robots.txt
  • Important content, links, or metadata that relies on JavaScript
  • Redirect loops
  • Crawling of erroneous URLs produced from site search or other bot-related parameters

On-page issues:

  • Duplicate or missing title tags, meta descriptions, and H1 tags
  • Incorrect header hierarchy
  • Image issues (alt text, file size, format)

Indexation issues:

  • Incorrect noindex tag or canonical usage
  • Soft 404s
  • Over-indexation on non-organic pages
  • Any issues from the URL Inspection report

URL consistency issues:

  • HTTP vs HTTPS inconsistency
  • www vs non-www inconsistency
  • Trailing slash inconsistency (/page vs /page/)

Content issues:

  • Thin content: pages with no meaningful traffic, no backlinks, and minimal content. Mark for consolidation or retirement.
  • Duplicate or near-duplicate pages covering the same topic. Consolidate before migrating.

Log all deferred issues with an assigned post-migration owner. Anything not fixed now must be explicitly tracked.

1.4 Redirect Map

The redirect map is the most critical SEO deliverable in a migration when URLs are changing. A missing redirect means a URL that held authority, ranking history, and backlinks starts from zero on the new site. Every URL in the inventory must have a documented disposition before staging build begins.

  • Use the migration content audit process to identify the list of URLs that need to be redirected during the migration. This map will not include URLs that will stay the same or pages that will be retired and not carried over (those should return 410s).
  • Set up a spreadsheet with three columns at minimum: old URL, new URL, HTTP status code.
  • Make sure the status code is set to 301, signaling a permanent address change. 302s are seen as temporary, meaning a search engine will wait on consolidating signals because it believes the original address is coming back at some point. (For a refresher on what each status code does, see the non-technical guide to HTTP status codes for marketers.)

1.5 Content and Metadata Archival

A full archive of the current site’s content and metadata serves two purposes: it is a reference during the staging build to ensure nothing is missed, and it is the QA benchmark used in Phase Three to confirm content parity. Store it before anything on the live site is touched.

  • Export the full CMS database (SQL dump or CMS-native export)
  • Export all media files (images, PDFs, videos, audio) with folder structure preserved
  • Export a metadata snapshot: title tags, meta descriptions, canonical tags, slugs, alt tags, and schema per URL. A custom crawl script may be needed to pull the actual JSON scripts for structured data. Screaming Frog can handle all metadata-related items.
  • Export all existing redirect rules from the current platform
  • Make note of all plugins, tracking scripts, and integrations
  • Store everything in a shared, timestamped location accessible to the full project team
  • Consider keeping the current server environment live (noindexed) for 30 days post-launch as an emergency rollback option

Phase Two: Staging Site Build

2.1 Environment Setup

The staging environment must be completely isolated from Google before any content is built on it. If staging gets indexed, even partially, Google may crawl and rank incomplete pages and create a canonicalization mess that persists after launch.

  • Password-protect the staging environment using HTTP basic auth (preferred over robots.txt blocking alone)
  • Confirm staging cannot be accessed by Googlebot. Verify that the auth prompt appears in an incognito browser.
  • Use a separate subdomain for staging (staging.domain.com) rather than a subfolder of the live site
  • Do not copy the production robots.txt to staging. Staging needs its own file with Disallow: /
  • Ensure hosting, SSL certificate, and DNS are in place for the new platform
  • Confirm the team has a documented rollback plan. The staging environment should remain accessible for at least 30 days after go-live.

2.2 Content Migration

Content migration is where the most SEO value is at risk of being accidentally dropped. Metadata, schema, alt text, internal links, and canonical tags do not migrate automatically. Each must be explicitly carried over and verified. Use the Phase One archive as the reference throughout.

Set up proper categorization and tagging structures before bulk-migrating content. This includes any taxonomies that organize how content is grouped: blog categories and tags, product categories, service types, location pages, course catalogs, or any other classification system the site uses.

Migrate all pages designated “keep” in the URL inventory to their new URLs per the redirect map. For each page, confirm the following has been carried over:

  • Page content: body copy, headings (H1, H2, H3), and formatting
  • Title tag and meta description
  • Open Graph tags (og:title, og:description, og:image) and Twitter card tags
  • Canonical tag (must point to the new URL, not the old one)
  • Schema markup (update all @id and URL values to reflect new URLs)
  • Images and media files (served from the new domain or CDN, not hotlinked from the old site)
  • Image alt text
  • Internal links updated to new URLs per the redirect map (do not rely on redirects here)
  • External links verified as still resolving correctly

Confirm navigation elements are fully migrated and accurate:

  • Primary navigation with all links pointing to new URLs
  • Secondary navigation and utility nav
  • Footer links
  • Breadcrumbs (confirm structure reflects new IA, not old)

Confirm schema types are in place for all applicable page types:

  • Organization (homepage)
  • Article or BlogPosting (content pages)
  • BreadcrumbList (if breadcrumbs are rendered)
  • FAQPage (if FAQ sections exist on the page)
  • Industry-specific types as applicable (Product, Service, Course, LocalBusiness, Event, Recipe, etc.)
  • ProfilePage (author bios, team pages, expert contributors)

Validate all schema on staging using Google’s Rich Results Test before QA begins.

2.3 Analytics and Tracking Implementation

Install and test all tracking on staging so you can confirm everything works before launch. Use a staging-specific analytics property or suppress data from staging to avoid polluting production reports. Production analytics confirmation is a Phase Four launch gate item.

  • Install Google Tag Manager on the staging site. Confirm the GTM snippet is present in the page head on all templates.
  • Set up a staging-specific GA4 property (or use debug view). Do not send staging traffic to the production GA4 property.
  • Verify GA4 pageview events fire correctly on staging using GTM Preview mode and GA4 DebugView
  • Verify all conversion events fire as expected: form submissions, CTA clicks, and any ecommerce events
  • Confirm that Google Search Console and Bing Webmaster Tools are set up properly. The new URLs won’t collect any data before the migration, but the properties need to be in place.
  • Confirm all marketing and third-party pixels are installed and firing:
    • Meta (Facebook) Pixel
    • LinkedIn Insight Tag
    • HubSpot tracking code
    • Any other platform-specific tags
  • Verify heatmap and session recording tools are installed (Hotjar, Microsoft Clarity, etc.)
  • Test all form submissions and automation flows end to end on staging:
    • Form submission triggers confirmation email or thank you page
    • Form submission delivers the record to the CRM or marketing platform
    • Any membership, gating, or paywall functionality works as expected
  • Confirm that data is flowing from your analytics platforms to your preferred data warehouse (BigQuery, Snowflake, Databricks, etc.)

Note: Analytics is tested in Phase Two but confirmed as a launch gate in Phase Four. Production GA4 and GSC properties must be verified live and firing correctly before calling the migration complete.

Phase Three: Staging Site QA

3.1 Compare Live vs. Staging Crawls

A side-by-side crawl comparison between the live site and staging is the most systematic way to catch migration gaps at scale. Screaming Frog’s Compare Crawls feature surfaces differences in metadata, status codes, canonical tags, and more across every URL simultaneously, catching issues that page-by-page QA would miss.

  • Crawl the live site with Screaming Frog and save the results
  • Crawl the staging site separately
  • Use Screaming Frog’s Compare Crawls feature to surface differences between the two:
    • Title tag changes or losses
    • Meta description changes or losses
    • H1 changes or losses
    • Canonical tag changes or losses
    • Status code changes (e.g., pages that were 200 now returning 404)
    • Word count drops (may indicate content was truncated or lost during migration)
    • Schema markup presence changes
  • For more advanced QA, use vector embeddings and semantic similarity scores to catch pages with content differences that aren’t obvious in metadata. If staging and live URL pairs score lower than a 1, review the Screaming Frog data or check the content manually.
  • Review and resolve all flagged discrepancies before proceeding to redirect testing

3.2 Mobile and Rendering QA

Google uses mobile-first indexing, meaning the mobile version of your pages is what gets evaluated for ranking. Rendering issues that look fine on desktop can silently kill rankings if they result in content being hidden, truncated, or inaccessible on mobile.

  • Test all key page templates on mobile: homepage, a blog or article template, a primary product or service page, a collection page, and any conversion landing pages
  • Check on both iOS (Safari) and Android (Chrome). Rendering differences between them are common and worth catching before launch.
  • Use Chrome DevTools device emulation for a fast initial pass, then follow up with real device testing on priority pages
  • Confirm the following on each tested template:
    • Text is legible without zooming
    • No content is hidden, cut off, or visually overlapping
    • Navigation is usable and accessible (hamburger menus, dropdowns, etc.)
    • Images scale correctly and are not oversized or broken
    • Buttons and tap targets are large enough to interact with reliably
    • Forms are functional and inputs are usable on a touchscreen
    • No horizontal scroll on any template
    • Hover-state interactions from desktop have appropriate mobile equivalents
  • Check that no critical on-page content is loaded via JavaScript in a way that Googlebot cannot render. Use the URL Inspection tool in GSC to view Googlebot’s rendered version of key pages once the site is live. Screaming Frog’s JavaScript rendering can also be used to quickly tab through pages.

3.3 Redirect Testing

The redirect map was built in Phase One but it must be tested against the staging environment, not just assumed to be correct. A redirect that returns a 302 instead of a 301, that chains through an intermediate URL, or that resolves to the wrong page will bleed link equity even if the map document looks accurate.

  • Upload the complete redirect map to the staging environment
  • Use Screaming Frog to bulk-test the entire redirect list against staging:
    • Upload old URLs as a custom list and crawl
    • Confirm every old URL returns a 301 (not 302, not a chain, not a loop)
    • Confirm the final destination URL matches the intended new page in the redirect map
  • Manually spot-check the 20 to 30 highest-value URLs (highest backlink count or organic traffic) in a browser
  • Test edge cases that often break redirect logic:
    • Uppercase URL variants (/Page vs /page)
    • Trailing slash vs no trailing slash variants
    • www vs non-www variants
  • Resolve any chains, loops, or incorrect destinations before proceeding to the link audit

Even if internal links were updated during the staging build, a link audit at QA catches anything that was missed. Since URLs are changing in this migration, any internal link still pointing to an old URL becomes a redirect hop post-launch or a broken link if there is a gap in the redirect map. Find and fix them now.

  • Crawl the staging site with Screaming Frog and export all internal links pointing to non-200 response code pages
  • Filter for any internal links still pointing to old-domain URLs or old URL structures and update them to the direct new URL
  • Check locations commonly missed during migration builds:
    • Navigation menus (primary, secondary, utility, mobile)
    • Footer links
    • Breadcrumb links
    • In-content CTAs and anchor text links
    • Image src attributes and image links
    • Hardcoded links inside page builder blocks (Elementor, Divi, Gutenberg). These often do not appear in CMS exports.
    • Sidebar and widget links
  • Export all external links from the staging crawl and verify they still resolve correctly. Flag any broken external links for cleanup.
  • Export referring domain data from Ahrefs or SEMrush for the top priority URLs. Note any external sites linking to old URLs that would benefit from a direct update post-launch. Link equity passes through redirects, but direct links are always preferable.

Phase Four: Launch Gate

Do not launch until every item below is confirmed. If any item cannot be confirmed, the launch should be delayed.

Phase One sign-off:

  • Complete URL inventory exported from the database and finalized
  • Baseline metrics captured and stored with date stamp
  • Live site technical issues audited and prioritized (critical issues resolved)
  • Redirect map complete, reviewed by SEO team, and signed off
  • Full content and metadata archive stored in a shared location

Phase Two sign-off:

  • Staging environment confirmed non-indexable (auth wall tested)
  • All pages migrated with metadata, schema, alt text, canonicals, and links in place
  • Schema validated via Google’s Rich Results Test
  • Navigation, footer, and breadcrumbs confirmed accurate
  • All tracking and pixels confirmed firing on staging
  • All forms and automation flows tested end to end

Phase Three sign-off:

  • Screaming Frog Compare Crawls complete with all discrepancies resolved
  • Content parity confirmed on all high-value pages
  • Mobile rendering tested across key templates on real devices
  • All redirects returning 301 to correct destinations (bulk tested and spot-checked)
  • Internal link audit complete with no links pointing to old URLs

Launch day prep:

  • Production robots.txt confirmed to allow crawling of all new pages (no Disallow: / at the top level)
  • Production robots.txt references the sitemap URL: Sitemap: https://domain.com/sitemap.xml
  • XML sitemap validated and confirmed to reflect final production URLs only, not staging. Dynamically generated sitemaps should auto-update but confirm generation is working correctly.
  • Google Search Console property tracking in place
  • Bing Webmaster Tools property tracking in place
  • Production GA4 property confirmed active and firing correctly (not the staging test property)
  • All production pixels and tracking tags confirmed live post-launch
  • Migration planned for a low-traffic window
  • Rollback plan is documented and the full team knows the procedure
  • Launch date and time annotated in reporting tools

This checklist picks up immediately after the site goes live. Phase One covers launch day. Phase Two is a full audit that should begin within the first 24 to 48 hours. Phase Three covers ongoing monitoring as the site recovers and stabilizes.

The depth here is shallower than pre-launch on purpose. If the pre-migration checklist was executed thoroughly, there should be no major surprises. Most of what follows is monitoring, verification, and cleanup rather than discovery.

Phase One: Launch Day

1.1 Annotate the Launch

Before doing anything else, document that the migration happened. An annotation in your reporting tools gives you a clear reference point for before and after comparisons. Without it, you are trying to interpret performance data without knowing where the inflection point is.

  • Add an annotation in GA4 with the exact launch date and time
  • Add the same annotation in any other reporting tools (GSC, rank tracker, etc.)
  • Log the launch in whatever project management or communication tool the team uses so there is a shared record

1.2 Submit Sitemaps

If the domain is changing, use the GSC Change of Address tool. If only URLs are changing, submitting the updated sitemap is the fastest way to signal that new URLs exist and are ready to be crawled.

  • Submit the updated XML sitemap to Google Search Console
  • Submit the updated XML sitemap to Bing Webmaster Tools
  • Confirm the sitemap URL is accessible and returns valid XML before submitting
  • If the sitemap is dynamically generated, confirm it is already reflecting new production URLs and not staging URLs

Note: If your CMS allows it, don’t immediately remove the old URLs from your sitemap. This increases the chance of Google finding the redirects and dropping the old pages from its index. You want to show crawlers that your addresses have changed. Once the old URLs have fallen out of the index, then you can remove those pages from your sitemaps.

1.3 Confirm Redirects Are Live

Confirm that the redirects that worked in staging are working in production. Spot-check your highest-value URLs the moment the site goes live, before Google has a chance to crawl them.

  • Manually test the 10 to 15 highest-priority old URLs in a browser and confirm they land on the correct new pages
  • Confirm each returns a 301, not a 302, not a chain, and not a 404
  • Test at least one URL from each major URL pattern or folder that changed structure
  • If any redirect is broken or incorrect, fix it immediately before moving on

1.4 Confirm Tracking Is Firing in Production

Staging analytics were set up on a test property to avoid polluting production data. Now that the site is live, you need to confirm that the production property is receiving data correctly. A gap in analytics data during a migration makes post-launch analysis harder.

  • Open GA4 Realtime report and confirm pageview events are recording live traffic
  • Use GTM Preview mode on the production site to verify all tags are firing correctly
  • Confirm the GA4 script is sending data to the production property, not the staging test property
  • Trigger a test form submission and confirm the conversion event fires and the record reaches the CRM
  • Spot-check that all other marketing pixels are active (Meta, LinkedIn, HubSpot, etc.) using a tag auditing tool or browser extension such as Tag Assistant or Pixel Helper

Phase Two: Immediately Post-Launch

This audit should begin within 24 to 48 hours of launch. Map out each issue and prioritize by level of impact and effort before assigning in a sprint. Critical items should be addressed immediately. Low-priority items can be handled weeks to months after the migration.

2.1 SEO and AEO Audit

The staging QA in Phase Three of the pre-migration checklist covered this ground thoroughly. The goal here is not to repeat that process from scratch, but to catch anything introduced during the launch itself or that behaves differently in the live environment than it did in staging.

  • Run a full Screaming Frog crawl of the live site and use the Compare Crawls feature against the staging crawl to surface any new discrepancies
  • Cross-reference against the pre-migration baseline crawl as a second reference point
  • Look specifically for issues that production can introduce that staging cannot: server configuration differences, CDN caching behavior, CMS output differences, and redirects resolving differently than expected
  • Check GSC’s Pages and Coverage reports for any crawl or indexation errors Google has already surfaced. Use the URL Inspection tool to confirm URLs are crawlable, indexable, and rendering correctly.
  • Do not limit the review to known issues from staging. Look for net-new problems: pages that should not be indexable, broken templates that only appear under real server conditions, schema errors surfaced by GSC’s live crawl, or any URL patterns that were not present in staging at all.

2.2 UX and Rendering Review

A migration is also an opportunity for something to go wrong visually that does not show up in a crawl. Walk through the live site on real devices and confirm the experience is clean across mobile responsiveness, design, navigation, and interactivity.

  • Review all key page templates on desktop and mobile on the live production site
  • Check for layout issues, broken images, overlapping elements, or fonts not loading correctly
  • Test on both iOS Safari and Android Chrome
  • Submit key pages to the URL Inspection tool in GSC and view the rendered screenshot to confirm Googlebot sees the page the same way a user does
  • Check that forms, CTAs, and interactive elements work correctly in the live environment
  • Confirm page speed is acceptable on the live server. Run Lighthouse in Chrome DevTools on the homepage, a content page, and a key conversion page.

2.3 Deeper Analytics Review

The launch day spot check confirmed that tracking was firing and data was recording. This review goes deeper, now that there is real traffic and real user behavior to work with.

  • Review channel attribution in GA4 and confirm traffic is being bucketed correctly. Organic, direct, and referral splits should look reasonable relative to baseline. An unexpected spike in direct traffic often indicates a tagging or referral exclusion issue.
  • Audit event firing across all key interactions: form submissions, CTA clicks, scroll depth, and any custom events. Use GTM Preview mode on the live site to step through each one.
  • Confirm conversion data is flowing correctly from GA4/GSC into any downstream platforms such as your data warehouse, Looker Studio, or your rank tracking setup
  • Compare the first 48 hours of post-launch data against the equivalent pre-migration window and flag anything that looks structurally off. Lower volume is expected during this window. Structural anomalies in attribution or event firing are not.

Phase Three: Ongoing Monitoring

Some volatility after a migration is expected. This phase is about watching the right signals and knowing the difference between normal recovery and something that needs intervention.

3.1 Crawling and Indexation Monitoring

What you are watching for is the recovery trend, not the dip itself.

  • Check GSC’s Pages and Coverage reports weekly for the first month to track how many new URLs have been indexed
  • Monitor for unexpected spikes in 404 errors, which can indicate redirect gaps
  • Watch for old URLs that are slow to drop out of the index. If they have not fallen off within four to six weeks, confirm the redirects are returning 301s correctly.
  • Once old URLs have fully dropped out of the index, remove them from the XML sitemap
  • Check GSC’s Crawl Stats report for any drops in pages crawled per day or spikes in crawl errors

Redirects pass link equity, but a direct link to the correct new URL is always preferable. This is worth doing for your highest-value pages but is not urgent.

  • Export referring domain data for your top old URLs from Ahrefs or SEMrush
  • Reach out to the highest-value referring sites and request they update to the new URL
  • Monitor for any backlinks returning errors rather than resolving through the redirect, which may indicate a gap in the redirect map

3.3 Performance Recovery

Compare against the pre-migration baseline captured in Phase One of the pre-migration checklist.

  • Monitor GSC and GA4 data regularly, including clicks, impressions, average position, and conversions
  • Report on combined old plus new URL performance together, not in isolation
  • Flag any pages that have not begun recovering after six to eight weeks and investigate indexation, redirects, and content

3.4 Ongoing Optimizations

Once the site has stabilized, shift focus toward improving performance beyond where the old site was.

  • Use GSC combined with third-party tools like Ahrefs or SEMrush to identify keyword and topic gaps where the site has low or no visibility
  • Prioritize refreshing existing content that was ranking before the migration but has been slow to recover
  • Build net-new content targeting gaps identified through keyword research and competitor analysis
  • Pursue off-site coverage through digital PR, link earning, and brand mentions to rebuild and grow authority on the new URL structure