USE CASE · SITE MIGRATION

Verify redirects after a site migration

Site migrations are high-stakes. A single broken redirect can tank a page's rankings overnight. Here's how to verify your redirect mappings and monitor for regressions.

The migration redirect workflow

1. Before migration: baseline check

Import your old sitemap.xml into a batch check. Export to Google Sheets. This is your "before" snapshot -- the URLs that need to keep working.

2. After migration: verify mappings

Run the same batch again. Every old URL should now redirect (301) to the correct new URL. Filter for 404s (broken), 302s (should be 301), and chains (inefficient). Export to the same Google Sheet for side-by-side comparison.

3. Post-migration: monitor for regressions

Set up a monitor on your top 100 old URLs. Check every hour for the first week, then daily for a month. If a redirect breaks (deployment overwrites the config, CDN cache expires, etc.), you'll catch it immediately.

4. Reporting: share with stakeholders

Share batch results via a public link, or send the Google Sheet to your client or manager. Every URL is listed with its redirect chain, status codes, and final destination.

Common migration issues we catch

Pro tip: Run Compare User Agents on your top 10 pages before and after the migration. Some CDNs and load balancers serve different redirects to bots vs browsers, which can cause Googlebot to index the wrong destination.

API integration for CI/CD

Add a redirect verification step to your deployment pipeline. After each deploy, the API can batch-check your critical URLs and fail the build if any redirects are broken. Use a webhook to notify Slack when the check completes.

Prepare for your migration

Start with a baseline batch check of your old sitemap, then re-run it after the cutover.

Sign up