How to Use a Bulk Redirect Checker

The most popular advice about redirects is to check whether the old URL returns a redirect and loads a page. That's not enough. A migration can look complete in a spreadsheet while old URLs pass through unnecessary hops, land on the wrong page, or end at an error. A bulk redirect checker is useful only when it shows what happens from the original request through the final destination.

Why a Redirect That Loads Can Still Be Wrong#

The migration spreadsheet says every legacy URL redirects. A few browser checks seem to confirm it: each old address takes you somewhere, and the new site opens. But that proves only that a request received a response and the browser followed it. It doesn't prove the visitor reached the intended page, or even a healthy one.

The distinction matters at scale. A study of 11 million redirecting URIs found that only half terminated successfully, while the other half ended in errors. It also found that 0.06% exceeded the study's 10-hop limit. Among 62,000 custom 404 URLs, nearly half were soft 404s, pages that may appear to load while still representing missing content (the study of redirecting URIs and custom 404s^[1]). A response that looks like a successful redirect can hide a destination that isn't useful.

A 3xx response isn't the finish line#

A 301 or 302 tells the client to go elsewhere. It doesn't tell you whether that destination matches the migration map, returns a healthy page, or preserves the user's path. A homepage fallback can make a broken deep link look alive. A redirect to the wrong language or host can also return a response while sending visitors somewhere they shouldn't go.

That's why a bulk audit should test every source against its intended final page. For each URL, the report needs to reveal the original status, every hop, the final status, and the address at the end. That's a different standard from opening a handful of links in a browser.

For hostname changes, confirm the destination also matches the site's chosen version. A team that needs to settle on one public hostname can use this guide to configure redirects for your preferred hostname^[2], then verify the resulting routes rather than assuming the hostname rule has fixed every page mapping.

Turn the audit into repairs#

Start with a complete list of old URLs and their intended destinations. Capture the whole chain, sort the failures by severity, and use the affected rows to correct the mapping. That lets the migration team distinguish a dead destination from a wrong code, an unnecessary hop, or a page that loads but doesn't match the source.

The blunt conclusion: a passing 301 or 302 is a weak signal of migration health. What matters is whether the rule has the right intent and leads to the right, reachable page.

Status Codes and Fields Worth Recording#

Before comparing redirect results, make sure each row records what the response means. The HTTP standard defines the 3xx class as responses that require further action by the user agent. A 3xx response is therefore a direction to continue, not proof that the journey has ended successfully (RFC 9110^[3]).

A 301 means the resource has moved permanently. A 302 means it's temporarily available at another location. These codes aren't interchangeable: if the move is permanent, labeling it temporary can leave the migration instructions at odds with the intended long-term routing.

Choose codes according to the request#

The other important distinction is whether the client must preserve the request method. Historically, clients could change a POST request into GET when following a 301 or 302. The 307 and 308 codes make method preservation explicit: 307 is temporary, while 308 is permanent. Their formalization in RFC 7538 established unambiguous temporary and permanent redirects that preserve the method.

For ordinary page moves, the mapping will usually call for a permanent status. For APIs, forms, checkout flows, and webhooks, the request method and body may matter as much as the destination. A redirect that changes POST to GET can break the operation even if the final URL responds. The choice between 301 and 302 should follow the same distinction between permanent and temporary intent, while 307 and 308 are relevant when the request method must remain unchanged. For a focused comparison of the common migration codes, see this guide to 301 versus 302 redirects.

Keep the fields that explain the outcome#

A usable audit row should capture:

• Original status: The exact code returned by the source URL.
• Every intermediate hop: Each address and status in the path, not just the first response.
• Location header: The destination specified at each redirect.
• Final status and URL: The response code and address reached at the end.
• Request-method behavior: Whether the method and body remain intact where they matter.
• Chain length: The number of redirects between source and destination.

Without these fields, an export can conceal a mix of permanent migration rules and temporary routing, lose path information, or apply a method-changing redirect to a request that needs preservation. Mark each rule's intent as permanent migration or temporary routing before treating its status as correct.

How to Check a Full URL List#

A browser glance is useful for troubleshooting one URL, but it's a poor bulk-audit method. Use a real HTTP client so you can capture each response and compare it consistently across the source list.

Run two passes for each source#

First, request each URL without following redirects. Record the status, Location header, protocol and host changes, response time, and whether the query string is preserved. This reveals what the source returns before a client moves on.

Then repeat with redirects enabled. Confirm the terminal status, check that the destination's content is reachable, and detect loops or repeated URLs. Google recommends keeping redirect chains ideally to no more than 3 hops and fewer than 5, because every hop adds latency and long chains may not be supported consistently by user agents (Google's site-move guidance^[4]).

Hops cost time as well as certainty. In RedirHub's benchmark of 26 redirect providers, measured from Washington, D.C., Frankfurt and Tokyo between 16 and 23 October 2026, the fastest provider's median time to first byte was 11 ms and RedirHub's was 17 ms (RedirHub redirect speed benchmark, 16–23 October 2026^[5]). A chain repeats that wait for every extra hop before the visitor reaches the final page.

Use GET as the authoritative production check. Some servers handle HEAD differently, so a HEAD response alone can give a misleading result. For APIs or other non-GET routes, test method behavior safely with synthetic requests or in a staging environment.

Compare more than the hostname#

Check whether the destination preserves or intentionally changes the path, query parameters, encoded characters, trailing slash, and internationalized-domain representation. A correct domain with the wrong deep path is still a bad mapping. Campaign parameters deserve particular attention because dropping them can disrupt attribution even when the page itself loads.

For a migration with search data available, extract search performance records^[6] to help identify which old URLs deserve careful mapping review. Use that context alongside the redirect results, not as a substitute for checking the actual destination.

At scale, keep concurrency bounded and use exponential backoff for 429 and 5xx responses. Export the source, hop count, status sequence, final URL, latency, and error class so the team can filter results and assign fixes. The mistake to avoid is counting any 3xx as a pass without confirming the final resource is reachable.

Fix the Migration Problems the Report Shows#

Googlebot follows both permanent and temporary redirects, but they don't send the same canonicalization signal. Permanent redirects indicate that the destination should be treated as canonical; temporary redirects don't provide that same signal. For site moves that change URLs, Google recommends server-side permanent redirects, preferably 301 or 308 where technically possible (Google's documentation on permanent redirects^[7]).

Fix the rows in order of impact. A source that ends in an error blocks the user journey. A redirect to the wrong page can misroute visitors and undermine the intended mapping. A temporary code on a permanent move sends the wrong signal, while unnecessary hops add avoidable work before the destination loads.

Prioritize by what breaks#

Don't treat a source as fixed just because one hop looks right. If the chain ends in an error, the migration failed for that URL. If it lands on the wrong language or protocol, change the mapping rather than leaving a redirect that merely returns 3xx. A redirect-mapping workflow such as the migration redirect mapper can help teams organize old-to-new URL pairs, but the final destination still needs validation.

A redirect also doesn't guarantee that the target becomes the preferred indexed URL. After correcting the rules, check the same list from relevant regions and repeat the audit over time. DNS, TLS, edge routing, and destination availability can vary, so a result from one place or moment may not describe every user's experience.

Tips for Paths, Parameters, and Rule Ownership#

Once the obvious status-code problems are corrected, the remaining failures are often in the details: a deep path gets sent to the homepage, query parameters disappear, or an old imported destination is still in use. A redirect can pass a basic status check and still break the user's intended journey.

Non-canonical redirects involving domain or path changes can reflect migration, rebranding, or security risks. That makes redirect quality an SEO, security, analytics, and governance problem, not just a question of whether a server returned a redirect.

Test the paths users actually follow#

Don't validate only the root domain. Choose representative deep paths and confirm they land on the relevant page, not on a catch-all fallback. A homepage redirect can make many unrelated failures look superficially successful.

Test query strings too. Include campaign parameters and verify that the destination preserves them or handles them as intended. If a redirect uses a supplied destination value, make sure it can't send users to an unexpected external host. Flag cross-domain destinations that don't match the approved mapping.

Compare the rule's stated intent with the page at the end. A deliberately retired URL isn't the same as an accidentally broken page, and both shouldn't be treated as a generic success. Bulk imports can leave stale destinations, old chains, or broad homepage fallbacks that disguise missing mappings.

Make ownership part of the audit#

For every rule, establish who approved it, why it exists, and where its change history is recorded. Without an owner, teams can't confidently distinguish a deliberate exception from a stale instruction or trace why a destination changed.

Once an old URL no longer needs an intermediate destination, consider replacing the chain with a direct mapping to the final page. Keep an intermediate route only when the URL still has a clear operational purpose; otherwise, it's an extra moving part that makes future audits harder.

Recheck the Chain, Then Publish the Fix#

After correcting the mapping, run the same source list again. Confirm the full path, including each 301, 302, and meta refresh, rather than checking only the first response. Any multi-hop route that can be collapsed should be fixed before launch, because each extra step adds another point where the journey can go wrong.

For a permanent domain or site move, map each old URL to its relevant new URL. Preserve the path and query when deep links need to survive, then test the journey before switching traffic. The destination should match the source's purpose, not just return a successful status.

Review the import before saving it#

For a large list, a CSV makes the changes easier to review as a set. RedirHub imports links from a CSV and shows what will be added, updated or removed before anything is written. Its redirect checker traces each 301, 302, 307 and meta refresh until the final page answers.

Place the rules on a domain your team owns, rather than relying on a borrowed public URL. RedirHub forwards query parameters on Core, Pro and Enterprise, and its checker exposes redirect chains and loops; teams can also review how redirect chains and loops behave as part of deciding what to fix before publishing.

Export the failing rows, correct the permanent mappings, import them, and run the checker again on the same list.

RedirHub provides a redirect checker that traces full redirect chains and a CSV workflow that lets teams review proposed changes before saving them. Visit RedirHub to check the corrected URLs, publish permanent migration rules on a domain your team owns, and verify the same list again.