Serving your site over HTTPS
HTTPS is HTTP sent over an encrypted TLS connection. It is what puts https:// in the address bar
and stops browsers from labelling your site “Not secure”. Today it is the baseline for every
website, not only for shops and login pages.
Why it matters
Over plain HTTP, everything between the visitor and your server travels as readable text. Anyone on the path, such as a public Wi-Fi operator, a compromised router or an ISP, can read it and change it. That includes passwords and form data, but also the page itself: attackers can inject ads, malware or fake login forms into an HTTP page in transit.
HTTPS gives you three things:
- Confidentiality: others on the network cannot read the traffic.
- Integrity: content cannot be modified in transit without the browser noticing.
- Authentication: the certificate proves the visitor is talking to your domain.
There are practical reasons too. Browsers mark HTTP pages as not secure, many modern browser features (geolocation, service workers, HTTP/2 and HTTP/3 in practice) work only over HTTPS, and Google uses HTTPS as a ranking signal.
What we check
| Result | When |
|---|---|
| Pass | the scanned page ends up on an https:// URL |
| Pass | the page was served over HTTP, but the host accepts TLS connections on port 443 |
| Fail | the page is served over HTTP and no TLS connection to the host succeeds |
The second case means HTTPS is set up but visitors are not sent to it. That shows up in the HTTP to HTTPS redirect check. The quality of the certificate (trust, expiry, hostname) and the TLS version are separate checks; see the TLS certificate guide.
How to fix
1. Get a certificate. Certificates are free and renew automatically with most setups:
- Let’s Encrypt with an ACME client such as Certbot, or the ACME support built into Caddy, Traefik and many control panels.
- Your CDN or host. Cloudflare, most managed hosts and platform services issue and renew certificates for you when you add a domain.
Cover every hostname visitors use, usually both example.com and www.example.com.
2. Enable HTTPS on the server. With Certbot and Nginx, for example:
sudo certbot --nginx -d example.com -d www.example.com
Certbot edits the server block and sets up renewal. A minimal manual Nginx configuration looks like this:
server {
listen 443 ssl;
listen [::]:443 ssl;
http2 on;
server_name example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}
Use fullchain.pem, not cert.pem: browsers need the intermediate certificates too.
3. Behind a CDN, encrypt both legs. In Cloudflare, an SSL/TLS mode of “Flexible” encrypts only the browser-to-Cloudflare leg and leaves Cloudflare-to-origin traffic on plain HTTP. Install a certificate on the origin and use “Full (strict)” where possible.
Moving an existing site to HTTPS
- Install the certificate and check that every page loads over
https://. - Fix mixed content: images, scripts and styles still loaded over
http://. Search your templates and database for hard-codedhttp://URLs to your own domain. - Update canonical links, sitemaps, internal links and Open Graph URLs to
https://. - Redirect all HTTP traffic to HTTPS with a 301 (see the redirect guide).
- Once everything works, add HSTS so browsers stop trying HTTP at all.
- In Google Search Console, add the
https://version of the site if you use a URL-prefix property.
Search engines treat an HTTP to HTTPS move like a site move, so rankings can fluctuate briefly while the new URLs are recrawled. Consistent redirects and canonicals keep that short.
MDN’s Transport Layer Security overview explains the protocol in more depth.