Redirect Checker & Map Validator

Redirect problems fall into two categories, and they need catching at different points in a project.

Before launch, the risk is structural: chains, loops, duplicate sources and malformed entries inside the map you are about to deploy. Every line can be individually valid while the map as a whole contains paths that fail. This is a validation problem, and it is solved by parsing the map before it goes anywhere near production.

After launch, the risk is behavioural: redirects that fire with the wrong status code, land on a 404, or add an extra hop through server-level canonicalisation. This is a QA problem, and it needs crawl data from the live site.

Both tools live on this page because they answer the same question at different stages.

A redirects to B, and B redirects to C. Each hop adds latency, consumes crawl budget and risks diluting the signals you are trying to preserve. Chains accumulate naturally across successive restructures, with each migration layering onto the last. The fix is flattening: point A directly at C.

A redirects to B and B redirects back to A. The browser gives up and the page is effectively offline. Loops usually appear when two people edit the same map independently, or when a new rule contradicts an existing one.

A URL pointing at itself. Always an error, usually a copy-paste artefact, and it becomes a loop the moment it deploys.

The same source mapped to two destinations. The server resolves the conflict by rules you probably have not considered, and the winner may not be the one you wanted.

Redirecting a trailing-slash URL to a non-slash one, or mixing relative and absolute paths, frequently produces an extra hop once your server's own canonicalisation applies. Individually trivial, collectively a source of avoidable chains.

301 signals a permanent move and tells search engines to transfer signals to the destination and update the index. 302 signals temporary and instructs them to keep the original URL indexed.

Use 301 unless the move genuinely is temporary. The most common error is not a deliberate wrong choice but a platform defaulting to 302 for redirects created through an admin interface. Worth confirming what your setup actually issues rather than assuming.

1. Crawl the current site fully and export URLs with traffic, rankings and backlink counts.
2. Map every URL that matters to its closest equivalent — not the homepage.
3. Validate the map for chains, loops, duplicates and malformed rows before deployment.
4. Test on staging and confirm status codes are what you intended.
5. Launch, then crawl immediately to catch anything the map missed.
6. QA the live redirects for wrong status codes, 404 destinations and unexpected hops.
7. Monitor Search Console for coverage errors and 404 spikes for at least a month.

The usual advice is a year. The more accurate answer is for as long as anything still points at the old URL.

Search engines eventually drop the old URL once the redirect is processed, but external links never update themselves. A link from an article published years ago will keep sending traffic through your redirect indefinitely, and removing it turns that link into a 404.

Redirects cost almost nothing to maintain. Unless the map has grown large enough to affect server performance, leaving them in place is the safer choice.

• Reserved URL prefixes. Products, collections and pages sit under fixed paths, so migrating from another platform nearly always requires a redirect for every URL.
• Deleted products leave 404s. No redirect is created automatically, which quietly discards inbound links to discontinued lines.
• Renaming a collection changes its handle and therefore its URL. The old one breaks immediately.
• CSV import for bulk maps. Practical at scale, and precisely where validating first pays off, since malformed rows can fail silently.

The mental shift that prevents most redirect problems is treating the map as a network rather than a list. Every row is an edge between two nodes, and the useful questions are structural.

• Does any path take more than one hop? That is a chain.
• Does any path return to its origin? That is a loop.
• Does any source appear twice? That is a conflict.
• Does any destination not exist? That is a redirect to a 404, which is worse than no redirect at all.

Reading a file top to bottom cannot answer any of these, because the failures live in relationships between rows that may be hundreds of lines apart. This is exactly the kind of check automation does well and human review does badly.

Validation confirms the map is coherent. It cannot tell you what the live server actually does with it, and the two frequently differ.

1. Status codes. Confirm 301s are issuing as 301s, not 302s.
2. Final destinations. Follow each redirect to its end and confirm it returns 200, not a 404 or another redirect.
3. Unexpected hops. Server-level canonicalisation for trailing slashes, protocol or www can insert a hop your map did not create.
4. Query strings. Check whether parameters survive the redirect, particularly for paid campaign URLs.
5. Coverage in Search Console. Watch for 404 spikes and unexpected redirect errors in the weeks after launch.