Redirect Checker

How it works

1. Each URL is requested from our server with a Chrome user-agent (and, if selected, again as Googlebot); redirects are not followed automatically — every hop is a separate request so its status, Location, Cache-Control and time are recorded
2. Up to 10 hops per chain; a URL seen twice is a loop; 8 s per request and 25 s per chain; every hop passes the same public-host checks (no private, link-local or localhost targets)
3. Only the final response body is read, only when it is HTML, capped at 256 KB — to find <meta http-equiv="refresh">, inline location.href / location.replace() patterns and the <link rel="canonical">
4. Findings per chain: no redirect / final OK / final error (4xx–5xx), loop, hop cap reached, more than 3 hops, 302 or 307 in the chain, 303, relative Location, http→https→www split into two hops, https→http downgrade, host change, meta-refresh, JavaScript redirect, canonical differs from final URL, slow chain (> 3 s)
5. With the Googlebot option the two chains are compared: a different final URL or status is flagged — the classic sign of user-agent-based cloaking or a bot-only redirect
6. Bulk: up to 20 URLs per run, 5 in parallel; the hop table of every chain can be downloaded as CSV

About redirects and what the checker reports

A redirect tells a client that the resource lives at another URL. For search engines the status code carries meaning: 301 and 308 say the move is permanent, so ranking signals should consolidate on the target and the old URL can drop out of the index; 302 and 307 say the move is temporary, so the original URL should keep its place. Google has said for years that it treats long-standing 302s as permanent in practice, but it still has to guess — a 301 removes the guess. 303 is a POST-to-GET idiom that has no place in a site migration. The checker shows every hop's code so the intent of the chain is visible, not inferred.

Chains cost crawl budget and dilute signals a little with every hop, and Googlebot gives up after ten. The usual culprit is not one bad rule but several correct ones stacked: http to https on the web server, non-www to www in the CMS, a trailing slash from the framework, and a URL rename in the application — four hops where one would do. The checker names the http→https→www pattern explicitly because it is the most common and the easiest to collapse into a single rule that jumps straight to the final URL.

Not all redirects are HTTP. A page that returns 200 and then moves the visitor with <meta http-equiv="refresh"> or a line of JavaScript is a redirect to the user but a normal page to a crawler that does not run scripts — and Google, which does render JavaScript, treats these as weak signals compared with a server-side 301. The checker reads the final HTML for both patterns and reports them; it does not follow them, because that is the point: the HTTP chain and the real destination differ.

Fetching as Googlebot alongside a browser catches two problems at once. Bot-only redirects — sending crawlers to a different page than users — violate Google's cloaking policy whether or not they were intended (a misconfigured bot-protection or geo rule is enough). And some sites redirect browsers by language or country while leaving Googlebot on the default, which is fine, but should be known. The checker compares final URL and status between the two agents and says whether they match. What to do with a difference depends on why it exists; the checker reports it.

Frequently asked questions

301 or 308?

Both are permanent. 308 additionally forbids the client from changing the method (a POST stays a POST), which matters for APIs and forms, not for pages. For site moves 301 is universally understood; 308 is fine too. Google treats them the same for indexing.

Does a 302 hurt SEO?

Not necessarily. Google has said it treats a 302 that stays in place as permanent after a while, and it consolidates signals either way. The problem is ambiguity: a 302 says 'this is temporary', so during a migration the search engine may keep the old URL indexed longer than you want. When the move is permanent, say so with a 301 — the checker flags 302/307 in a chain so you can decide.

How many hops are too many?

Google follows up to 10 redirects per chain; beyond that the page is not crawled. Each hop adds latency for users and a little signal loss for search, so the working rule is one hop, two at most. The checker warns above three. Fix chains by redirecting the first URL directly to the last, not by removing intermediate rules that other URLs still need.

Why does the checker say the final page has a canonical that differs?

Because the HTML the chain ends on points its <link rel="canonical"> at a different URL than the one you landed on. A redirect to page B whose canonical says page C tells Google two different stories. Usually one of the two is stale after a migration; the checker reports the mismatch and both URLs.

What is a redirect loop and why does the checker stop early?

A loop is a chain that returns to a URL it already visited — A to B to A. Browsers show an error, crawlers give up. The checker stops the moment a URL repeats and marks the chain as a loop; it also stops at 10 hops whether or not the chain is looping, because Googlebot does.

Why fetch as Googlebot?

Some sites — by intent or by a misconfigured rule — send crawlers somewhere else than browsers. Redirecting Googlebot to a different page than users is cloaking under Google's spam policies; redirecting browsers by language while leaving bots on the default is common and acceptable but worth knowing about. The checker runs the chain twice with the two user-agents and reports whether the final URL and status match. Note that some bot-protection services block anyone claiming to be Googlebot from an unverified IP, so a 403 for the bot run can be that, not a redirect rule.

Does the checker follow meta refresh or JavaScript redirects?

No. It detects them in the final HTML and reports the target, but the chain it shows is the HTTP chain, which is what a crawler that does not execute scripts sees. Google does render JavaScript and treats these as redirects, but slower and with less certainty than a server-side 301. If the tool reports one, the real destination is a step further than the table shows.