How do I verify redirects after a site migration?

The old sitemap, which gives you the URLs the site advertised. It is the easiest source and the least complete.

A crawl of the old site, taken before the migration where possible. This finds what was linked but never listed.

Server access logs, which are the only record of what was actually requested — including URLs from old emails, external links and bookmarks that no sitemap ever contained.

Search Console's Page indexing report and performance data, which name the URLs search engines know about and the ones that brought traffic.

The union of these four is the real list. Each one alone leaves a category of URL unmapped, and the omissions only surface as 404s weeks later.

The status: a single `301`, not a 302, not a chain, not a 404.

The destination status: following the redirect must reach a `200`, not another redirect and not an error.

The destination content: the equivalent page, not the home page and not a category listing. A redirect to an unrelated page is treated as a soft 404 and helps nobody.

`curl -sIL <old-url> | grep -iE '^(HTTP|location)'` answers the first two. The third needs a human or a comparison of titles.

Test in bulk rather than by sampling. A migration failure is rarely uniform: one template maps correctly and another does not, and a ten-URL sample finds that only by luck.

Chains, where the migration redirect points at a URL that itself redirects — typically through an old HTTP-to-HTTPS or `www` rule that was never folded in.

Everything redirected to the home page, which is fast to implement and loses the connection between old and new pages entirely.

Query strings and trailing slashes dropped by rules that matched the path only, so `/old?ref=email` and `/old/` are not covered.

Case differences, since most servers treat paths case-sensitively and old links are not always lowercase.

Redirect loops between the new canonicalisation rules and the migration rules, which produce an unreachable page rather than a slow one.

Redirects that work for the page but not for its assets, leaving images and stylesheets 404ing on pages that otherwise load.

Not everything has a successor, and forcing one is worse than admitting it.

Return 404 where the content is simply gone, or 410 where you deliberately removed it and want it dropped from indexes sooner.

Keep the 404 page useful: search, the main sections, and an honest statement that the page no longer exists.

Do not redirect them to the home page to avoid the error. That converts a truthful answer into a misleading one and hides the broken links from you as well as from visitors.

Submit the new sitemap and keep the old one available for a period so search engines re-crawl the old URLs and see the redirects.

Update internal links to point at the new URLs directly. A redirect is for external links and bookmarks; your own links should not need it.

Watch Search Console for 404 spikes over the following weeks. The URLs that were never in any list appear here and nowhere else.

Expect the index to move over weeks rather than days, and avoid changing the URL structure again in the middle.

Keep the redirects in place permanently. Removing them a year later turns every external link and bookmark built up since into a 404, which is the same migration failure arriving late.

VeriFixScan follows redirects during a crawl and reports `transport.redirect_chain` with every hop, which is how a chain is distinguished from a clean single redirect.

`availability.redirect_loop` reports cycles that never resolve, and `availability.broken_links` reports links whose destination returns an error.

`seo.sitemap` reports whether the sitemap is reachable and parses, which matters more than usual immediately after a migration.

A crawl starts from the new site and follows what it links to. It does not know your old URLs, so the migration list still has to be assembled and tested separately.