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
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
- 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.
- Add a permanent (301) redirect from http:// to https:// in your hosting panel, server configuration or CDN; many hosts offer a "force HTTPS" switch.
- 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-8There 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
- Google, How to specify a canonical URL with rel="canonical" and other methods — says Google prefers HTTPS pages by default, and lists a redirect or a rel="canonical" link from the HTTP page to the HTTPS page as ways to make sure of it. Checked 25 September 2026.
Editorial review: 29 September 2026