Redirect Checker
The Redirect Checker follows every server-side hop from a submitted URL to its terminal response for up to 10 sources. An HTTP redirect tells a browser and a crawler that a URL has moved to another address.
What an HTTP redirect does
An HTTP redirect tells a browser and a crawler that a requested URL has moved, and the response carries a status code plus a Location value that names the address to request instead.
The status code states whether the move is permanent or temporary, and that distinction tells a search engine whether to keep the old address in its index and whether to transfer signals to the new one.
The Location value can be absolute or relative. A relative value is resolved against the URL that supplied the response, which is why a redirect chain can move through several hostnames before it reaches a terminal response.
How a redirect response is delivered
A redirect is a status code plus a Location value, and a meta refresh is the only client-side form the checker reports.
Server-side redirect response
HTTP/1.1 301 Moved PermanentlyLocation: https://example.com/new-pageClient-side meta refresh
<meta http-equiv="refresh" content="0; url=https://example.com/new-page">Redirect status codes and what each one means
HTTP 301 and 308 describe permanent moves, while 302, 303 and 307 describe temporary or method-specific moves.
Permanent redirects: 301 and 308
A permanent status is the correct choice when the old address should never serve the content again. A search engine treats the new address as the long-term location and moves the old signals to it.
Temporary redirects: 302, 303 and 307
A temporary status is the correct choice when the old address returns later, such as a maintenance window, a time-limited campaign, or a location-based routing rule. Because the move is not permanent, a search engine keeps the original address in its index.
Method preservation across 303, 307 and 308
The method rules separate the codes further. A 303 tells the client to request the new address with GET, a 307 preserves the original HTTP method, and a 308 preserves the method while marking the move permanent. Method preservation matters for form submissions and API endpoints, where changing the method breaks the request.
How redirect chains affect signals and speed
Each redirect in a chain adds a separate request before the terminal response, so a longer chain costs additional latency and passes slightly less signal than a direct redirect to the final address.
The shortest correct path
A single redirect from the old address to the final one is the shortest correct path. Two hops add one extra request, and a chain that runs through several intermediate addresses adds a request and a resolution step at every stage.
Why latency compounds
The latency compounds because each hop repeats name resolution, connection setup, and response handling. On a fast origin each hop can cost a few tens of milliseconds, and a slow origin costs more, so a chain can consume a visible share of a page’s load time before the first byte of content arrives. Because every hop delays the terminal response, a long chain pushes out Largest Contentful Paint and works against the Core Web Vitals thresholds that use load speed as a ranking input.
Chains are followable but avoidable
Search engines can follow chains, so a chain is not a penalty by itself. The cost appears as avoidable delay and as intermediate URLs that keep receiving requests, which is why collapsing the chain to one hop is the corrective action.
Common redirect faults and how to read them
A loop repeats a normalized URL and never reaches a terminal response, and a terminal 4xx or 5xx means the redirect resolved while the destination failed.
Redirect loops
A loop produces a repeated URL identity rather than a final status. Conflicting application, proxy, CDN, and protocol rules are the usual cause, and every entry point that feeds the loop needs the same correction.
Terminal 4xx and 5xx responses
A terminal error is not a redirect fault. The chain completed and the destination returned a client or server error, so the repair belongs at the target rather than in the redirect rule.
Two-hop protocol and hostname consolidation
An HTTP to HTTPS or www to non-www consolidation is written as two hops when the first rule targets the secure host and a second rule changes the hostname. Both hops can be expressed as one rule that resolves directly to the final address.
When a redirect is the wrong instrument
A redirect moves every visitor and every crawler, so it is the wrong instrument when both addresses must stay reachable.
Use a canonical tag when both URLs must stay live
Tracking-parameter variants, print views, and product pages reachable from several categories need a canonical declaration rather than a redirect, because both addresses serve content and one should represent it.
Point old URLs at an equivalent page
A redirect to a homepage for an old deep URL discards the relevance of the original page. Point the old URL at the closest equivalent address so the visitor and the crawler land on content that matches the original intent.
Redirect status codes compared
| Status | Meaning | Stays in the index | Correct use |
|---|---|---|---|
| 301 | Permanent move | No, the new address replaces it | Changed slug, new domain, outright replacement |
| 302 | Temporary move | Yes, the original is retained | Short-term campaign or routing rule |
| 303 | See other resource | Yes | After a form submission, so the result is fetched with GET |
| 307 | Temporary move, method preserved | Yes | Temporary move for an endpoint or form that must keep its method |
| 308 | Permanent move, method preserved | No, the new address replaces it | Permanent endpoint move where the method must not change |
Using the Redirect Checker
What the Redirect Checker checks and reports
List each bounded fetched URL in order with its hop number, keeping the submitted source, intermediate locations and terminal response distinguishable throughout the redirect path.
Show the HTTP status and declared Location value behind every followed server-side redirect, including relative locations resolved against the response URL that supplied them.
Stop repeated URL identities as a loop and cap total fetched or returned hops at five. A limit result stays distinct from a confirmed terminal response.
Report the final effective URL and HTTP status, with terminal meta refresh markup identified as page evidence. The checker does not execute JavaScript or treat client-side navigation as an HTTP hop.
When to use the Redirect Checker
Run the Redirect Checker to diagnose unexpected destinations, loops or multi-hop paths that add latency and obscure the final resource.
How to use the Redirect Checker
Example: inspect http://example.com/old-page to trace each 301 or 302 response through its final HTTPS destination.
Common Redirect Checker issues and fixes
When the hop table shows avoidable intermediate responses, update the source link, canonical or redirect rule to point directly to the intended final URL. Keep a required migration hop only when it serves a real compatibility need, then retest the original source.
A repeated normalized URL means the chain cannot reach a terminal resource. Inspect the two or more conflicting application, proxy, CDN or protocol rules shown in the evidence, correct the cycle and retest every affected entry point.
A client or server error at the final destination means the redirect resolved but the resource did not succeed. Repair that destination or change the redirect target. Preserve the reported status instead of labelling every distinct failure simply broken.
Understanding your Redirect Checker results
The report lists each bounded fetched URL, status and Location target, plus the terminal response and any terminal meta refresh markup.
Limitation: The Redirect Checker makes bounded HTTP requests for up to 10 public source URLs and follows at most five total fetches per source. It records server-side status and Location evidence, stops loops and reports a limit without inventing a terminal response. It may identify meta refresh markup only on the terminal response; it does not render the page, execute JavaScript or reproduce browser-internal navigation. Network, TLS, authentication, blocked-network and response-limit failures remain transport evidence. The result describes the observed path, not whether every crawler has cached or processed it.
Frequently asked questions
What is the difference between permanent and temporary redirect status codes?
HTTP 301 and 308 describe permanent redirects, while 302, 303 and 307 describe temporary or method-specific redirects. The Redirect Checker reports the actual status on every hop. Whether a status is correct depends on whether the source URL should remain the long-term public location.
How many redirect hops are too many?
The shortest correct path is one redirect from the old URL to the final URL. This checker stops after five total fetches so loops and long chains stay bounded. Remove avoidable intermediate hops when they add latency, create conflicting destinations or prevent the terminal response from being reached.
Do redirects lose ranking signals?
A permanent redirect passes the signals from the old address to the destination, and a temporary redirect keeps the signals with the original. A chain dilutes the transfer at each hop because each intermediate address is a separate step, which is why the direct redirect is the preferred form.
Should I redirect or use a canonical tag?
Redirect when the old address should stop serving content and visitors should reach the new one. Use a canonical tag when both addresses must stay live and only one should represent the content. A canonical tag leaves both URLs reachable, and a redirect removes one from normal use.
Does the Redirect Checker follow JavaScript redirects?
It follows server-side Location headers and reports terminal meta refresh markup as page evidence. It does not execute JavaScript, so a client-side navigation that runs in a browser is not recorded as an HTTP hop.
Monitor URLs over time
Redirects break quietly during migrations and platform changes. Monitor your redirecting URLs and detect a loop, a changed destination or a new terminal error on a schedule.