404 Checklist After a Site Migration

12 steps, before and after launch · updated October 2026

A migration breaks URLs at scale. Every old link is a promise — from Google's index, from someone's bookmark, from another site's blog post — and the moment the new site goes live, some of those promises quietly return 404. The damage compounds: crawlers waste their budget on dead ends, link equity evaporates on every broken redirect, and real visitors bounce. This checklist is the order we'd work through, in three phases.

Before launch (or the moment you know a migration is coming)

Crawl the old site while it's still live. Export every reachable URL. This is your baseline — after the old site is gone you can no longer tell "link we broke" apart from "page that never existed." If the old site has a sitemap, start there; a crawler gets you the rest.
Build a 1:1 redirect map. Old URL → closest new equivalent, written down as a table, before any redirect is configured. Content moved to a new path? Map it. Product retired? Map it to the category page. Gaps in the map become your 404s.
Use 301 (permanent), not 302. Permanent redirects pass the signal; temporary ones tell crawlers to keep checking the old URL. Almost nothing about a real migration is temporary.
Never bulk-redirect everything to the homepage. It's tempting — one rule, done. But a homepage redirect for a deep content page is treated as a soft 404 by search engines and as a dead end by the visitor who wanted that specific thing. Redirect to the nearest real equivalent, or let it 404 and fix it properly.
Keep unchanged URLs unchanged. Every URL you don't have to change is a redirect you never have to maintain. Preserve paths where the platform allows, even when it costs a little cleanliness.

Launch day

Test the redirect map on the URLs that matter. Pick your top pages by traffic plus the old URLs with the most external links pointing at them. Each should resolve in a single 301 hop to a live 200 page. Chains (301 → 301 → 200) work, but every extra hop is latency and dilution.
Scan the new site for internal 404s. Templates are built from shared parts — one broken link in a footer, menu, or sidebar is repeated on every page of the site. Manual spot-checks of the homepage will not find these; you need a sitewide pass:

The free scanner reads your sitemap, visits each page it scans (up to 25 free), and lists each 404 with its status code — the fastest way we know to do this step on a site under a few hundred pages.

Check resource 404s too. A page whose stylesheet or main image returns 404 renders broken even though the "page" works, and crawlers record it as an error. A good scan report includes these; eyeballing won't.
Audit canonical tags and social URLs. One of the most common migration misses: pages that copied the old domain into <link rel="canonical"> or og:url. View-source a sample of pages and confirm they point at the new domain.
Update robots.txt and resubmit the sitemap. Make sure the new site isn't accidentally disallowing crawlers, that no sitemap reference still points at the old domain, and submit the new sitemap in Google Search Console (and Bing Webmaster Tools).

Week one

Re-scan daily for the first week. Redirect typos and missed mappings surface as real traffic reaches obscure pages you never thought to test. The free 25-page scan covers small sites — re-running it each day is a two-minute chore.
Watch Search Console's "Not found" report. Every 404 Google reports there is an old URL someone (or some link) is still trying to reach. Recurring patterns — a whole section, a URL-parameter format — deserve a redirect rule, not one-off fixes.

Common questions

How badly do post-migration 404s hurt? Three ways at once: crawl budget spent on dead ends, link equity lost on every broken redirect, and visitor trust spent on every "page not found." Recovery from a botched migration is measured in weeks to months of re-crawling — which is why the pre-launch crawl and redirect map are worth more than anything you do after.

301 or 302 after migration? 301, unless the move is genuinely temporary (a short-lived event page, an A/B test). Search engines treat 302 as "the old URL is still the real one."

What's a soft 404? A page that returns HTTP 200 but shows "not found" content. It's worse than a real 404: visitors see a broken page, and crawlers get mixed signals. Simple link checkers verify status codes; catching soft 404s needs content-level checks (Search Console reports them under Page indexing).

How long should old redirects stay in place? The textbook answer is forever. The practical answer: as long as real traffic and links still arrive. Check your server logs or Search Console — when an old URL hasn't been requested in a very long time, its redirect is a candidate for cleanup, but high-value ones (bookmarks, press links) are cheap to keep.

Want the wider picture — finding broken links on any site, not just after a migration? See the full guide to finding and fixing broken links.