Redirect Checker – Complete Guide to 301/302 Redirect Chains and Loops

Redirects are everywhere: HTTP to HTTPS, bare domain to www, old URLs to new ones after a relaunch, campaign links through tracking domains, short links. Browsers follow them silently, so you only notice when something goes wrong: a "too many redirects" error, a migration that lost search rankings because every old URL uses 302, a chain of five hops that slows every visitor down, or a hop that drops from HTTPS back to HTTP.

The Redirect Checker follows a URL hop by hop from the NetTools.tech server and shows every request with its status code, Location header, what changed (scheme, host, path, query) and the time it took, followed by findings about loops, downgrades, temporary redirects and long chains.

What is a redirect checker?

In simple terms

When you open a URL, the server can answer "not here, go to this other address" instead of sending the page. The browser then asks the new address, which might redirect again. A redirect checker makes those steps visible, one line per request, until a server finally answers with the page or an error.

Technical background

HTTP redirects are responses with a 3xx status code and a Location header (RFC 9110, section 15.4):

Location may be absolute (https://www.example.com/new/) or relative (/new/), in which case it is resolved against the URL that was requested. Permanent redirects may be cached by browsers, which is why a wrong 301 can keep affecting visitors after it is fixed on the server.

Search engines treat permanent redirects as a strong signal that the target is the canonical URL, and temporary ones as a sign that the original should stay indexed. Crawlers also limit how many hops they follow. Long chains therefore cost both speed and crawl efficiency.

Redirects can also be implemented outside HTTP: <meta http-equiv="refresh"> in HTML or location.href in JavaScript. Those happen only after the page is loaded and parsed and are not part of an HTTP redirect chain.

Why use a redirect checker?

• Validate migrations. Old URLs should answer one 301 or 308 straight to the matching new URL, not 302, not a chain, not the home page.
• Find loops. "Too many redirects" errors are usually two conflicting rules; the hop list shows which.
• Catch HTTPS downgrades. A hop from https:// to http:// exposes visitors and can trigger browser warnings.
• Shorten chains. HTTP → HTTPS → www → trailing slash adds three round trips before the first byte of content.
• Expand short and tracking links. See where a short link really leads before you click it or publish it.

Who should use it?

• SEO specialists planning and auditing site migrations, domain moves and URL restructures.
• Web developers and DevOps engineers configuring nginx, Apache, CDN or load-balancer redirect rules.
• Security-minded users and analysts who want to know where a short link or tracking URL ends up.
• Marketing teams checking that campaign links reach the right landing page.

How the redirect checker works

The NetTools.tech server handles each request itself instead of letting an HTTP library follow redirects automatically:

1. Validation. The URL must be http or https, without embedded credentials, on port 80, 443, 8080 or 8443. If you omit the scheme, https:// is assumed, so add http:// explicitly to test the HTTP to HTTPS redirect.
2. Destination guard. The hostname is resolved once; if any address is private, loopback, link-local or reserved, the request is refused. The connection goes to exactly that address.
3. Request. A GET request (many servers handle HEAD incorrectly) with the user agent you chose, no cookies and an 8-second limit per hop. Only the first 16 KB of each response body are read; the body is not shown.
4. Next hop. If the status is 301, 302, 303, 307 or 308 and a Location header is present, the server resolves it against the current URL, runs the full validation and destination guard again and requests it. This repeats up to 10 redirects.
5. Stop conditions. The chain ends when a non-redirect response arrives, when the next URL was already visited (loop), when 10 redirects have been followed, when a hop is blocked by the guard, or when a request fails (DNS, timeout, connection, TLS).

The user agents available are:

The analysis (findings, hop changes) runs in your browser on the returned hop list. Per-client rate limits apply, and the same website can be checked about 30 times per minute across all users.

How to use the NetTools.tech Redirect Checker

1. Open the Redirect Checker.
2. Enter the starting URL in URL, for example http://example.com/old-page. Without a scheme, https:// is used.
3. Choose Request as: Desktop browser, Mobile browser or NetTools bot (identified).
4. Press Check redirects.
5. Read the summary tiles, the final destination, the findings and the hop table.
6. Use the Try chips for sample inputs, or Preview with sample data to see a made-up four-hop chain on example.com without sending a request.

You can also open the checker with a prefilled URL by adding ?url= to its address, for example from your own documentation.

Understanding the results

Example: a chain after a site relaunch

Checking http://example.com/old-page as a desktop browser returns:

Hop  URL                                 Status                  Change
1    http://example.com/old-page         301 Moved Permanently   http → https
2    https://example.com/old-page        302 Found               adds www
3    https://www.example.com/old-page    301 Moved Permanently   new path
4    https://www.example.com/new-page/   200 OK                  final

Findings:

• Warning: 3 redirects in a row. Each adds latency; point links and old URLs straight at the final destination.
• Info: 1 temporary redirect (302). If the move is permanent, use 301 or 308.
• OK: HTTP is redirected to HTTPS.
• OK: Final destination reached after 3 redirects.

The fix: make the non-www HTTPS rule a 301, and add a rule that sends /old-page on any host and scheme directly to https://www.example.com/new-page/ in one hop.

Common use cases

• Migration audits: check a sample of old URLs per section after a relaunch or domain move.
• HTTPS rollout: confirm http:// redirects to https:// on every host name, and that nothing downgrades.
• www and trailing-slash policy: verify that only one canonical variant answers 200.
• Short and tracking links: expand a link before trusting or publishing it.
• Mobile redirects: compare the chain for Desktop and Mobile browser user agents.

Troubleshooting

Redirect loop

The chain returns to a URL already visited. Typical causes: the CDN or load balancer terminates TLS and talks HTTP to the origin, which then "upgrades" again; conflicting www and non-www rules; or an application and a web server both enforcing a trailing-slash policy in opposite directions. Fix the rule on one layer and make the origin trust the proxy's forwarded protocol header.

Stopped after 10 redirects

Either a very long chain or a loop whose URLs differ slightly each time (for example a growing query string). Look at the Change column for repeating patterns.

A hop was not followed

The Location points to a private address, a disallowed port or a non-http scheme. Internal host names leaking into Location headers usually come from a misconfigured proxy that does not rewrite redirects.

"The last request failed"

The chain reached a host that does not resolve, refuses the connection, times out or has an invalid certificate. Check that host with DNS Lookup, Port Check or the SSL Certificate Checker.

Different chain in your browser

Your browser may have cached an old 301, carry cookies (consent, language, login) or be in another country. Test in a private window, and compare with the user-agent options here.

Common mistakes

• Using 302 for permanent moves. Common in framework defaults and CMS plugins; search engines may keep the old URL indexed.
• Redirecting everything to the home page. Old URLs should go to the closest matching new page; mass home-page redirects are often treated like 404s.
• Chaining rules from different layers. CDN, web server and application each add a hop; consolidate them.
• Testing only https://. The HTTP entry point and the bare domain need checking too.
• Forgetting cached 301s. After fixing a wrong permanent redirect, browsers that cached it still follow the old target until their cache expires.

Limitations

• Only HTTP redirects (3xx with Location) are followed. Meta refresh and JavaScript redirects are not part of the chain; the Meta Tag Analyzer reports meta refresh tags on a page.
• The check runs from one server location, without cookies. Geo-based, cookie-based or A/B-test redirects may differ for real visitors.
• At most 10 redirects are followed, each with an 8-second limit.
• Only public hosts on ports 80, 443, 8080 and 8443 can be checked.
• Hop times are measured from the NetTools.tech server and include its network path to each host; they are indicative, not a performance benchmark.
• When a host has IPv4 and IPv6 addresses, IPv4 is used.

Security & privacy

The URL and the selected user agent are sent to the NetTools.tech server, which makes the requests. URLs and responses are not stored. Each target server sees requests from our server's IP address with the chosen user agent, not your IP. Cookies are neither sent nor kept between hops.

Expanding a suspicious short link here is safer than clicking it, because only the HTTP responses are retrieved and no page content is rendered or executed. Still, avoid checking URLs that contain one-time tokens (password resets, magic login links): requesting them may consume or log the token.

Related tools

• HTTP Status – status code and full response headers of a URL (guide).
• URL Shortener – create short links that use a clean single 302 hop (guide).
• Meta Tag Analyzer – canonical tags and meta refresh on the final page (guide).
• Broken Link Checker – find links on a page that redirect or are broken (guide).
• SSL Certificate Checker – diagnose TLS errors on a hop (guide).

Summary

The Redirect Checker follows a URL's HTTP redirects one hop at a time from the NetTools.tech server, re-validating every target, and shows status, Location, changes and timing for each step. Its findings point out loops, the 10-hop limit, blocked hops, HTTPS downgrades, temporary redirects and long chains. Use it to keep redirects short, permanent where they should be, and pointing at the right destination.