Quick answer: what is a redirect chain?
A redirect chain is the sequence of HTTP responses that moves a request from its starting URL to a final destination. Check each hop's status code and destination, then confirm that the final page is the page you intended to reach.
Inspect a public URL with the Redirect Checker
Run a useful redirect check
- Copy the complete public URL, including https:// or http://.
- Open the Redirect Checker and enter the URL in the workspace.
- Run the check and review the returned hops in order.
- Check the final destination, final status and any incomplete-result warnings.
- Repeat with another URL variant only when you need to compare its behavior.
Do not paste a password-reset link, signed download URL, private token or authenticated dashboard address. The check runs from the server, without forwarding your browser's login cookies. Use a non-sensitive public test URL.
Read the response codes
301 and 308 indicate permanent redirection. 302 and 307 indicate temporary redirection. The 307 and 308 codes preserve the request method; handling of 301 and 302 can differ for requests such as POST. Check the method and the application's requirements before changing a production redirect rule.
A 200 final response means that an endpoint answered successfully at that moment. It does not establish that the content is correct, secure or indexable. A final 404 means the requested resource was not found. A 403 may indicate authorization or filtering rather than a redirect problem.
HTTP response and redirect semantics: RFC 9110
Example: an old tool URL after a redesign
Suppose a date calculator used to live at /online-age-calculator/ and now has a dedicated address under /tools/. The old URL should lead to the matching calculator, rather than an unrelated home page. Check both the old address and the final tool URL.
If there are several intermediate redirects, investigate which layer creates each hop: the application, web server, hosting platform or CDN. A deliberate host normalization redirect may be valid. Avoid adding another rule without checking the rules already in place.
Troubleshoot loops and unexpected destinations
A loop occurs when the redirect path returns to an earlier URL or never reaches a usable final resource. Common things to review include conflicting HTTP-to-HTTPS rules, opposite www rules and trailing-slash rules at different layers.
Change one rule at a time and keep a rollback copy. After changing a rule, test a normal page as well as the affected URL. Do not weaken authentication, disable certificate verification or expose internal addresses to make a checker return a green result.
Why a browser can show a different result
Your browser may use cookies, cached redirects, JavaScript, a service worker or a different network location. The checker observes a server-side HTTP path. A JavaScript navigation or HTML refresh is not necessarily part of that HTTP redirect chain.
Results can also vary by time, region or request headers. Record the starting URL and the conditions of the test before comparing results. The checker does not prove that Googlebot received the same response.
Common questions
Does a redirect automatically fix ranking? No. A correct redirect helps users and crawlers reach a replacement, but rankings depend on more than the redirect.
Should every deleted URL point to the home page? No. Use a genuine equivalent when one exists. An unrelated destination is confusing and may be treated as a soft 404.
Inspect your own URL
Open the Redirect Checker. If your next task is reviewing URL discovery, read the XML sitemap validation guide.
No published comments yet. Start the conversation.