Audit HTTP status differences after a migration

Why audit status codes

A migration changes what the server returns for every URL, and most faults are not a total outage but a small set of responses that changed meaning: a page that was 200 is now 404, a redirect that used to point to the final page now loops, or a static asset returns a 500 on the new host. Comparing the HTTP status of every URL on the old host against the new host catches those regressions before visitors do, so it belongs in the host migration checklist at the point where you would otherwise assume the copy "just worked".

Status codes are the compact signal for this comparison. A page, a redirect chain, a missing resource and a server error each produce a distinctive code, and two hosts that return the same code for the same path are behaving the same at the HTTP layer even if they came from different software. The audit is a crawl: fetch every important URL against the old host and the new host, record the final status and the redirect chain, then diff the two lists.

Crawl both hosts

Run the same crawl against both states before you switch DNS. The two targets are the live host (keep the old DNS as is) and the new host, reached by overriding the hostname, for example through a local hosts entry or the hosting control panel's preview URL. The DNS cutover testing article covers reaching the new host before DNS changes.

A loop over the URL list with a tool that follows redirects captures the final code and the chain. The exact mechanism varies by tool, but the shape is a consistent check per URL:

curl -s -o /dev/null -w "%{http_code} %{url_effective}\n" -L https://new-host.example/page/

For the full redirect chain rather than just the final code, request with headers that expose each hop, or use a checker that prints every redirect along the way. Capture enough per URL to compare meaningfully: the final status, the number of redirect hops, and the final URL for anything that redirects.

Compare the results

Group every URL by whether its behaviour matches on both hosts. Most should match exactly. The differences here are the ones that matter:

• 200 on old, 404 or 500 on new. Content exists on the old host but is missing or broken on the new one. Investigate the file, path, permalink structure or a database path not moved, often tied to WordPress fixed links or a cache that must be cleared.
• Different redirect destinations. The old host redirects to /page-a and the new host to /page-b, so both end with a 200 but to different places. This usually points at a redirect map that was rebuilt differently on the new host. Compare the final URL, not just the code.
• Redirects that loop or hard-fail. A chain that terminates on the old host now returns 302 forever or ends at a 500. Anything that ends in a loop or in a 5xx is a cutover blocker.
• Errors that are new on the new host. A 500, 502 or 503 localised to the new infrastructure is a configuration fault to fix before you redirect traffic, not something to discover after DNS switches.

Classify each difference as must-fix-before-cutover or will-accept, and confirm the safe set through the rollback plan so a change that breaks one path does not take the whole migration with it. Run the comparison once with a snapshot of the URL list, fix the differences the new host introduced, and re-crawl only the changed paths until old and new agree. When the diff is clean, the migration has a far smaller chance of shipping a silent 404, a dropped redirect or a broken asset that a status-code audit would have caught in minutes.