HTTPS has been an explicit Google ranking signal for a long time, but many sites just “install a certificate and call it done,” overlooking details like HSTS, certificate rotation, and mixed content. As a result their security posture isn’t complete and they can’t hold onto the ranking dividend. Certificates and HSTS go together — miss one link and it’s not really full-site encryption.
This article breaks down HTTPS certificate selection and HSTS configuration so you can earn the ranking boost without hitting the “site breaks after configuring” pitfall. For fixes related to mixed content, work through the mixed content fix guide alongside — the two together decide the page’s security score.
First, remember the baseline about HTTPS: it’s a foundational ranking signal, the certificate must be valid, everything must run over https, and no mixed content can be dragging you down. For the certificate, prefer a short-validity scheme that auto-rotates (like a 90-day one) so an expired cert doesn’t suddenly make the whole site untrustworthy. HSTS’s job is to make browsers force https and block downgrade attacks, but before configuring it you must confirm all site resources are already https — otherwise you’ll lock up leftover http pages entirely. Joining the HSTS preload list eliminates the plaintext risk of the very first request, but once you’re on it there’s no easy way back, so think it through before submitting.
Why HTTPS is a ranking baseline
Google has treated HTTPS as a lightweight ranking signal since 2014, and today browsers flag http sites with “Not secure” directly — user trust drops a notch first, and the rising bounce rate comes back around to hurt rankings. So HTTPS stopped being a “bonus” long ago; it’s now a “deduct if you don’t meet it” baseline.
What’s worse is mixed content: the certificate is installed, but the page still embeds http resources, and the browser won’t consider you secure anyway. Certificate and mixed content are two sides of one thing — handling only one side doesn’t help. The technical SEO handbook covers how certificates fit into the overall technical strategy more systematically.
Certificate selection and validity
A DV certificate is enough for personal sites; enterprises can use OV to show entity info in the cert. The key isn’t the type — it’s “don’t expire.” With the old one-year long-validity certificates, forgetting to renew makes the whole site untrustworthy and traffic hits zero overnight.
A steadier approach is a 90-day short-validity certificate with auto-renewal (Let’s Encrypt plus a cron job, or CDN-managed). Short validity shrinks the “forgot to renew” risk window to a minimum, and even if the script occasionally fails there’s time to recover — you don’t wait a full year for one big blow-up.
What HSTS is and how to enable it
HSTS (HTTP Strict Transport Security) is a response header telling the browser “this domain only allows https from now on.” Once enabled, even if a user types http or is tricked into clicking an http link, the browser upgrades it to https locally, blocking man-in-the-middle downgrade attacks.
There’s an iron rule before configuring: you must first confirm all site resources, including subdomains, are https-available — otherwise enabling HSTS will lock up pages still using http so they can’t open. So the standard sequence is: fix mixed content first, run full-site https steadily for a week, then enable HSTS. The order can’t be reversed.
The HSTS preload list
HSTS has a weakness: on a user’s “first” visit, the request still goes out in plaintext, and attackers can strike on that first request. The HSTS preload list (a list baked into browsers) solves this — the browser knows your domain out of the box and forces https even on the first visit.
To get on the preload list you need: full-site https, the root domain with includeSubDomains and preload directives, and a long enough max-age. The cost is that it’s hard to leave — old browsers keep the record. So submit only when the architecture is stable and you’re committed to long-term https; don’t submit a trial-run site.
Figure: HTTPS and HSTS — Core Points (compiled by YunyingGO)
| Setting | Recommended | Note |
|---|---|---|
| Certificate validity | 90 days + auto-renew | Avoid forgetting to renew |
| HSTS max-age | At least 1 year | Enable after full-site https |
| includeSubDomains | On | Force subdomains too |
| preload | Add once stable | Hard to leave |
Common configuration errors
Error one: remembering to renew only when the cert is about to expire, then an outage at midnight. Error two: enabling HSTS before full-site https, locking up leftover http resources. Error three: only enabling HSTS on the main domain and missing subdomains, so users on subdomains still get hit by downgrade attacks.
Error four: treating preload as “the earlier the better,” submitting before the architecture is stable, then later switching back to http and finding old browsers still force https — a large chunk of users can’t open the site. These pitfalls all come down to not thinking through “order and scope”; following “full-site https → then HSTS → finally preload” is the steadiest rhythm.
Migration and verification
When migrating to full-site https, 301 the old http URLs to the corresponding https ones — don’t let users and crawlers hit 404s or mixed-content warnings. Submit the https version’s sitemap in GSC and watch whether the mixed-content entries in the “HTTPS report” clear to zero.
After launch, periodically look back at the certificate validity and whether the HSTS header is still there — better yet, put both into monitoring alerts that remind you automatically before expiry. Security and SEO are bound together; when the certificate item goes wrong, all the content optimization you did gets offset by the drop in trust.
Certificate chains and intermediate certs
A certificate isn’t a single file — it’s a chain: your cert is issued by an intermediate, and the intermediate connects to the root. If you omit the intermediate, some older devices judge the “certificate as untrusted” and the page won’t open — this kind of problem comes and goes and is the hardest to track down.
When deploying on a CDN or server, include the full chain (fullchain), not just your own certificate. Verify by scanning with a tool like SSL Labs to confirm the chain is complete, nothing is expired, and there are no weak cipher suites — blocking this kind of hidden failure before launch.
Recheck mixed content after launch
After enabling HSTS, you must recheck mixed content even more regularly, because with an http resource present, the browser blocks it outright rather than degrading it — harsher than before. Put mixed-content scanning into the monthly routine, combined with certificate and HSTS header checks, forming a three-in-one security config inspection.
If any of these three (certificate, HSTS, mixed content) goes wrong, the content optimization you did gets offset by the trust problem. Instead of rescuing things after a failure, automate the inspection, push alerts to a group, and whoever’s on duty reviews them — only then can the security score hold up long-term.
Keep the order straight when you get to work: first check the whole site’s certificate validity and switch to 90-day auto-renewal — stop relying on remembering dates by hand; fix all mixed content and confirm all site resources are https-available before adding the HSTS header (max-age of one year, with includeSubDomains); once the architecture is stable, consider submitting to the HSTS preload list. Finally, wire certificate expiry and HSTS header status into monitoring with automatic reminders before they expire. Once this set is done, your site is truly “fully encrypted,” and only then does the ranking dividend hold steady.
