Redirects are one of the quietest parts of a website. When they work, nobody notices them. When they go wrong, pages load slowly, visitors land in the wrong place, and search engines waste effort following a trail of hops instead of indexing content. The good news is that redirect problems are among the easiest SEO issues to diagnose, because a checker shows you the whole trail: every hop, its status code, and how long it took.
This guide walks through a real-style check using the On-Page SEO and Redirect Checker, explains what each part of the report means, and shows how to shorten chains without breaking the links that depend on them.
What a redirect actually is
When a browser or search engine requests a URL, the server can answer with the page itself, or it can answer with an instruction: go to this other URL instead. That instruction is a redirect, delivered with a 3xx status code and a Location header naming the next URL. The browser follows it automatically, and the visitor usually never sees the intermediate address.
Redirects exist for legitimate reasons. A site moves from HTTP to HTTPS. A page moves to a new address. A domain changes its preferred form, from example.com to www.example.com or the other way round. A short campaign link points at a longer page. Each of these is one clean hop from an old address to a new one, and that is exactly how redirects should behave.
Reading the chain in a checker report
Paste a URL into the checker and the first section of the report is the redirect chain. Read it top to bottom: each row is one hop — the URL requested, the status code returned, and the time that hop took. The final row is the destination, which should return a 200, meaning the page was served.
The status code on each hop is the most informative part. A 301 means the move is permanent, and search engines should update their records to the new address. A 302 means the move is temporary: the old address is still the real one, and search engines should keep it. A 307 is similar to a 302 but stricter about preserving the request method, and a 308 is the permanent equivalent of 307. Using a 302 where you mean 301 is a common mistake — it tells search engines to keep showing the old address.
Timing matters too: every hop adds a round trip to the server. One hop is barely noticeable; four or five hops on a mobile connection can add a visible delay before anything renders. The checker's per-hop timings show whether the delay comes from the number of hops or from one slow server in the middle.
Where chains come from
A chain forms when redirects accumulate over time, each one added without checking what already exists. A typical story goes like this. A site launches at http://example.com. Later it adds HTTPS, so HTTP redirects to HTTPS. Later it standardises on www, so the non-www HTTPS version redirects to the www version. Later a page is renamed, so the old page redirects to the new page — but the redirect is written from the old address to the intermediate address that was current at the time, not to the final one. The result is a request that hops from HTTP to HTTPS, then to www, then to the renamed page: three hops where one would do.
Other common sources include content management systems and plugins that each add their own redirect rules, marketing tools that wrap a destination in a tracking redirect, and old rules never cleaned up after a redesign. None of these is malicious; they are the ordinary sediment of a site maintained for years, which is why chains are worth checking periodically, not only after a migration.
Worked example: following a three-hop chain
Imagine checking an old blog post URL that was shared widely years ago. The checker returns:
http://example.com/old-post— 301 tohttps://example.com/old-post, 120 mshttps://example.com/old-post— 301 tohttps://www.example.com/old-post, 140 mshttps://www.example.com/old-post— 301 tohttps://www.example.com/new-post, 180 mshttps://www.example.com/new-post— 200, page served
Nothing here is broken, exactly: every hop is permanent, and the final page loads. But the visitor waited through three redirects, and a search engine following the old shared link must do the same work on every crawl. The fix is to collapse the chain at its source: change the first rule so the old HTTP, non-www address points directly at https://www.example.com/new-post. After the change, the check should show one hop and a 200.
Before changing any rule, note where the old URL is linked from. Internal links should point directly at the final URL, so update those too. External links you cannot control are exactly what the redirect is for; the redirect stays in place, it just gets shorter.
What a loop looks like, and how to break it
A loop is a chain that never ends. Page A redirects to page B, and page B redirects back to page A, or a longer circle of pages each points at the next until the trail returns to the start. Browsers detect this and stop with an error such as "too many redirects", and the page never loads at all. Unlike a chain, a loop is not a performance problem; it is a total failure for that URL.
Loops usually come from two rules contradicting each other: a plugin redirecting a page one way while a server rule redirects it back, or a trailing-slash rule fighting a non-trailing-slash rule. The checker report makes the circle visible: the same URLs repeat, or the check stops after a maximum number of hops without reaching a 200. To break the loop, decide the real final destination, correct the rule that points away from it, and re-check until the report shows a single hop to a 200.
How to shorten a chain safely
Work in this order. First, run the checker on the old URL and save the full chain, so you have a before-and-after record. Second, decide the final destination and the correct status code: 301 for a permanent move, 302 only for a genuinely temporary one. Third, edit the redirect at its source so the earliest rule points straight at the final destination. Fourth, update internal links to point at the final URL directly. Fifth, re-run the checker and confirm the chain is now one hop, the status codes are as intended, and the final page returns 200.
Two cautions apply. Do not delete a redirect just because its target page looks old: if other sites link to that address, removing it turns those links into 404 errors. And do not "fix" a chain by redirecting everything to the homepage; the final destination should be the closest equivalent page, or a helpful category index — not a blanket homepage catch-all.
If the chain involves a sitemap question — for example, your sitemap still lists the old redirected addresses — the Robots and Sitemap Checker can confirm what robots.txt and the sitemap currently declare. And if you are rebuilding the destination page itself, the Schema Generator helps you add valid structured data to it once the redirect work is done.
Honest limitations
A checker reports on-page and server signals for the URL you give it; it cannot guarantee rankings or traffic, and it cannot see redirects that only trigger for certain visitors, such as rules based on location, device, or login state. If a redirect behaves differently for you than for the checker, a conditional rule is the likely cause, and you will need to test with the relevant condition yourself.
Server checks also have practical limits. A site that is slow, temporarily down, or rate-limiting automated requests may return incomplete results, so a failed or partial check is not proof that the page is broken — wait and retry before changing rules. For the full repair method, including the correct server rules for common cases, see How to Fix Redirect Chains and Redirect Loops.
FAQs
Is one redirect bad? No. One redirect is normal and expected, for example from HTTP to HTTPS. Problems start at two or more hops, and get worse with each additional hop.
Should I use 301 or 302? Use 301 for a permanent move and 302 only when the change is genuinely temporary. The wrong choice does not break the page for visitors, but it changes how search engines treat the old and new addresses.
Can a redirect chain hurt even if the page eventually loads? Yes, in two ways: each hop adds loading delay, and search engines may stop following a very long chain before reaching the content. Shortening the chain removes both problems.
human review pending client designation