HTTP Redirect Checker

Enter a URL to follow it hop by hop: each redirect with its status code, target, response time and IP, then the final status and response headers. For a home page the checker also tests http://, https://, www and the bare domain to confirm they all end at one canonical address.

Reading the request chain

Each row is one request. A 301 or 308 tells browsers and search engines the move is permanent; 302, 303 and 307 are temporary, so search engines may keep showing the old URL. The time column shows how long each hop took from our server, and the IP column shows which server answered.

A chain of more than two hops slows the first visit, and a loop never ends. The checker stops at 10 redirects, the same limit Googlebot uses.

One canonical address

Visitors type your domain in many ways. All four variants, http and https with and without www, should end at the same https:// URL with permanent redirects. If two variants end at different pages, search engines can index duplicates and split links between them.

On cPanel and DirectAdmin, the Force HTTPS redirect option plus one rewrite rule for www usually does the job; the .htaccess redirect generator writes the rules for you.

Response details

For the final URL the checker shows the content type, compression (gzip or Brotli), the Server header, Cache-Control and whether HTTP/3 is advertised through Alt-Svc. Missing compression on large text responses is an easy speed win.

HTTP Redirect Checker at a glance

How to use this tool

1. Enter a URL. Without a scheme the checker starts at https://; type http:// explicitly to test the HTTP to HTTPS redirect. Ports 80, 443, 8080 and 8443 are supported.
2. To check one old address, enter the full path, for example http://example.com/old-page/, and confirm it ends at the new page with a single 301.
3. To check the whole domain setup, enter just the domain. For a home page (no path, no query string) the checker also tests the four variants: http:// and https://, with and without www.
4. Press Look up and read the summary, the request chain and the variants table.

Each hop is a plain GET request, made one at a time so every response is visible. The checker reads the Location header only: redirects done in JavaScript or with a <meta http-equiv="refresh"> tag are not followed, and the final page is reported as reached. Certificate errors do not stop the chain, so you can see where an HTTPS hop leads even with a broken certificate. Results are cached for 5 minutes.

How to read the results

Row	What it means
Final URL / Final status	Where the chain ended and the status code there. Anything below 400 is green. If no final page was reached, this row says why: redirect loop, more than 10 redirects, or no response with the connection error.
Redirects	Number of hops before the final page. Amber above 2.
Temporary redirects	Shown when any hop used 302, 303 or 307, listing those URLs.
HTTPS downgrade	Shown in red when a hop sends an https:// URL to an http:// URL.
Canonical URL	For a home page: green when all four variants end at the same URL, amber when they end at different URLs.
Content type, Compression, Server	Read from the final response. Compression shows the Content-Encoding (gzip or br); amber when a text response over 1 KB is sent uncompressed.
HTTP/3	Shown when the final response advertises h3 in Alt-Svc.
Cache-Control	The caching instruction on the final response, when it has one.
Response time	Time for the last hop only, measured from our server. Amber above 1,500 ms.

In the Request chain table, hops with 301, 308 or a final 2xx are green, 302, 303 and 307 amber, and 4xx or 5xx red. In the Address variants table a variant is amber if it gets there through a temporary redirect, red if it ends in an error, and marked as information only with no DNS record when, for example, www does not exist; that is not counted as a problem.

Redirect rules that take one hop

The cleanest setup sends every variant straight to the final address. For https://example.com as the canonical address, on Apache or LiteSpeed (.htaccess, above the WordPress block):

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

On nginx, give the redirects their own server blocks so the main site block has no conditions:

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

Swap the host names if you prefer www as canonical. Use one place for the rule: a panel redirect, a plugin and a server rule all doing the same job is how loops and double hops start. The .htaccess redirect generator writes the Apache version for other cases.

Common problems and how to fix them

“redirect loop: this URL was already visited”

Browsers show this as ERR_TOO_MANY_REDIRECTS (Chrome) or “The page isn’t redirecting properly” (Firefox). Look at the request chain to see the two URLs that alternate. Common pairs:

• HTTP and HTTPS alternating: a proxy or CDN connects to the server over HTTP, so a rule based on %{HTTPS} keeps redirecting. Use Full (strict) SSL mode on Cloudflare, or have the rule check X-Forwarded-Proto.
• www and non-www alternating: the server redirects one way and the application the other. In WordPress, the Site Address in Settings » General must match the server rule.
• The same URL with and without a trailing slash: two rules disagree about slashes.

For WordPress, check the two addresses it redirects to with WP-CLI:

wp option get siteurl
wp option get home

A 302 where a 301 was intended

Many tools default to temporary redirects: PHP’s header('Location: ...') sends 302 unless you set the code, WordPress wp_redirect() defaults to 302, and in cPanel Domains » Redirects you choose Permanent (301) or Temporary (302) per rule. Change the redirect to 301 or 308 when the move is for good; Google treats 302, 303 and 307 as a weak signal and may keep the old URL indexed.

Three or more hops

Typically http://www goes to https://www, then to https:// without www, then adds a trailing slash. Each rule is right on its own, but they run one after another. Point each rule directly at the final URL, as in the examples above.

“HTTPS downgrade”

A hop sends visitors from HTTPS back to HTTP. The source is usually a hard-coded http:// address in the application, an old redirect rule, or an app behind a proxy that thinks it is on HTTP. Fix the target URL; with HSTS enabled, browsers will refuse to follow the downgrade anyway.

An old URL redirects to the home page

Sending every removed page to the home page looks tidy, but Google may treat such redirects as soft 404s and drop them. Redirect each old URL to the closest matching page, and let pages with no replacement return 404 or 410.

“no response” with a timeout

Our server got no answer within 10 seconds on that hop. The server may be down, overloaded or blocking data-centre IP ranges with a firewall or WAF. Check whether the site loads at all with the website down checker, and look for blocks in CSF, Imunify360 or the CDN firewall.

Official documentation: RFC 9110 (HTTP semantics), Google: redirects and Search.

Related guides: Cloudflare Error 521, 522 and 525 on cPanel: Proven Fixes · Cloudflare cPanel DNS Proxy: Real Visitor IPs Made Easy · cPanel Temporary Domain: Free *.cpanel.site Setup.

Frequently asked questions