301 Redirect Checker

What are HTTP redirects?

HTTP redirects tell the browser to load a different URL than the one originally requested. They are used for domain migrations, enforcing HTTPS, canonicalizing URLs (www vs non-www), and handling moved content.

What is the difference between 301 and 302 redirects?

A 301 redirect is permanent — it tells search engines to transfer all ranking authority to the new URL. A 302 is temporary — search engines keep the original URL indexed. Use 301 for permanent moves and 302 for temporary changes.

What this tool checks

We follow the redirect chain hop by hop, recording each step: the request method, the response status code (301, 302, 303, 307, 308), the Location header's resolved URL, the TLS / non-TLS state at each hop, the latency from request to response, and any header changes worth noticing (HSTS appearing or disappearing, cookies dropped, Cache-Control hints). The whole trace runs from a real HTTP client — not by reading meta-refresh or scanning HTML — so the result matches what curl, Googlebot, and most CDNs see. The final destination URL, its status code, and the cumulative chain length are surfaced explicitly. Method preservation is called out per hop: 301 / 302 / 303 silently downgrade POST to GET in most clients, while 307 / 308 preserve the original method — getting this wrong is the most common cause of broken form submissions after a domain change.

How we interpret the results

Each hop receives a grade: pass (normal forward step), warning (works but suboptimal — an extra hop, a method-preserving status used where a permanent redirect would be cleaner, a www↔apex flip after the HTTPS step that could have been combined), or critical (breaks something — http inside an https chain, a redirect loop, more than 10 hops, status 302 used for a permanent move which loses SEO link equity). The overall result is rejected as a loop if any URL appears twice in the chain; the loop is highlighted at the hop that closes it so you can see which redirect rule needs to change. Cumulative latency is reported as a single number so you can decide whether the chain length is impacting page load — every hop is at minimum a TLS handshake plus a round trip, so a 5-hop chain on mobile can easily cost a second of perceived load time.

Common findings on real sites

Four redirect patterns dominate. First, an unnecessary http→https hop on the apex domain because HSTS preload is not enabled — every first-time visitor pays one extra TLS handshake. Second, the www↔apex flip happens in two stages (http://www → https://www → https://apex) instead of one (http://www → https://apex), doubling the chain length on the most common visitor pattern. Third, 302 used where 301 belongs — usually because the developer copied a sample from Stack Overflow and never thought about it; the cost is real, because Google's link-equity transfer through a 302 is treated as temporary and weaker than a 301. Fourth, trailing-slash inconsistencies that force two different canonical URLs ('/about' and '/about/') with a redirect between them — pick one canonical form at the framework level and stop the application from emitting both.

How to fix common redirect issues

Pick one canonical hostname (apex or www, almost always apex these days for cleaner cookies) and one canonical scheme (https) and configure the server to send a single 301 from any non-canonical combination directly to the canonical form. Submit the domain to the HSTS preload list (hstspreload.org) so browsers skip the http→https hop entirely on first visit. For trailing-slash policy, choose 'always trailing' or 'never trailing' at the framework level (Next.js trailingSlash: false, Express express-slash, etc.) and stop emitting both forms. For SPA-style hash routing migrations, replace meta refresh and JavaScript-based redirects with server-side 301 / 308 so search engines and CDNs handle the hop correctly. After every change, re-trace the chain on the most common entry points (apex, www, http variants of each) — what looks like a single rule change is often three rules that need to align.

Why redirect quality matters

Every redirect costs at minimum one full round trip plus a TLS handshake on mobile. A chain of three redirects on a 4G connection in a weak-signal area is often the difference between a 1-second perceived load and a 4-second one — and 4 seconds is the well-documented threshold past which a large fraction of visitors abandon. From an SEO angle, redirects pass link equity but the transfer is lossy: each 301 hop attenuates the signal slightly, and 302 / 307 hops are treated as temporary (essentially no equity transfer). For analytics, redirects break referrer chains: the analytics call on the final landing page sees the previous hop's URL as the referrer, not the original entry point, which silently distorts attribution. And for accessibility and slow-network users, every avoidable hop is friction. Getting the redirect chain to a single 301 from any non-canonical entry is one of the cheapest meaningful performance + SEO wins available.