RedirectProofby Ettix

Guide

How to QA redirects after a website migration

A migration keeps its search rankings, bookmarks and inbound links only if every old URL lands on the right new page in one permanent step. This guide is the checklist we use, with the fixes for the failures we see most.

1. Build the redirect map

The map is a two-column table: every URL that exists on the old site, and the single URL it should end up on.

2. What a good redirect looks like

3. Common failures and how to fix them

Redirect chain (old → http new → https new)
Usually separate rules for "old path to new path", "http to https" and "non-www to www" that run one after another. Write the migration rule so it targets the final https host and path directly, and put it before the generic canonicalization rules.
Wrong destination: trailing slash differs
The redirect points to /about and the site then adds a slash (or the reverse). Point the rule at the canonical form the new site actually serves.
Wrong destination: query string dropped or added
Some servers append the original query string to the target by default; others drop it. In nginx, return 301 https://www.example.com/docs/$is_args$args; keeps it; in Apache RewriteRule, the QSD flag drops it and QSA appends it.
Destination returns 404
The redirect is right but the new page is missing, unpublished or has a different slug. Fix the page or update both the map and the rule.
Temporary redirect (302/307)
Many frameworks and hosting dashboards default to 302. In nginx use return 301, in Apache Redirect 301 or [R=301,L], and in hosting UIs pick "permanent".
Redirect loop
Two rules point at each other, often a "remove trailing slash" rule fighting an "add trailing slash" rule, or an old and a new rule for the same path. Remove one of them.
No redirect: the old URL still answers 200
The old page is still being served (a cached copy, an old CMS route, or a CDN rule that never deployed). Purge the cache and confirm the rule is live on the server that answers that host.
Host does not resolve
The old domain's DNS was removed or moved before the redirect host was set up. Keep the old domain pointing at a server that issues the redirects for at least a year.

4. When to test

  1. On staging, if the staging host is publicly reachable on standard ports, using a copy of the map with the staging host.
  2. Right after the DNS or rules go live, with the production map.
  3. Again after cache purges and CDN deploys, and once more a few days later. Rule changes, plugin updates and CDN edits regularly break redirects that worked on launch day.

5. Testing a map with RedirectProof

  1. Open the checker and load your CSV (or try the demo first).
  2. Fix rows flagged as invalid (missing scheme, spaces, non-standard ports, local hosts).
  3. Run the free check on the first 25 routes. Put your most important URLs first if you want them in the free check.
  4. Unlock the full check ($49 one time per project) for up to 500 routes, repeat checks, the CSV and the printable report.
  5. Filter by Fail and Warning, open each hop chain, fix the rules, and run the same project again.

RedirectProof sends plain GET requests without cookies or login from a server, over IPv4 only. Sites that vary by location, device, login state or bot detection may answer your visitors differently.

6. Launch-day checklist

Check your redirect map