Site Migration Redirect Checklist

Use Screaming Frog, Sitebulb, or a similar crawler to get every URL on your current site. Export the full list. This is your source of truth. Do not skip this — your sitemap.xml is probably incomplete.

Go to Search Console > Pages > View data about indexed pages. Export this list. Cross-reference with your crawl. Google may have indexed URLs your crawler missed (orphan pages, old content).

Use Ahrefs, Moz, or Semrush to export all URLs receiving external backlinks. These URLs are the most critical for redirect mapping — losing their link equity hurts your domain authority directly.

Pull the last 12 months of traffic data from Google Analytics or your analytics tool. Sort by sessions. Your top 100 URLs need extra attention during mapping and testing.

Export your current redirect rules from .htaccess, Nginx config, Cloudflare, your CMS, or wherever they live. These redirects need to be preserved or updated in the new setup. Failing to migrate existing redirects is one of the most common migration mistakes.

Build a spreadsheet with at minimum: old URL, new URL, redirect type (301 for permanent), priority (based on traffic and backlinks), and verification status. Every old URL that will not exist on the new site needs a row.

Map each old URL to the most relevant new URL. Not the homepage — the actual equivalent page. If /services/web-design becomes /solutions/website-design, that is the mapping. Only redirect to the homepage as a last resort when no equivalent exists.

Some old pages will not have a match on the new site. Map these to the closest category page or parent page. If nothing is even close, consider keeping the content or explicitly returning a 410 (Gone) status instead of a redirect to an irrelevant page.

If your current site has URL A redirecting to B and B is being migrated to C, map A directly to C. Do not create A to B to C chains. This is your chance to clean up years of accumulated redirect debt.

Permanent migration means 301 redirects. The only exception is if you plan to revert the change within a few weeks — then use 302. In practice, migrations are permanent. Use 301.

Add your redirect rules to the new site's configuration. The method depends on your stack — Nginx config, .htaccess, Cloudflare Bulk Redirects, CMS redirect plugin, or application-level redirects. Use the method that is most maintainable for your team.

If URL patterns changed predictably (e.g., /blog/ became /articles/), use regex or wildcard rules rather than mapping every URL individually. But test these rules thoroughly — regex redirects are the leading cause of redirect loops.

If you are moving to HTTPS, ensure that HTTP versions of all URLs redirect to their HTTPS equivalents. Use HSTS headers to tell browsers to always use HTTPS. Consider HSTS preload for maximum protection.

Do not rely on redirects for your own site's navigation. Update all internal links to point to the new URLs directly. Redirects should catch external links and bookmarks — your own site should not be sending traffic through redirect chains.

Every page on the new site should have a canonical tag pointing to its own new URL. Update your sitemap.xml to list all new URLs. Remove old URLs from the sitemap.

Use a bulk redirect checker to verify every single redirect. For a migration of any size, manual checking is not feasible. Feed your redirect map into a bulk checking tool and verify that each old URL returns a 301 and lands on the correct new URL.

Deliberately test URL patterns that could loop — especially URLs that match multiple redirect rules. Common loop triggers: HTTPS redirect + www redirect + path redirect all firing in sequence.

Check URLs with query strings, trailing slashes, mixed case, encoded characters, and fragments. These often break redirect rules that work fine for clean URLs.

No URL should require more than one redirect to reach its final destination. If you find chains (301 to 301 to 200), flatten them. Two hops is acceptable in rare cases. Three or more is not.

Deploy to staging and run your full redirect test suite before touching production. Fix issues on staging. Re-test. Only go live when every redirect resolves correctly.

After deploying the new site, re-run your entire redirect test suite on the live production URLs. Do not wait. Do not assume staging results carry over. DNS changes, CDN caches, and production-only configs can change behavior.

Submit your updated sitemap.xml in Search Console. If you changed domains, use the Change of Address tool. This tells Google to start crawling the new URL structure.

Watch your analytics in real time for the first few hours. A sudden traffic drop to specific pages usually means a broken or missing redirect. Fix immediately.

For the first two weeks, check Search Console daily for new 404 errors and crawl issues. Each 404 is potentially a missing redirect. Add redirects as you find gaps.

Compare organic traffic week-over-week for at least 3 months. Some ranking fluctuation is normal after a migration (the "Google dance"), but sustained drops indicate redirect or indexing problems.

Once a month for the first 6 months, re-check that your redirects are still working. Server config changes, plugin updates, and CDN cache purges can silently break redirects.

Do not remove redirects early. Google needs time to reindex, and external sites linking to your old URLs may never update their links. One year is the minimum. Indefinitely is better.