Site migration broken-link validation: catch the 8,000 dead redirects before the client does.

The migration pattern that goes wrong

The story is the same every time. A client decides to move from WordPress to Webflow, or from a custom platform to Shopify, or to consolidate three sub-domains under one. The dev team builds the new site. The team writes redirect rules for the major URLs. The migration ships on a Friday.

Two weeks later, the client emails: "our organic traffic dropped 30%, what happened." The post-mortem reveals the redirect rules covered the top 200 URLs, missed the long-tail 7,800. Those 7,800 URLs are now 404, every backlink pointing to them is dead, every Google ranking they accumulated is gone.

The fix takes weeks of catching up. The client doesn't forget. Most of the damage was avoidable with a pre-flight URL check that the dev team didn't prioritize because it wasn't in scope.

The pre-flight check (before migration)

The starting point is the complete URL inventory of the legacy site. Sources to combine:

• Sitemap. Pull whatever the legacy CMS exposes. Most miss orphaned pages.
• Google Search Console export. Every URL Google has ever indexed for this site. Often 2-5x larger than the sitemap.
• Backlink export from Ahrefs / Semrush / Majestic. Every URL on this site that anyone has linked to externally. These are the URLs whose link equity matters most.
• Server log mining. If the dev team can pull access logs, every URL that's been requested in the last 6-12 months. This catches the long tail.
• Internal navigation crawl. Every URL the site's own internal linking exposes.

Combined and deduped, that's the list. Run it through the checker against the current production legacy site to get a baseline of which URLs return 200 today, which already return redirects, which are dead at present.

The redirect-rule audit

Once you have the legacy URL list, hand it to the dev team building the new site. They write redirect rules. You run a post-flight check on the staging environment with the redirect rules applied: every legacy URL → expected destination on the new site.

The check surfaces:

• URLs with no redirect rule. They return 404 on the new site. The biggest source of post-migration traffic loss.
• URLs with broken redirect chains. Legacy URL redirects to a destination that itself redirects, or worse, to a destination that 404s. Each hop is a chance to lose link equity.
• URLs where the redirect lands on the wrong page. Compare the new destination's page content against the legacy URL's content. A redirect that lands on the homepage when the user expected a product page is technically a 200 but functionally a 404.
• Soft 404s on the new site. Pages that return 200 with no useful content, often a custom "page not found" rendered with status 200. Google treats these as 404s for ranking purposes.

The post-flight check (after migration)

The migration ships. Within 24 hours, run the same legacy URL list against the production new site. Catch:

• Anything that worked in staging but broke in production (different env vars, different redirect ordering, CDN cache issues).
• New errors introduced by load (the new infra works at 1 RPS in staging, surfaces 502s under real traffic).
• URLs the staging redirect map missed.

Then schedule the same check daily for the first month. Catch regressions in real time, before traffic and rankings drop.

The value to the client

For agencies billing the migration as a project, this is the difference between a migration that ends with "you missed 7,000 redirects, our traffic tanked" and one that ends with "here's a report showing 99.4% of legacy URLs resolve correctly on the new site, with the 0.6% remaining flagged for your dev team."

Same migration, different deliverable, different perception of the agency's competence.

Pricing fit

Migration audits are spiky. A 50,000-URL legacy audit followed by daily monitoring for 30 days fits comfortably inside the agency-tier monthly URL pool. For one-off migrations of larger sites (200K+ URLs), the credit-pack model on the standard tier covers it without committing to the agency tier.

For agencies running migrations as a recurring service line, the agency tier with multi-client workspaces means each migration gets its own bucket, history is preserved, and the deliverable for each is branded.

The shape of the deliverable

A typical migration audit report:

1. Cover page. Agency-branded, "Pre-migration audit for [client]" or "Post-migration validation for [client]."
2. URL inventory summary. Total URLs scanned, sources combined, dedup count.
3. Pre-migration baseline. Status distribution on legacy site at time of audit.
4. Redirect-rule coverage. Of N legacy URLs, X have redirect rules, Y are missing.
5. Post-migration validation. What survived, what broke, sorted by link equity if backlink data was provided.
6. Recommended actions. Prioritized list of redirect rules to add or fix.
7. Daily monitoring summary. First 30 days of health, regression detection.