HTTP Redirect Checker

What are HTTP redirects?

An HTTP redirect is a server response that tells the browser or search engine to navigate to a different URL. When a server returns a 3xx status code along with a Location header, the client automatically makes a new request to the destination. The original URL is effectively forwarded.

Redirects are used to upgrade plain HTTP traffic to HTTPS, to consolidate www and non-www variants onto a single canonical URL, to handle domain migrations, and to preserve old URLs when site structure changes. When configured well, redirects are invisible to users. When misconfigured, they cause loops, broken pages, or slow load times.

301 vs 302 vs 307 vs 308 — which redirect type to use

The HTTP status code in a redirect determines whether it is permanent or temporary, and whether the browser preserves the original request method. Choosing the wrong type can hurt performance, SEO authority, or browser caching behavior.

For standard HTTP → HTTPS and www canonicalization redirects, 301 is the correct choice. It is permanent, browser-cached, and transfers SEO authority to the destination. Use 302 or 307 only when the redirect is genuinely temporary.

Why HTTP → HTTPS redirects matter for security

When a user types a domain name without a protocol prefix, or follows an old http:// link, the browser sends a plain, unencrypted HTTP request first. Without a redirect, the server might respond over plain HTTP — exposing the user's session to eavesdropping on public Wi-Fi or corporate networks.

An HTTP → HTTPS redirect ensures all traffic is automatically upgraded to TLS. The server responds to the HTTP request with a 301 and the browser immediately re-requests the page over HTTPS. This is the first line of defense for enforcing encryption, and it works even before HSTS has been established.

server {
  listen 80;
  server_name example.com www.example.com;
  return 301 https://$host$request_uri;
}

<VirtualHost *:80>
  ServerName example.com
  ServerAlias www.example.com
  Redirect 301 / https://example.com/
</VirtualHost>

In Cloudflare, enable Always Use HTTPS under SSL/TLS → Edge Certificates. This forces all HTTP traffic to HTTPS at the CDN level before it reaches your origin.

How HTTP redirects relate to HSTS

HTTP redirects and HSTS (HTTP Strict Transport Security) are complementary mechanisms — they solve the same underlying problem at different layers, and a well-configured site should use both.

What causes redirect loops and how to fix them

A redirect loop occurs when a URL's redirect chain never terminates — URL A redirects to URL B which redirects back to URL A, or through a longer cycle. Browsers detect this and show "ERR_TOO_MANY_REDIRECTS". No page is loaded; the site is effectively broken for that URL variant.

Why excessive redirect chains hurt performance and SEO

Each redirect in a chain requires a complete HTTP request/response round trip — typically 50–300ms on a fast connection, more on mobile networks. A chain with 4 hops adds 200ms–1,200ms of latency before the page even starts loading. Google has confirmed that redirect chains longer than 5 hops may be cut off by the crawler entirely.

Chains grow over time through accumulated redirect rules. A URL restructuring adds one hop, a domain migration adds another, and an HTTPS upgrade adds another — and suddenly http://old-domain.com/page requires 4 hops to reach the canonical URL.

Canonical URLs and www vs non-www

A canonical URL is the single, authoritative version of a page that you want search engines and users to use. For most sites, this means all four URL variants (http/https × www/non-www) should ultimately redirect to the same URL — for example, all of http://example.com, https://example.com, http://www.example.com, and https://www.example.com should resolve to https://example.com/ (or https://www.example.com/ if you prefer www).

If both www and non-www serve the same content independently (without redirecting), search engines see them as separate sites. Link equity is split between them, duplicate content penalties may apply, and crawl budget is wasted. Choosing one and redirecting the other is straightforward and has a meaningful SEO benefit.

server {
  listen 80 default_server;
  server_name example.com www.example.com;
  return 301 https://example.com$request_uri;
}
server {
  listen 443 ssl;
  server_name www.example.com;
  return 301 https://example.com$request_uri;
}

# Redirect all http to https://www
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^ https://www.example.com%{REQUEST_URI} [L,R=301]

Frequently asked questions

Related tools