Redirect Checker

It shows where a URL really sends visitors and search engines. You get every hop between the address you typed and the page that finally answers, with the status code and timing of each one. That answers three questions at once: is the redirect firing, does it point at the right destination, and how many hops are wasted along the way.

A 301 says the move is permanent: browsers cache it, and Google consolidates the old URL's ranking signals into the new address and keeps the old one only as an alternate name, so it usually stops appearing in results but can still surface when a query suggests users trust it. A 302 says the move is temporary, so the original URL normally stays indexed and the response is not cached unless the headers allow it. Use 301 for migrations and HTTPS upgrades, 302 only for A/B tests and maintenance pages.

One is the target, two is tolerable, three or more should be collapsed. Browsers abort after roughly 20 hops, and Google’s crawlers follow up to 10 redirect hops before treating the URL as an error. Every extra hop costs a round trip, a hop that switches scheme adds a TLS handshake, and a hop that changes host adds a DNS lookup as well, so a three-redirect chain can add several hundred milliseconds on mobile before the first byte of real content arrives.

Open DevTools with F12, go to the Network tab, tick Preserve log, then load the URL. Each hop appears as its own row with a 301 or 302 status; click one and read the Location header under Response Headers. The catch is that DevTools shows what your browser did, complete with your cookies, HSTS cache and extensions, so a colleague on another machine may see a different chain.

Three usual causes. Your browser has the site in its HSTS cache, so it upgrades http:// to https:// before any request leaves the machine. The site varies its answer by cookie, language header or country, and our server looks different from you. Or a meta refresh or JavaScript redirect finishes the journey in the page body, which an HTTP-level trace never sees because it only reads headers.

Yes. Switch to bulk mode and paste up to ten URLs, one per line. Each is traced separately and the results land in one table with the number of redirects, the final status, the final URL and the total time. Download that table as CSV or copy it as tab-separated text, which pastes cleanly into Sheets, Excel or a Jira ticket without any reformatting.

There is nothing visible in the URL itself. A redirect is a server response: status 301 plus a header reading Location: https://example.com/new-page. Some links advertise it in the path, such as https://www.google.com/url?q=https://example.com or an affiliate link ending in ?url=, but a plain address like http://github.com can redirect just as easily. Only the response tells you.

Find the layer that emits it, because the same rule can live in four places: an .htaccess or nginx rewrite, a CDN or DNS-level page rule, a plugin such as Yoast or Redirection, or the application router. Delete it in that one place, then purge the CDN cache and re-check. Browsers cache 301 and 308 aggressively, so test in a private window or clear the site data first.

Legitimate ones come from canonicalisation (http to https, www to non-www, adding a trailing slash), moved or renamed pages, language and country routing, link shorteners and login flows that bounce you through an identity provider. Unwanted ones usually come from an injected script, a malicious ad, or a browser extension, and those redirect from inside the page rather than in an HTTP header.

A single 301 or 308 passes ranking signals and is not a problem. Chains are, for two reasons: Google’s crawlers follow up to 10 redirect hops and report anything longer as a redirect error, and every hop delays the first byte, which feeds directly into Core Web Vitals. Loops are worse, because the page is never reachable and drops out of the index entirely. Collapse chains so the first URL points at the last.