Browser tool · CSV · Free to use
Redirect mapping validator
Check a redirect CSV for conflicting destinations, duplicates, chains and cycles before importing it.
Practice datasets are fictional and labeled as such. Real store captures are dated observations with their own sources and evidence limits.
Works in your browser
Check your own data
No signup or upload to a server. Up to 10 MB per file and 50,000 rows or URLs per set. Results describe the supplied files only.
Prepare the map
Use a CSV with source and destination columns containing absolute HTTP or HTTPS URLs. Keep a separate reviewed decision record for pages that stay, merge or return 404/410; this tool checks redirect pairs only. Try the defective sample and its separate worked correction before using your own export.
The checker preserves case, query strings and trailing slashes. It does not silently merge addresses that a server might treat differently. Export your platform’s current rules as a baseline and retain the original file. If a map uses relative paths, resolve them against the intended origin before importing here.
Interpret findings before changing rules
A duplicate source with the same destination is redundant; a source with two destinations is ambiguous. A self-redirect points back to itself. A chain passes through another source in the supplied map. A cycle, or a route leading into one, cannot reach a final destination under those supplied rules.
The correct destination is still an editorial and product decision. A chain can be flattened only after you verify that the final page satisfies the original purpose. The tool never invents a successor based on a similar slug. It also cannot see redirects imposed by a CDN, server or platform outside this file.
Work the migration sample before trying the answer
The fictional store supplied eight rules. Its approved content decisions are: /final replaces both /old and /intermediate; /keep stays at its current address; /products/boots preserves the boot range, including the former sale-boots entry point; /guides/care combines the useful content of care-a and care-b. These decisions are exercise inputs, not conclusions inferred by the checker.
Run Try sample data. The /old route reaches /final through /intermediate, so review it for a direct mapping using the supplied decision. /keep redirects to itself: remove that rule and retain the page as a Keep decision. The two /boots rules disagree. Choose the approved product range, not the home page, and then update /sale-boots to the same approved destination.
The care-a and care-b rules form a loop. Replace both with direct mappings to the supplied consolidated care guide. Try corrected sample runs the six reviewed rules; Download corrected sample gives you that separate CSV. The original example stays available. The checker does not generate this answer from your uploaded file or silently change your destinations.
The corrected sample should have zero file findings. That is deliberately not a launch sign-off: the example domains are fictional and no HTTP responses have been tested. /keep is absent because it is not a redirect; retain it in the wider inventory and test its normal response separately.
Assign decisions and retain the full route
Filter Fix to address invalid addresses, conflicting rules, duplicates, self-redirects and loops. Review isolates chains whose shortening requires a content decision. Search a source, submitted destination or issue. A conflicting source stops route analysis: neither the first nor the last conflicting rule is assumed to win, because platform precedence is unknown.
Each finding shows the supplied source and target, the route and its stopping reason. Short routes are visible in full. For unusually long routes, the page shows the first 50 entries and offers the complete route as a CSV; unresolved alternatives are retained too. Routes are traced only within the uploaded map. Hostname handling, fragments, wildcard rules and platform normalization need their own real-server checks.
Export all findings creates the priority queue with action, approved correction, owner, status and evidence fields. Export all URL checks includes every submitted row, even a direct mapping with no findings. Its terminal or stopping-point column describes file evidence; the actual HTTP chain remains blank until tested. Both exports ignore display filters so a filtered view cannot accidentally hide work from the handoff.
Before launch: turn a map into a testable release
Reconcile the source inventory with the mapping and the separate Keep, Merge and Remove decisions. Include product variants, categories, editorial pages, images and downloads that matter to the store. Use durable product identity and purpose to approve destinations. A missing row is outside this checker's evidence; the tool cannot know that an export omitted a valuable URL.
Assign a content owner to destination decisions and a technical owner to rule implementation. Keep the existing rules, deployment version and rollback procedure. Test the candidate configuration in staging, including routes already handled by the CDN or platform. The same exact CSV can behave differently under wildcard precedence, query handling or normalization.
For each priority source, retain the requested URL, observed status sequence, final address, selected product or category identity, canonical and access result. Include a direct mapping and a repaired loop or conflict as controls. Set acceptance criteria before release: no unresolved map conflicts, reviewed destinations and evidence for the expected response behavior. Passing the file checker alone does not meet those criteria.
At launch: verify what the shopper and crawler receive
After activating the approved rules, retest representative old URLs against the production hostname. Record the actual response sequence instead of copying the planned destination into the evidence column. Test exact paths, trailing slashes, relevant parameters and mobile product selection. Check the real final content and canonical together; a technically successful response can still deliver the wrong product.
Check navigation, internal links, sitemap output, rendered access controls and key shopping flows against the release plan. When a discrepancy appears, record its scope and owning layer before editing another rule. Use the smallest approved recovery action; do not restore an old commerce database over new orders to undo a redirect configuration.
After launch: investigate changes with the release record
Keep the original map, corrected map, implementation version, findings and completed URL register together. Revisit priority routes after cache changes and subsequent deployments. Compare crawler observations and Search Console coverage with the intended inventory, and investigate unexplained missing pages or changed destinations rather than treating a stable total count as proof.
Separate technical acceptance from search performance. Record the deployment date, measurement changes and concurrent promotions before interpreting traffic movement. A clean map does not establish retained rankings, indexation or revenue. Close each implementation task when its actual response and destination evidence match the approved decision; keep unresolved search observations as separate follow-up work.
Complete the live verification separately
For each priority source, record the real response chain and final URL after implementation. Compare the final page’s title, product identity, availability and canonical with the approved decision. Review market subfolders and query behavior where they are part of your store.
Pass when file-level findings are resolved or explained and representative live paths satisfy the approved decisions. Exported findings include row numbers so an owner can return to the input. CSV exports escape spreadsheet formula prefixes; imported file contents stay in this browser session.
Sources and maintenance
Check current platform documentation before implementation. Review these instructions when your platform, catalog behavior or source guidance changes.