A secure address passes through an insecure one
In the reportHTTPS redirects through HTTP
https_redirects_to_http · Issue
This appears when the https:// version of your homepage, with or without www, redirects to an http:// address or passes through one on its way. The secure connection is dropped at that step, and Google says such redirects make it prefer HTTP very strongly. Redirect straight from one https:// address to another.
Severity: High. Fix it soon: while it stands, Google may choose the http:// address over the secure one.
Why it matters
Google prefers HTTPS pages unless signals conflict, and one it lists is an HTTPS page that redirects users to or through an HTTP page. It advises avoiding HTTPS-to-HTTP redirects because they make Google prefer HTTP very strongly, and says HSTS cannot override that.
What to do
- Review the affected HTTPS roots and their recorded redirect steps to find where HTTP was introduced.
- Find the redirect to HTTP in your hosting panel, server configuration or CDN.
- Redirect directly to your preferred HTTPS address.
What we read
The shared host check requests four roots: HTTP and HTTPS, with and without www, from the site's registrable domain. HTTPS requests follow each origin's robots.txt policy; an HTTP root uses the same host's HTTPS policy for /. A walk may reach the four exact roots or HTTPS addresses on the same registrable domain, within ten redirects and the audit's recorded request budgets.
This rule reads the two HTTPS roots. An observed redirect to HTTP is reported even when a later step returns to HTTPS or fails. All affected roots form one site finding. Without a downgrade, an unjudged HTTPS root leaves the result unverified; a recorded certificate failure belongs to the certificate check.
Example & evidence
Illustrative example — one site, not a live audit.
The site is https://bakery.example/. We request https://www.bakery.example/:
GET https://www.bakery.example/
HTTP/1.1 301 Moved Permanently
Location: http://bakery.example/
GET http://bakery.example/
HTTP/1.1 301 Moved Permanently
Location: https://bakery.example/
GET https://bakery.example/
HTTP/1.1 200 OKThe chain ends on https://, but its first step points to http://, so the site is reported with https://www.bakery.example/ as the affected address.
A possible correction:
GET https://www.bakery.example/
HTTP/1.1 301 Moved Permanently
Location: https://bakery.example/Confirm & check again
Check for yourself: run curl -IL https://www.bakery.example/ with your own address, with and without www, and check that no Location line starts with http://.
Check again: Full audit — run an audit that sufficiently rechecks the same site. The HTTPS roots must no longer pass through HTTP, with at least one usable 200 response and no unresolved HTTPS root. Missing responses, robots denial or a handshake without a certificate verdict leave the fix unconfirmed. A page limit alone does not decide whether these roots were sufficiently rechecked.
Limits & sources
Only these root addresses and their permitted redirect walks are checked. For a site at shop.bakery.example, the matrix uses bakery.example and www.bakery.example. A foreign domain or HTTP address outside the four exact roots is refused, though a recorded Location may still prove a downgrade. If initial HTTPS robots access fails, the audit stops before these probes and creates no finding from this check.
Confidence: High because each redirect step and the address it points to are read directly.
Sources
- Google, How to specify a canonical URL with rel="canonical" and other methods — lists an HTTPS page that redirects to or through an HTTP page as a conflicting signal, and says HTTPS-to-HTTP redirects make Google prefer HTTP very strongly. Checked 25 September 2026.
Editorial review: 3 November 2026