Page served over HTTP, not HTTPS
What it is
The page is served from an http:// address and does not redirect to https://, so the connection between the visitor and your site is not encrypted. Anyone on the network path, on public Wi-Fi for example, can read what the page sends and receives, or inject their own content into it.
Why it matters
Browsers label HTTP pages “Not secure” in the address bar, which puts visitors off, most of all on pages with forms. Google lists serving pages over HTTPS as part of page experience. When an HTTPS version exists but is not enforced, the same content lives at two addresses, and links can be split between them. For visitors, the cost is the risk to anything they type into the page.
How Asky checks it
Asky judges the page’s final URL, after following redirects, and reports the page when that URL starts with http://. An http:// URL that redirects to its https:// version is not reported, and neither is that redirect. Only the page’s own address is judged: links from an HTTPS page to http:// pages are reported as HTTP links on an HTTPS page, and http:// files loaded by an HTTPS page as mixed content. Mixed content is not checked on a page that is itself served over HTTP.
Reported as an error with high severity.
How to fix it
- Make sure the site has a valid TLS certificate for this host. Most hosts and CDNs issue one for free, and Webflow and most managed WordPress hosts set it up for you.
- Redirect every
http://URL to itshttps://twin with a 301, at the server or CDN, or with your platform’s force-HTTPS setting. - Use the
https://URLs in your sitemap and canonical tags, and update internal links to them. - Change any
http://images, scripts or stylesheets on the page tohttps://, so the secure page does not raise mixed content.
Example
http://example.com/contact answers directly instead of sending visitors to HTTPS:
curl -sI http://example.com/contact | grep -i -E "^(HTTP|location)"
# Before: HTTP/1.1 200 OK
# After: HTTP/1.1 301 Moved Permanently (to https://example.com/contact)