Redirect Map Checker
Check that every old URL in your migration map lands where the map said it should. Paste old,new pairs and see which rows missed. Free, no signup.
A redirect map is the spreadsheet you build before a site migration: every old URL, and the new URL it is supposed to point to. It records intent. Once the rules are live, the only thing that counts is what the server does when somebody requests the old address, and the two can differ on rows nobody thought to spot-check. Paste the map back in as old,new pairs and every line is requested for real, then compared against the destination you said you wanted.
Rows that land somewhere other than the mapped URL come back marked mismatch. That is the defect a bulk status checker will never report: the redirect fired, it returned a healthy 200, it just went to the wrong page. The table also flags the chains and loops hiding behind that 200, and gives the hop count so you can tell a clean 301 from a rule that fires three times before it settles. A bare URL with no pair still works, which is what you want when you are auditing a migration somebody else ran. For one stubborn URL, trace it hop by hop in the Redirect Checker.
Verifying a redirect map after a migration
The map is a document of intentions. It was written before a single rule existed, by people reading a spreadsheet rather than a server config, and it says what should be true. Verification is the opposite exercise: request each old URL against the live site and write down what actually comes back. The gap between the two is rarely uniform. It is a scattered handful of rows behaving differently from the rest, which is exactly why spot-checking twenty URLs tells you almost nothing.
Five things account for most of that gap.
Rules that never shipped
The map had 4,000 rows and the config has 3,800. Someone truncated a paste, a bulk import hit a row limit, or the last section of the sheet was still under review when the deploy went out. Those URLs return 404 and nothing announces it.
Rules that fire in the wrong order
Server rules are read top down and the first match wins. A broad rule written for /products/ intercepts a request meant for /products/legacy-sku, and the specific rule below it never runs. The URL redirects. It just redirects somewhere else.
A catch-all that swallows the specific rules
The blanket rule at the bottom of the file, the one sending anything unmatched to /shop or to the homepage, is what hides the damage. Every missing rule now returns a healthy 301 to a live 200, so a status check passes. Only a comparison against the mapped destination shows those rows are wrong.
Trailing-slash normalisation
Your rule points at /new-page and the platform canonicalises to /new-page/. The redirect works and the visitor arrives, but every mapped URL now takes two hops instead of one. Match the slash form your platform emits and the extra hop disappears.
A staging hostname baked into the target
The rules were written and tested on staging.example.com, and a handful of absolute targets kept that host. In production they send visitors off your domain to a server that is password-protected, blocked from indexing, or already torn down.
All five surface as a row you can act on. The undeployed rule shows as a 404, the losing rule and the catch-all show as mismatches, the slash flip shows as two hops, and the staging target shows as a final URL on a hostname that is not yours.
What to check the day you migrate, and the week after
One pass is not enough. The answer changes as caches drain and the CMS catches up, so three runs spaced across the first week catch three different classes of failure.
- 01
The day you cut over
Run the full map as soon as DNS points at the new site. You are looking for structural failure here: whole sections returning 404, targets still pointing at staging, a catch-all quietly absorbing hundreds of rows. These are the expensive ones, and fixing them in the first hour costs you almost nothing.
- 02
Once CDN and DNS caches expire
Edge nodes keep serving the old response for as long as their TTL says, and regions expire at different times, so a run from one machine on day one tests one warm node. Go again 24 to 48 hours later. A row that passed on cutover day and fails now means the cached response was covering for a rule you never deployed.
- 03
After the CMS regenerates its own redirects
WordPress, Shopify and most headless setups write redirects of their own whenever a slug changes or a product is republished, and those land on top of yours. Re-run the map about a week in, once the content team has stopped touching things, and check that no row has grown a second hop.
Keep the CSV export from each run. Diffing two exports tells you which rows changed and when, which is a faster diagnosis than reading the config again from the top.
How it works
- 01
Paste the map
One pair per line: the old URL, a comma, then the destination it was mapped to. A bare URL with no pair still works and reports where it currently lands.
- 02
Run the check
Sitewell requests every old URL against the live site, follows each 301 and 302, and records the final URL, the status code and how many hops it took.
- 03
Fix the red rows
Mismatches and 404s are what cost you rankings. Chains are slower but survivable. Export the table as CSV and hand it to whoever owns the redirect config.
Frequently asked questions
- How do I verify my 301 redirect map?
- Take the same old,new sheet you handed to whoever wrote the rules and paste it back in, one pair per line. Every row is requested against the live site, so you get the status code, the final URL and the hop count sitting next to the destination you said you wanted. Rows marked mismatch redirected correctly to the wrong page, which is the failure a status checker cannot see. Fix those first, then the 404s, then the chains.
- How do I check a redirect map after a site migration?
- Export the old URL list the map was built from, keep the expected destination in the second column, and run it in batches of 200. What you want on every row is one 301 that lands on a 200 at the address the map named. Anything else points at a rule: a 404 means the rule never shipped, a mismatch means another rule matched first, and two or more hops means an old rule is still firing ahead of the new one.
- What should every old URL return after a migration?
- A single 301 to a URL that answers 200. Not a chain, even a short one, because each extra hop is another round trip and another transfer where ranking signal leaks. Not a 302, which asks search engines to keep the old address indexed. And not the homepage: sending a retired product page to / is treated as a soft 404, so the old URL keeps none of what it earned. When there is genuinely no equivalent page, a 410 is more honest than a redirect to something irrelevant.
- Why do some redirects work locally but not in production?
- The rule is rarely the only thing between the request and the response. A CDN or reverse proxy in front of production can answer first, or keep serving a cached copy of the old response until its TTL runs out. The server can differ too: an .htaccess file that works under Apache does nothing on nginx, and AllowOverride may be off on the production host. Some hosting platforms also cap how many rules they read from a redirects file and drop the rest without warning. Test against the public hostname and you are testing the stack your visitors get.
- What is a redirect mapper?
- A redirect mapper takes a list of old URLs and follows each one to wherever it ends up, so you see the whole redirect map in a single table instead of checking addresses one by one. Paste a plain list and it reports each URL's final destination and status code. Add the destination you expected as an old,new pair and it also flags the rows that landed on the wrong page.
- How do I map redirects in bulk?
- Paste up to 200 old URLs, one per line, and run the map. The tool requests each one, follows its 301s and 302s, and tracks where every URL lands along with the status code and the hop count. You get one row per URL, which is what you want when you are moving a whole site and need to confirm the new rules did what the map said they would.
- What is a redirect map?
- It is a list pairing every old URL with the new URL that should replace it. Teams build one in a spreadsheet before a site migration and hand it to whoever writes the server config or the CMS rules. The map describes what should happen. This redirect mapper checks what did happen, by requesting each old URL and comparing where it lands against where the map said it should go.
- What does the mismatch verdict mean?
- You gave an expected destination in an old,new pair and the URL landed somewhere else. Usually that means a typo in the config, an earlier rule that fires first and wins, or a second redirect sitting on the new URL that moves it again. Mismatches are the reason to use a redirect mapping tool rather than a plain status check: the redirect worked, it returned a healthy 200, it just went to the wrong page.
- How is this different from the Redirect Checker?
- The Redirect Checker traces one URL and shows you every hop in the chain, which is what you want when you are debugging a single strange redirect. The mapper is built for volume. It runs up to 200 URLs at once and gives you one verdict per row instead of a full trace, so you can scan a whole migration in a single pass.
- What should I do when the map shows stacked hops?
- Stacked hops in a mapping usually mean an old rule and a new rule are both firing on the same URL — easy to miss because the page still loads fine. Rewrite the first rule to point straight at the final destination, re-run the map, and confirm every row resolves in one hop.
- How many URLs can I check at once?
- 200 per run, free, with no account. If your redirect map is bigger than that, split it into batches and run them back to back. The tool is rate limited to a few runs a minute because each row can mean several requests.
- Do you store the URLs I check?
- No. The URLs are processed to return your results and are not tied to an account. We do not sell your data or reuse the URLs you check for anything else.