HTTPS Is Not Enough: HSTS, Certificate Transparency and HTTP/3

A padlock in the address bar gets mistaken for complete security more often than it should. HTTPS encrypts a connection once it is established - it does not stop an attacker from redirecting a visitor to an unencrypted version of the same site in that very first moment, before the redirect even has a chance to fire. Set up HTTPS and stop there, and you have solved half the problem.

Why HTTPS alone is not enough

The attack a plain HTTPS certificate does not protect against is SSL stripping: an attacker on the same network - an open Wi-Fi network, for instance - intercepts the very first connection attempt before a redirect to https:// takes effect, and quietly keeps the visitor on an unencrypted connection. To the visitor, the site looks normal; in reality, all traffic is flowing through the attacker in plain text. A certificate and a redirect do not solve this, because both only kick in after the first connection has already been made unencrypted.

What HSTS technically does

HTTP Strict Transport Security (HSTS) closes exactly that gap by telling the browser to only ever contact a domain over HTTPS for a set period - no first unencrypted attempt at all. The signal arrives as an HTTP header from the site itself:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

max-age sets, in seconds, how long the browser remembers this rule, includeSubDomains extends it to every subdomain, and preload is the application for the preload list described below. One thing worth understanding: this header only takes effect after the browser has visited a site over HTTPS at least once - on the very first contact with a brand-new domain, it does not help on its own yet.

Preload: the step that is practically irreversible

The preload list closes exactly that first-visit gap. Instead of waiting for that first visit, the domain is already hardcoded into the browsers themselves - Chrome, Firefox, Safari and Edge all ship this list with every new release. A visitor hitting a listed domain for the very first time gets redirected to HTTPS before the first request even goes out, because the browser already knows, without ever having asked the website.

That same hardcoding is exactly what makes inclusion practically irreversible. The list is maintained through hstspreload.org, but removing a domain does not mean the change takes effect immediately: it first has to be removed from the source list, and the removal only reaches users once they install the next browser release that ships it - across all four browser vendors, with no way for the website itself to influence when that happens. Preload a domain and later need to run a subdomain without HTTPS, and that decision sits there unresolved for months, not minutes. Preload belongs on a domain only once HTTPS runs reliably and permanently across the entire domain, subdomains included - not as a default checkbox at initial setup.

Certificate Transparency: the public log of your certificates

Certificate Transparency (CT) is a public, tamper-evident log of every certificate issued. Every certificate authority reports a newly issued certificate into this log, and modern browsers only accept a certificate once it is verifiably recorded there. The practical benefit: if a certificate is issued for your domain anywhere without your knowledge, it shows up in that same public log. Tools like crt.sh let you search the logs for your own domain directly. With modern certificate authorities such as Let's Encrypt, CT logging happens automatically with every issuance, with nothing manual required - checking the logs for your own domain regularly is still worthwhile, since the logging itself does not verify that a certificate was legitimately requested.

HTTP/3: faster without TCP overhead

HTTP/3 runs on QUIC instead of classic TCP for transport. The most practically relevant difference shows up with packet loss: under TCP, a single lost packet blocks every packet behind it on the same connection until it is retransmitted. QUIC transmits independent streams separately, so a lost packet only delays the affected stream instead of the whole connection. QUIC also reconnects faster when a device switches networks - from Wi-Fi to mobile data, for example. On a stable fibre connection that difference barely registers; on a phone on a mobile network with fluctuating signal, it does. Modern CDN and edge providers typically enable HTTP/3 automatically today; classic shared hosting often does not.

Concrete steps for the next 90 days

• Days 1-30: set the HSTS header without preload and confirm HTTPS runs reliably across every subdomain
• Days 31-60: check Certificate Transparency logs for your domain via crt.sh, confirm HTTP/3 availability with your hosting or CDN provider
• Days 61-90: only after every subdomain has run stably, add the preload directive and submit to hstspreload.org

Conclusion

Of the steps in this article, three are harmless if you reverse them later: HSTS without preload, monitoring Certificate Transparency, enabling HTTP/3. One is not. The preload list takes a domain in weeks and releases it only months later - so submit it once every single subdomain really is permanently reachable over HTTPS, including the one nobody is thinking about right now. How a solid technical foundation affects loading speed is covered in our article on Core Web Vitals 2026. What role crawler control plays for the visibility built on top of that foundation is covered in our article on robots.txt and AI crawlers. What a technical SEO audit including an HTTPS review costs is covered in our article on SEO costs. For a no-obligation review of your current HTTPS configuration, feel free to get in touch.