HTTP to HTTPS redirect checker

When a site supports HTTPS, requests to the HTTP version should automatically redirect to HTTPS — otherwise the site is accessible over two separate protocols, each looking like a different URL to search engines. This creates duplicate content, splits link equity between http:// and https:// versions, and exposes users to a "Not Secure" browser warning on the HTTP version. Google has confirmed HTTPS as a ranking signal since 2014, and modern browser features (service workers, geolocation, webcam access, secure cookies) require HTTPS to work. A single 301 redirect from HTTP to HTTPS, configured once at the web-server level, resolves all of this.

What this tool checks

• HTTPS accessibility — the site actually responds over HTTPS
• HTTP redirect behavior — http:// should redirect (3xx) to the https:// version
• Redirect status code — 301 or 308 (permanent) vs 302 / 303 / 307 (temporary)
• Redirect target protocol — the Location header should point to an https:// URL
• Path preservation — requesting http://site/some-path should redirect to https://site/some-path, not dump you at the homepage
• HTTP 200 without redirect — HTTP serves content directly, a duplicate-content problem
• HTTP-only disabled — HTTP port closed entirely is a valid secure configuration

Redirect status codes for HTTP→HTTPS

• 301 Moved Permanently — the classic choice. Permanent, transfers ranking signals, cacheable by browsers.
• 308 Permanent Redirect — modern permanent redirect that preserves the HTTP method (a POST stays a POST). Functionally equivalent to 301 for GET navigation; use when your redirect might hit non-GET requests.
• 302 Found — temporary redirect. Signals to search engines that the move may be reversed, so they hold onto the HTTP version longer. Not recommended for permanent HTTPS migration.
• 307 Temporary Redirect — like 302 but preserves the method. Still temporary, still not recommended for HTTPS migration.
• 303 See Other — rare in this context; treated as temporary.

Good vs bad examples

Good — Nginx configuration redirecting all HTTP to HTTPS with path preservation:

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

Good — Apache .htaccess:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Good — Cloudflare: enable "Always Use HTTPS" under SSL/TLS → Edge Certificates.

Bad — HTTP returns the page content directly (no redirect):

GET http://example.com/product
→ 200 OK (HTML content served)

Bad — redirect loses the path (sends everyone to the homepage):

GET http://example.com/some-article
→ 301 Location: https://example.com/  ← should be /some-article

Bad — temporary 302 redirect for what should be permanent migration:

GET http://example.com/
→ 302 Location: https://example.com/

Common mistakes

• No HTTP→HTTPS redirect configured — both versions accessible, duplicate content, split link equity
• 302 instead of 301 — temporary redirect for a permanent migration; search engines keep the HTTP version in the index longer
• Redirect without path preservation — all HTTP URLs land on the homepage; deep links from external sources break
• Redirect to non-HTTPS URL — HTTP redirects to another HTTP URL that redirects to HTTPS (chain), or to a completely different resource
• Internal links still using http:// — even with a working redirect, internal HTTP links add an extra hop for every click. Update them after HTTPS migration
• Not redirecting the www/non-www variant — covered by the separate www-redirect check but commonly combined with HTTPS migration