The http:// version of your site does not redirect to https://

In the reportHTTP does not redirect to HTTPS

http_not_redirected_to_https · Issue

Short answer

This appears when the http:// version of your homepage, with or without www, answers with a page, directly or after redirecting to another http:// address, instead of reaching https://. Visitors and links that arrive there stay on an unencrypted copy. Add a permanent redirect from each http:// version to its https:// address.

Severity: Medium. Fix it in your next round of site changes. It is kept for review instead when each such version names one https:// address as its canonical, which Google lists as another way to prefer the secure page.

Why it matters

Google prefers HTTPS pages by default, and lists a redirect from the HTTP page to the HTTPS page, or a rel="canonical" link to it, as ways to make sure of that. Without either, the http:// homepage stays a separate, unencrypted copy that people and links can reach.

What to do

  1. Look at the finding: it lists the http:// versions that answered with a page and, for each of the four homepage versions, the final address, the status and the number of redirects.
  2. Add a permanent (301) redirect from http:// to https:// in your hosting panel, server configuration or CDN; many hosts offer a "force HTTPS" switch.
  3. Cover both versions, with and without www, and make sure the https:// page they reach answers normally.

When to leave it as it is: Leave an HTTP homepage serving content only as a temporary migration state if you cannot redirect it yet. An HTTPS canonical can guide search engines, but it does not encrypt a visitor's HTTP connection; plan to redirect both HTTP homepage versions.

What we read

We request the four versions of your homepage: http:// and https://, with and without www, built from your registered domain and ignoring robots.txt. This check reads the two http:// versions and follows up to ten 301, 302, 303, 307 or 308 redirects; a meta refresh or a script redirect is not followed. Each request is retried once after a dropped connection, a 429 or a server error.

A version is reported when it ends on an http:// address that answers 200, and all such versions go into one finding for the site. A version that cannot be reached, or ends with another status, is not judged.

Example & evidence

Illustrative example — one site, not a live audit.

The site is https://bakery.example/. We request its http:// homepage:

GET http://bakery.example/
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8

There is no redirect and the page names no https:// canonical, so the site is reported as an issue with http://bakery.example/ as the affected address; http://www.bakery.example/ redirects to https:// and is not listed. Had the page named https://bakery.example/ as its canonical, the finding would be kept for review.

A possible correction:

GET http://bakery.example/
HTTP/1.1 301 Moved Permanently
Location: https://bakery.example/

Confirm & check again

Check for yourself: a browser may switch to https:// by itself, so make a GET request to each http:// version, with and without www, in a tool that follows redirects and shows the final address and status. Each version should end at an https:// address that answers 200; an intermediate http:// redirect alone does not fail this check.

Check again: Full audit — run a new audit of the site; it requests the four homepage versions again. The finding is confirmed fixed only when both http:// versions end at an https:// page that answers 200, and the audit is complete: not cut short by its page limit, with every address it found fetched and answered 200, and none refused by robots.txt. If a version cannot be reached, for example because www has no DNS record, the fix cannot be confirmed.

Limits & sources

Only the homepage of each version is requested, so other http:// addresses are not tested, and neither is the redirect type: a temporary 302 or 307 to https:// passes. The versions are built from your registered domain, so for a site at shop.bakery.example the check reads bakery.example and www.bakery.example, not the subdomain. HSTS is not checked.

Confidence: High because the status and final address of each request are read directly.

Sources

Editorial review: 29 September 2026