Redirect chains
A redirect tells the browser that the page lives at another address. A redirect chain is a series of redirects where each one points to another redirect before the visitor reaches the real page:
http://example.com/blog 301 →
https://example.com/blog 301 →
https://www.example.com/blog 301 →
https://www.example.com/blog/ 200 OK
Chains rarely happen on purpose. They build up over time: an HTTP-to-HTTPS rule, then a www rule, then a trailing-slash rule, then a site migration, each added separately.
Why it matters
- Every hop costs time. Each redirect is a full request and response before the real page can even start loading. On mobile networks, a long chain adds a noticeable delay to server response time and everything after it.
- Crawlers may give up. Search engines follow a limited number of hops per attempt. Long chains waste crawl time and risk the final page not being reached.
- Signals can get lost. Search engines generally pass ranking signals through permanent redirects, but every extra hop is another place for a temporary redirect, a loop or a broken link to creep in.
- Loops break the page entirely. A redirect that eventually points back to itself never resolves, and browsers show an error.
What we check
We follow the redirects from the URL you entered, one at a time, and count the hops:
| Result | Redirect hops before the final page |
|---|---|
| Pass | 0, 1 or 2 |
| Needs attention | 3 or more |
The report lists each hop with its status code. We follow at most five redirects; if the chain is longer or loops, the final response is still a redirect, and the HTTP status check fails as well.
Two hops are fine and common, for example http://example.com → https://example.com →
https://www.example.com. One is better.
How to fix
Redirect straight to the final URL. Each rule should point to the final, canonical address, not to an intermediate one. Decide on one scheme, one host and one trailing-slash style, and combine the rules so any old variant lands there in a single hop.
In Nginx, handle HTTP and the non-preferred host in one step:
server {
listen 80;
listen 443 ssl;
server_name example.com;
# ssl_certificate ... (needed for the 443 listener)
return 301 https://www.example.com$request_uri;
}
server {
listen 80;
server_name www.example.com;
return 301 https://www.example.com$request_uri;
}
In Apache (.htaccess), one rule for both cases:
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^ https://www.example.com%{REQUEST_URI} [L,R=301]
Replace www.example.com with your preferred host. If you serve the bare domain instead, swap the
logic.
Update old redirect maps after a migration. If /a redirects to /b, and a later change
redirects /b to /c, edit the first rule to point straight to /c.
Fix internal links. Links in your navigation, content, canonical tags and sitemap should point to final URLs, so visitors and crawlers do not hit redirects at all.
Use the right redirect type. For moves that are permanent, use 301 Moved Permanently or
308 Permanent Redirect. Use 302 or 307 only for temporary moves. 307 and 308 keep the
request method, which matters for form submissions and APIs; for ordinary pages, 301 and 308
behave the same way for search engines.
Check CDN and platform settings. CDNs, hosting platforms and CMS plugins can each add their own redirects (HTTPS, www, trailing slash). If your server already handles one of these, turn off the duplicate.
Checking a chain yourself
curl shows every hop:
curl -sIL http://example.com/blog | grep -iE '^(HTTP|location)'