Redirect Checker

301 vs 302, chains and loops: what every redirect tells a crawler.

A redirect is a small promise a server makes about where a page lives now. Here is how to read one, why the number of hops matters more than most people think, and what to check after any change to your site, including the links you can no longer edit.

What a redirect is, and what a hop is

When a browser or a crawler asks for a URL, the server can answer with the page, or with a status code in the 300s and a Location header naming another address. The client then asks for that address instead. Each of those exchanges is one hop. A redirect chain is the whole sequence, from the address someone typed or clicked to the response that finally carries a page.

Your browser hides the chain: it follows every hop and shows you only where it ended. That is why you need a redirect tracker to see it. This is a real trace from Willowdale Equity's site, run while this page was built, for an old-style link to one of its articles:

# http://www.willowdaleequity.com/blog/1099-vs-k1, traced 27 Sep 2026
301  http://www.willowdaleequity.com/blog/1099-vs-k1
     Location: https://willowdaleequity.com/blog/1099-vs-k1
308  https://willowdaleequity.com/blog/1099-vs-k1
     Location: /blog/1099-vs-k1/   # relative, resolved by the tracer
200  https://willowdaleequity.com/blog/1099-vs-k1/

Three requests, two redirects. The first hop fixes two things at once: it moves the request from http to https and drops the www. The second adds the trailing slash the site uses for its articles. Every hop worked, the page arrived, and nothing about this chain is broken. It is simply one hop longer than it needs to be, which is exactly the kind of thing a browser never shows you.

301 vs 302, 307 and 308

Four redirect codes do almost all the work on the web. They differ on two questions: is the move permanent, and may the client change the request method (turning a form's POST into a plain GET) when it follows.

The Google column is taken from Google Search Central's page on redirects, which also groups 303 See Other with the temporary codes. The practical rule: if a page has moved for good, use a 301 or a 308; use a 302 or a 307 only when the old URL is coming back, for maintenance, a short campaign, or a location-based detour. A temporary redirect left in place for a year is the most common redirect mistake after the chain itself, because the old address can keep being treated as the real one.

On value, the question everyone asks: Google's Gary Illyes wrote in July 2016 that "30x redirects don't lose PageRank anymore." The type of redirect changes which URL Google treats as canonical; it is not a dial for how much ranking signal passes through. What does matter is where the redirect points. The signal follows it to whatever page is at the end, so send an old page to its real replacement, not to the homepage. For what each status code means on its own, including the 4xx and 5xx answers a chain can end on, the HTTP Status Code Checker has the full list.

Redirect chains: why one hop beats three

A chain is any redirect that lands on another redirect. Chains are rarely designed. They accumulate: the site moved to https one year, dropped www the next, adopted trailing slashes with a new host after that, and each change added its rule on top of the last. Every link written before the first change now pays for all three.

Each hop is a full round trip before the page can start loading. From our server Willowdale's hops above took between 45 and 96 milliseconds each; a visitor on a mobile connection pays the same number of round trips at their own latency. Crawlers have a limit too. Google documents that its crawlers follow up to 10 redirect hops by default, and Search Console reports failed redirects as errors. Most chains are far shorter than that, which is why they survive: nothing breaks, so nobody looks.

Using this as a redirect chain checker, the fix is always the same shape. Point every old address straight at its final URL in one permanent redirect, then update the things you control so they skip the redirect entirely: internal links, the canonical tag, the XML sitemap, and the URL in your email signature. Verand's deep crawl flags any page that redirects on every customer site, for exactly this reason; this tool shows the hop-by-hop chain behind that flag.

Redirect loops and ERR_TOO_MANY_REDIRECTS

A loop is a chain that never reaches a page: A sends you to B, and B sends you back to A, sometimes through several addresses in between. Browsers give up after a fixed number of redirects (Chrome's limit is 20) and show an error, which in Chrome reads ERR_TOO_MANY_REDIRECTS. This checker stops sooner: it flags a loop the moment the same URL comes round a second time, and marks the trace as failed if it reaches ten hops without landing.

Loops usually come from two rules that each think they are in charge. A CDN or proxy talks to your server over plain http while the server insists on https, so the server redirects, the proxy asks over http again, and around it goes; Cloudflare's own troubleshooting guide lists this as a cause. Two plugins, or a plugin and the host, disagree about www or the trailing slash. A login page redirects to a page that requires login. The trace shows you which two URLs are arguing, and one of those two rules has to go.

The four doors: http, https, www and bare

Every domain can be reached four ways: http://example.com, http://www.example.com, https://example.com and https://www.example.com. People type all four, old links carry all four, and a crawler that finds two of them answering with a page has two copies of your homepage to choose between. The goal is dull and precise: all four land on one URL, in one hop, with a 200.

Tick the host forms box and the checker traces all four at the homepage in the same run. On Willowdale's domain, all four land on https://willowdaleequity.com/, three of them in one hop and the fourth because it is already there. When two forms land on different URLs, the card says which, and writes out the redirect that would close the gap. You choose which host is the real one; either is fine, so long as there is exactly one. The HTTPS Checker looks at the same doors from the security side, including mixed content and HSTS.

Trailing slashes

To a server, /guide and /guide/ are two different URLs. Many hosts pick one and redirect the other, usually with a 308. The two sites we traced for this page pick opposite conventions: Willowdale adds the slash to its articles, and verand.ai removes it, so https://verand.ai/blog/ answers 308 to https://verand.ai/blog. Neither is wrong. What costs a hop is linking to the form your own server redirects away from, which is easy to do when one person writes URLs with slashes and the platform writes them without.

Server, meta refresh and JavaScript redirects

A server redirect is the status code and header described above, and it is the kind this checker reads. Two other kinds live inside the page. A meta refresh tag tells the browser to load another URL after a delay; Google interprets an instant one as a permanent redirect and a delayed one as temporary. A JavaScript redirect changes window.location in a script, and Google only sees it if rendering the page succeeds, which is why its guidance is to use one only when a server or meta refresh redirect is not possible. This checker never reads the page body, so both of those show up here as a 200 that goes nowhere. WhereGoes and a few other tracers do follow them; if you suspect one, check there, then move the redirect to the server.

The links you can no longer edit

For most sites a broken redirect costs some traffic. For a firm in a regulated field it can put the wrong document in front of a client. Links go into places nobody can edit afterwards: emails already sitting in inboxes, PDFs that were filed or downloaded, brochures and business cards, QR codes on printed material, directory and social profiles written years ago. When the site is rebuilt, those links either chain through the old structure or stop at a 404, and a link to an old disclosure or fee page can land on a newer version of it, or on nothing at all.

So after any site change, rebuild or platform move, check redirects on the addresses you have published, not only the ones in your navigation:

• The homepage, in all four forms. The one check that catches a whole class of problems at once.
• Every URL printed on paper or in a QR code. Brochures, business cards, signage, direct mail. These cannot be reissued cheaply.
• Links inside PDFs. Disclosures, fee schedules, privacy notices, offering and onboarding documents. Open the file and trace each link it contains.
• Links in email templates and past campaigns. The signature block, the footer, and anything a client might reopen next year.
• The old address of every page that moved. If /disclosures became /legal/disclosures, the old one should 301 to the new one in one hop, and land on the version you mean it to.
• Profile links you set once. Directory listings, bar or association profiles, social bios and review sites.

The result you want on each is the same: a 200, on the page you intended, in no more than one hop.

Using it as a 301 redirect checker after a migration

Enter the old URL, not the new one. A good result is one 301 or 308, straight to the new address, which then answers 200. If you see a 302, the move is being announced as temporary. If you see two hops or more, the migration's rules are stacking on older ones. If the final answer is a 404, the redirect is missing, and the old link is dead.

This checker traces one URL at a time. For a migration of hundreds of pages, bulk tools such as httpstatus.io and urllo take a list of URLs in one go, and a crawler will find redirects inside your own links; use those for the sweep, and this page for the URLs that look wrong, where seeing every hop and the exact Location each server sent is what tells you which rule to change.