HTTPS and TLS 7 min read Updated August 2026

HTTPS, TLS, and certificates: secure every public entry point

HTTPS protects the connection between a visitor and the site. The report checks more than the padlock: it validates the requested hostname, the certificate dates, the negotiated TLS connection, insecure subresources, and whether HTTP entry points converge safely on HTTPS.

At a glance

A valid certificate is only one part of secure delivery

A reliable setup combines a trusted certificate for every public hostname, modern TLS, a direct permanent HTTP-to-HTTPS redirect, and pages whose scripts, styles, images, forms, and canonical signals also use HTTPS.

  • Cover every hostname that users and crawlers can reach.
  • Renew certificates before expiry and monitor the complete chain.
  • Remove mixed content instead of relying on browser upgrades.
  • Enable HSTS only after HTTPS works across the intended scope.
01

What a successful TLS check proves

During the TLS handshake, the server presents a certificate chain and proves control of the corresponding key. The client checks trust, validity dates, and whether the requested hostname is included in the certificate.

A certificate can be valid for example.com but fail on www.example.com, or work at the origin while an edge node serves an expired chain. Test the public hostnames through the same CDN and proxy path used by visitors.

02

Common report findings

  • Hostname mismatch The certificate does not cover the exact requested host. Add the host to the certificate or stop exposing it.
  • Expiry or trust failure Repair automated renewal and deploy the full intermediate chain on every endpoint.
  • Mixed content An HTTPS page requests an HTTP resource, weakening security or causing the browser to block it.
  • Insecure form or link User data or navigation can still be sent to HTTP even when the current document is secure.
03

Migrate and harden in the right order

First make every resource and application flow work over HTTPS. Update canonical tags, hreflang, sitemaps, structured data, and internal links, then redirect HTTP directly to the selected HTTPS URL.

After stable deployment, consider Strict-Transport-Security. Its includeSubDomains and preload options have broad consequences, so do not enable them until all covered hosts can remain HTTPS-only.

Action checklist

Validate secure delivery end to end

  1. 01Test the apex, www, and any other public hostname over HTTPS.
  2. 02Confirm hostname coverage, trust chain, and renewal monitoring.
  3. 03Replace HTTP resources, forms, canonical tags, and internal links.
  4. 04Redirect each HTTP URL directly to its equivalent HTTPS URL.
  5. 05Retest from the public edge before enabling HSTS broadly.

Official references

The technical recommendations in this guide are aligned with these primary sources.