GUIDE

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:

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

  1. Set up redirects on staging. Implement all rules on a staging server that mirrors production. This is where you test first.
  2. Prepare old URLs. Take the "Old URL" column from your mapping. If the staging domain differs, swap the domain in each URL.
  3. Batch check. Paste all old URLs into the batch checker and run. The tool follows each redirect to its final destination.
  4. Export results. Export to Google Sheets or download CSV. You now have old URL and actual final destination side by side.
  5. 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.
  6. 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.

Sign up free