Website not served over HTTPS

No certificate at all: `https://` fails to connect. Rare in 2026, and unambiguous.

Both protocols answer, no redirect. `http://` returns 200 with the same content. This is the common case, and the one that looks fine in a browser because everyone types the domain and gets whichever the browser prefers.

HTTPS with an incomplete redirect: the apex redirects but `www` does not, or the home page redirects but deep paths do not. Partial configurations are the norm after a migration.

Anything sent over HTTP — a login, a contact form, a session cookie — is readable by any intermediary. On shared or public networks that is not theoretical.

Browsers show a not-secure indicator on HTTP pages, and mark forms on them explicitly.

Secure-context features are unavailable: service workers, geolocation, camera and microphone access, and much of the modern platform.

Google has stated HTTPS is a lightweight ranking signal. It is the smallest of the reasons on this list.

`curl -I http://example.com` — a correct configuration answers 301 with a `Location` starting `https://`. A 200 means the insecure version is live.

Test all four variants: `http://example.com`, `http://www.example.com`, `https://example.com`, `https://www.example.com`. They should converge on one address in at most one hop.

Test a deep path, not just the home page. Redirect rules that only cover `/` are common.

Check the certificate covers the hostnames you actually serve, including `www` if you use it.

Obtain and install a certificate covering every hostname you serve. Let's Encrypt issues them free and automates renewal.

Redirect all HTTP to the HTTPS equivalent with 301, preserving the path — `http://example.com/a/b` must reach `https://example.com/a/b`, not the home page.

Fix mixed content, or the HTTPS pages will load broken. This is usually the largest part of the work on an older site.

Add `Strict-Transport-Security` once HTTPS is verified working. It instructs browsers to use HTTPS without asking. Start with a short `max-age`, because the header is hard to undo — browsers honour it for its full duration.

Update internal links, canonical tags and the sitemap to HTTPS so nothing relies on the redirect.

`transport.https` reports whether the site serves HTTPS and whether the certificate is valid for the hostname. `transport.http_redirect` reports whether the plain-HTTP version redirects, which is the question the first one does not answer.

`transport.hsts` and `transport.hsts_directives` report the Strict-Transport-Security header and its parameters; `transport.certificate_details` and `transport.certificate_coverage` report what the certificate actually covers.

`transport.canonical_host` reports whether the host variants converge, which is where partial configurations show up.

The certificate is rarely the hard part. The problems come from everything that was written down as `http://` while that was correct.

The site loads over HTTPS with pieces missing. Scripts and stylesheets referenced over HTTP are blocked outright, so a page renders unstyled or a feature silently stops. This is the first thing to expect and the largest task on an older site.

Redirect loops between the protocol rule and the host rule. Each is correct alone; together they can bounce a request back and forth until the browser gives up. Test all four host-and-protocol combinations, not the one you configured.

A load balancer terminating TLS and forwarding plain HTTP to the origin. The application sees an insecure request, decides to redirect it to HTTPS, and the loop is complete. The fix is reading the forwarded-protocol header rather than the connection.

Cookies without the `Secure` attribute, which keeps sending them in clear text on any request that still reaches HTTP.

Canonical tags, sitemap entries, `hreflang` and Open Graph URLs still declaring `http://`. These do not break anything visibly and they keep telling search engines that the old protocol is the real one.

Third-party integrations with a hardcoded HTTP callback: payment notifications, webhooks, single sign-on returns. These fail after the switch, quietly, and are found by whoever notices the orders stopped.

And in Search Console, the HTTPS site is a separate property. Adding it before the migration means the data is there when it is needed rather than starting from zero afterwards.