maplatchFIELD NOTES / UPDATED 10 OCTOBER 2026
How to QA a redirect map
before launch.
A redirect map is a list of decisions about old URLs. Your job is to make sure the list is complete, internally consistent and supported by evidence — then test the actual implementation.
This guide is written by MapLatch, which provides a free file checker and is preparing a paid review service. The examples are illustrative. No ranking improvements are claimed.
1. Keep an independent old URL inventory
Start from more than the map itself. Use relevant sitemap exports, crawl data, analytics landing pages, Search Console and known externally linked URLs where available. An incomplete inventory produces incomplete coverage, even when a checker reports 100%.
For each old URL, record one decision: redirect, keep, or retire. A missing row is not the same as an intentional retirement. A retired page may need a 404 or 410; that is an implementation decision to verify.
2. Preserve distinctions that your server preserves
Do not silently remove query strings, lowercase paths or strip trailing slashes. /Offer, /offer and /offer/ may behave differently. Scheme and hostname also matter when changing domains. Provide the correct old and new origins when your file contains paths.
URL fragments are not sent in HTTP requests. A rule containing #section therefore needs separate browser-level review.
3. Find conflicting sources before following chains
Two identical rows are usually a cleanup issue. Two destinations for the same source are a decision problem. Resolve conflicts first: the effective behavior can otherwise depend on server rule order.
Consider /old → /middle → /new. A direct destination may be preferable, but only after confirming that /new is the intended relevant page. A loop such as /a → /b → /a is a blocker.
4. Check destination evidence, not just URL syntax
A well-formed destination can return an error, be non-indexable or canonicalize elsewhere. Export destination status and indexing observations from a crawler. Include the crawl time in your handoff, because a historical 200 response is not proof of the current response.
A destination absent from an export is unverified; absence alone does not prove a 404. This distinction matters when your crawl intentionally excludes parts of the site.
5. Review relevance and exceptions
Redirecting every discontinued page to the homepage can be inappropriate. Group related pages, examine what moved, and have the content owner approve consolidation and retirement. Automated graph checks cannot decide whether two pages meet the same user need.
Use a decision register with the old URL, proposed action, rationale, evidence, owner and approval status. Leave unresolved decisions visibly unresolved.
6. Test implementation separately
Stage a representative set: a direct redirect, a chain correction, query-string cases, trailing slashes, mixed-case paths, important landing pages, kept pages and retired pages. Compare actual HTTP status and final URL with the approved map. Test rule precedence and platform-specific behavior.
After launch, re-crawl, review internal links, canonicals and sitemaps, and monitor Search Console with the owner. A static CSV report cannot replace these checks.
What a useful handoff contains
- Input filenames, dates, scope and limitations.
- An explicit decision for each relevant old URL.
- Prioritized findings with record references and next actions.
- Approval status for exceptions and content decisions.
- A staging test plan and a named launch decision owner.
Google Search Central’s site-move documentation is the primary reference for this workflow. It recommends mapping URLs, avoiding unnecessary chains and checking the move. It does not endorse MapLatch.