GUIDE

Site Migration Redirect Checklist

Missing or broken redirects are a common cause of post-migration traffic loss, and they are one of the few migration risks a QA process can catch before launch. This checklist covers URL inventory, mapping validation on staging, launch-day verification, and post-launch monitoring.

The stakes are real. A launch that ships with 404s where 301s should be will drop rankings on those pages until they resolve. The size of the drop depends on how many URLs miss, how much traffic they carried, and how fast search engines recrawl. This checklist reduces the odds of missing a URL.

Phase 1: Before migration

Build your URL inventory

You need a complete list of every URL on the current site. Do not rely on memory. Pull from multiple sources:

Sitemap.xml is the starting point, but it rarely includes everything.
Google Search Console exports all indexed URLs, including pages missing from your sitemap.
Analytics and server logs catch pages that receive traffic but live nowhere else.
A site crawl finds orphan pages and JavaScript-rendered URLs.

Create your redirect mapping

For every old URL, determine the correct new URL. Two columns: old URL and new URL. Do not default to redirecting everything to the homepage. Google treats that as a soft 404 and you lose all ranking value for those pages.

Tip: Before finalizing, validate your URL mapping against your staging environment to catch issues before launch.

Check existing redirects

Your current site likely already has redirects. If old-page-1 already redirects to old-page-2, your new mapping needs to send old-page-1 directly to the new equivalent of old-page-2. Otherwise you create a chain.

Document high-traffic pages

Identify your top 50-100 pages by organic traffic and backlinks. These are the pages where mistakes hurt the most. Give them extra attention during QA.

Phase 2: Test on staging

Import old URLs into the batch checker, pointing at your staging domain.
Compare destinations against your mapping spreadsheet. Every old URL should land on the right new URL.
Filter for problems: 404s (missing redirects), chains (2+ hops), loops, 302s that should be 301s.
Fix and re-run until everything passes. See our guide on bulk testing 301 redirects for more detail.

Test all four URL variations

For important URLs, test http/https and www/non-www versions. Each should reach the same final destination in as few hops as possible. See our HTTPS audit and www vs non-www guides.

Phase 3: Launch day

Verify immediately after cutover

As soon as DNS propagates, run your batch check again against production. Do not assume staging matches production. CDN settings, server configs, and DNS-level redirects can all differ.

Spot-check top pages

For your top 20-30 pages, check each one individually. Confirm: the redirect fires (not a 404), the destination is correct, the status is 301, and there is only one hop.

Submit the new sitemap

Submit your updated sitemap.xml to Google Search Console. Remove the old sitemap if it still references old URLs.

Phase 4: Post-launch monitoring

Set up ongoing monitoring

Use redirect monitoring to automatically re-check your most important redirects on a schedule. Redirects break during server updates, CDN changes, and CMS plugin updates.

Re-check at 1 week, 1 month, 3 months

Run your full batch at these intervals. Redirects break over time as configs change and caches expire.

Do not remove redirects too early. Keep them active for at least 1 year. External links, bookmarks, and cached search results will reference old URLs for months. Many SEOs recommend keeping them indefinitely.

Common migration mistakes

Redirecting everything to the homepage. Google treats this as a soft 404. Each old page needs its own redirect.
Using 302 instead of 301. A 302 tells Google the move is temporary. Use 301 for permanent changes.
Forgetting images and PDFs. If they are indexed, they need redirects too.
Creating chains. Old redirects plus new redirects equals chains. Use the chain checker to find them.
Skipping pagination URLs. Pages like /blog?page=2 or /blog/page/2 are often missed.

For platform-specific guidance, see our WordPress to Shopify redirect checklist.

If you already crawl with another tool, reuse those exports: Screaming Frog, Ahrefs Site Audit, and SEMrush Site Audit all feed the batch checker for full chain, TLS, and user-agent detail.

Verify your migration redirects

Import your URL mapping and run the batch against staging, then production after cutover.