Validate Your URL Mapping Before Launch
A redirect mapping spreadsheet says what should happen; only hitting the server says what actually happens. This guide tests every row of your old-to-new mapping against staging, then production, before launch.
The problem with untested mappings
Every site migration produces a spreadsheet: old URL in column A, new URL in column B. It might have 50 rows or 5,000. It usually looks like this:
Old URL,New URL
https://example.com/about-us,https://example.com/about
https://example.com/services/web-design,https://example.com/solutions/web
https://example.com/blog/old-post,https://example.com/articles/old-post
https://example.com/contact-us,https://example.com/contact Looks correct on paper. But between the spreadsheet and the real server, many things go wrong:
- Typos in redirect rules. A mistyped path in .htaccess means the redirect never fires (404) or goes somewhere wrong.
- Regex matching too broadly. A rule like /services/(.*) -> /solutions/$1 also matches /services-agreement, sending it to /solutions-agreement.
- Rule ordering. A broad rule earlier in the list catches a URL before the specific rule meant for it.
- Protocol or domain mismatch. The mapping says /about but the redirect goes to http://example.com/about while the site is on https://www.example.com/about. Extra hops.
- Case sensitivity. /About-Us might not match a rule for /about-us depending on your server.
Spreadsheets lie. A mapping tells you what redirects should do. Only testing tells you what they actually do. Always validate against the real server.
How to validate
- Set up redirects on staging. Implement all rules on a staging server that mirrors production. This is where you test first.
- Prepare old URLs. Take the "Old URL" column from your mapping. If the staging domain differs, swap the domain in each URL.
- Batch check. Paste all old URLs into the batch checker and run. The tool follows each redirect to its final destination.
- Export results. Export to Google Sheets or download CSV. You now have old URL and actual final destination side by side.
- Compare. Put batch results next to your mapping. For each old URL, compare the actual destination against the expected one. Any mismatch is a problem.
- Fix and re-test. Update rules for mismatches, then re-run the batch to verify.
What to check
Destination matches expected URL
The most important check. Watch for subtle differences: trailing slashes, www vs non-www, http vs https. These all count as different URLs.
Status code is 301
For permanent changes, the redirect should be a 301. If you see 302, update your rules. Many servers and CMS plugins default to 302.
Single hop, no chain
Each old URL should reach its destination in one hop. If results show 2+ hops, you have a redirect chain. The redirect probably points to an intermediate URL that itself redirects again.
No 404s or 500s
A 404 means the redirect rule is missing. A 500 means there is a server error in your redirect config, often a regex syntax error.
Spreadsheet tip: In Google Sheets, use
=IF(B2=C2,"OK","MISMATCH")where B2 is the expected new URL and C2 is the actual destination from your batch results.
Common pitfalls
Testing production before redirects are deployed
If you batch check against production before the rules are live, every URL returns 200 (the current page) instead of a redirect. Always test against the environment where redirects are active.
Forgetting URL variations
Your mapping says https://example.com/page, but external links use http://example.com/page or https://www.example.com/page. Test all variations for your most important URLs. See our HTTPS audit and www vs non-www guides.
Staging vs production differences
CDN settings, DNS config, and server-level redirects can differ between environments. After staging passes, run the same batch on production right after launch.
After launch: re-validate
Run your full mapping through the bulk redirect checker again on production. Then follow the rest of our site migration checklist for post-launch monitoring.
Set up redirect monitoring on your most important redirects to catch regressions. Server updates, CMS changes, and CDN config changes can all break redirects that were working on launch day.
Validate your URL mapping
Import the old URLs from your mapping and compare actual destinations against the expected column.