Broken Links After a Site Migration: A Recovery Playbook

The first week after any site migration is when broken links emerge en masse. The replatform looked clean in staging, the redirects mostly worked, but now Google Search Console is flagging 404s, customers are emailing about dead pages, and your rankings are sliding for queries you used to own. This playbook is the order of operations we have seen work most reliably when you discover this situation on day three after launch.

The first 48 hours: crawl your own site

Before you touch a single redirect, crawl your own production site end-to-end with whatever tool you use. The internal broken-link map is your single source of truth. Most post-migration link rot is internal — old navigation, old footer links, old in-content links — not external 404s. Fixing internal links is fast and high-impact and you can do it before you have any data on external traffic loss.

Reconcile against the redirect map

If your migration included a redirect map (it should have), pull a fresh crawl of every old URL and check it lands somewhere sensible. The two failure modes are: redirects that work but land on irrelevant pages (Google treats these as soft 404s), and redirects that 301 to URLs that themselves 301 again (Google follows three or four hops at most). A spot-check against the redirect map catches both.

Use Search Console for ranked-page priority

After the internal pass, use Google Search Console to identify which 404s are pages that were ranking. A 404 on a page nobody linked to or visited is a triage problem, not a crisis. A 404 on a page that drove 5,000 monthly clicks last quarter is a fire. Prioritise the ranked URLs ruthlessly — restore content or redirect to the closest semantic equivalent, and do it the same day.

Audit outbound links you did not control

Migrations often break outbound links — your old "trusted sources" section might link to articles that have moved or been removed. While you are doing the internal pass, also flag outbound 404s. These do not directly hurt ranking, but they hurt user trust and they sometimes accumulate into a helpful-content signal over time.

Set up a 30-day watch

Most migration link issues surface within the first month. Set a 30-day reminder to re-crawl and re-check Search Console. By day 30, you should be at or below your pre-migration broken-link baseline. If you are still above it, the migration did not finish cleanly and you have a bigger problem than link rot.

Tooling that pays for itself during a migration

You can do this whole playbook with free tools and Search Console, but a continuous broken-links checker running in the background catches issues hours after they appear rather than weeks later, which during a migration is the difference between a 24-hour incident and a 6-week recovery. The marginal cost is low and the saved time is genuine.

What this playbook does not cover

This is specifically about the link layer of a migration. The content-quality layer, the schema layer, the canonical-URL layer all have their own playbooks. A clean broken-links recovery is necessary but not sufficient for a successful migration — if you have lost rankings and the link audit comes back clean, the problem is elsewhere and you need to widen the investigation.

For teams approaching a migration soon, the leverage point is doing this work in staging before launch. The same playbook applied two weeks before go-live catches 80% of the post-launch issues before they ever go live. UtilitySEO and similar tools all support staging-environment auditing if you set up the right authentication.