Redirect Checker
Follow every hop in a redirect chain, catch loops, and see which URLs are bleeding link equity through unnecessary 302s.
Learn More
A redirect chain occurs when a URL redirects to another URL which then redirects to yet another URL creating a sequence of hops before reaching the final destination. For example page A redirects to page B which redirects to page C which finally serves the content. Each hop in the chain adds latency and dilutes SEO value. Redirect chains typically form over time as websites undergo multiple redesigns domain migrations or URL restructuring. A page might have been redirected during a 2020 redesign then the destination was redirected again in 2022 creating a chain that nobody intended. Content management systems and marketing tools that automatically generate redirects can also contribute to chain buildup. A redirect loop is a more severe variation where the chain circles back to a URL already in the sequence creating an infinite cycle. Browsers detect this and display an error (ERR_TOO_MANY_REDIRECTS) making the content completely inaccessible. Both chains and loops need to be identified and resolved to maintain site health and search engine visibility.
A 301 redirect signals a permanent move. It tells search engines that the original URL has been permanently replaced by the new destination. Search engines transfer the link equity (ranking power) from the old URL to the new one and eventually remove the old URL from their index. Use 301 redirects when you have permanently moved content changed your domain or restructured your URL scheme. A 302 redirect indicates a temporary move. It tells search engines that the original URL will be back eventually so they should keep the old URL in their index and not transfer link equity to the temporary destination. Use 302 redirects for A/B testing temporary maintenance pages or geolocation-based routing where the original URL still has a purpose. Using the wrong redirect type is a common mistake. A 302 where a 301 is needed means search engines will not pass link equity to your new page potentially hurting its rankings. Conversely using a 301 for a truly temporary redirect means losing the original URL from the index. There is also the 307 (temporary) and 308 (permanent) redirect which are the HTTP/1.1 equivalents that preserve the request method — important for POST requests in APIs.
The solution to redirect chains is straightforward: update every redirect in the chain to point directly to the final destination. If A redirects to B B redirects to C and C is the final page update A to redirect directly to C and update B to redirect directly to C. This eliminates all intermediate hops. Start by auditing your entire redirect configuration. Export your redirect rules from your web server (Apache.htaccess Nginx config) your CMS and any CDN or edge rules. Map out all chains by following each redirect to its final destination. Automated tools like CheckFast trace the full chain for you making this process much faster. After identifying chains update the rules in reverse order — fix the longest chains first. For each chain create a single redirect from the original URL to the final destination. Remove the intermediate redirect rules if they are no longer needed by any other URL. Also update internal links throughout your site to point to final destination URLs rather than URLs that redirect. This eliminates unnecessary server round trips speeds up page navigation and ensures that link equity flows directly to the correct pages without any dilution through redirect hops.
Frequently asked questions
301 and 302 are HTTP/1.0; 307 and 308 are HTTP/1.1. The key functional difference: 301/302 historically allowed browsers to change the HTTP method (POST → GET) on redirect which could break form submissions and APIs. 307 (temporary) and 308 (permanent) forbid that — the redirected request uses the same method + body as the original. For API endpoints or form POSTs always use 307/308. For normal browser navigation 301/302 still work fine and are more widely cached.
Google's crawler (Googlebot) follows up to 10 redirects per URL. After that it gives up and drops the URL for that crawl. But it re-attempts at a lower frequency on future crawls. The practical SEO impact: chains of 2-3 are inefficient; chains of 4-5 waste significant crawl budget and slow indexing; chains of 10+ effectively block indexing. Browsers vary — Chrome gives up around 20 hops Firefox around 20 Safari around 16. Always target zero or one redirect.
No — HTTP → HTTPS is the single most important redirect you'll implement and Google expects it. The pattern: one 301 from http://example.com/page directly to https://example.com/page. Avoid double-hops like HTTP → HTTPS non-www → HTTPS www — collapse them into one redirect. Use HSTS (Strict-Transport-Security header) to tell browsers to skip the HTTP hop entirely for future visits. After a full year of HTTPS adoption you should see zero HTTP hits in your logs outside of the initial handshake.
The official Google position is that 301 302 307 and 308 all pass PageRank equally. In practice there's still lingering asymmetry: 302s keep the old URL in the index longer (because they signal temporary ) which can create duplicate content issues and delay ranking transfer. If the move is permanent always use 301 — it's faster clearer to crawlers and removes any ambiguity. Reserve 302/307 for A/B testing seasonal content swaps or geolocation.
No and both are worse for SEO. Meta-refresh () is treated by Google roughly like a 302 — it can work but is slower and less reliable across bots. JS redirects (window.location =...) require the crawler to render the page which delays indexing and can fail entirely for non-rendering crawlers. Always prefer a server-side HTTP redirect (301/302/307/308) — it's faster for users unambiguous for crawlers and the only option for non-HTML resources like PDFs or images.
More in Delivery & SEO
Reachability, discoverability, and page performance for humans and crawlers.