You've probably noticed the little grey padlock in the address bar and assumed the security topic was settled long ago. Except in 2026, "having HTTPS" and "actually having a secure site" are two very different things in Google's eyes, and even more so in the eyes of AI answer engines deciding whether your page deserves to be cited. Chrome is rolling out "Always Use Secure Connections" as the default setting for all users by the end of 2026: in practice, a site still reachable over plain HTTP will show a security warning before the page even loads.
This guide covers what most general SEO audits skip: HTTPS, obviously, but especially HSTS and security headers (CSP, X-Frame-Options, and friends), and why these technical details, invisible to a regular visitor, increasingly matter in how an AI engine decides which source to cite.
HTTPS: a non-negotiable prerequisite (but not a magic bullet)
Google confirmed HTTPS as a ranking signal back in 2014. Twelve years later, its weight in the algorithm remains deliberately light, but its real impact plays out elsewhere: in visitor trust and bounce rate.
An expired certificate, a mix of HTTP and HTTPS resources on the same page (the infamous mixed content), or a poorly configured HTTPS redirect trigger a browser warning that drives away a meaningful share of visitors before they even read a line of content. Google observes this behavior indirectly through aggregated engagement data, not a direct algorithmic penalty, but a bad-experience signal that eventually translates into weaker rankings.
Three pitfalls show up in nearly every audit:
- Unresolved mixed content. An image, script, or stylesheet still loaded over HTTP on an HTTPS page. The browser blocks or warns, and the display can silently break.
- Chained HTTP → HTTPS redirects. A redirect that goes through www and then an old URL before reaching the final version wastes crawl budget and dilutes the signal being passed.
- Forgotten subdomains. The main domain has a clean HTTPS setup, but a subdomain (blog, shop, customer portal) still has a misconfigured or missing certificate, the same kind of blind spot we cover in our HTTP redirects guide.
HSTS: enforcing HTTPS without a redirect on every visit
HSTS (HTTP Strict Transport Security) is a header your server sends telling the browser: "from now on, never contact me over HTTP again, even if the user types the address without the S." In practice, the browser rewrites the request to HTTPS itself before it's even sent, eliminating the 301 redirect round-trip on every visit and closing a classic attack window (session hijacking on the first unencrypted request).
Three levels exist, from basic to strictest:
- Basic HSTS on the main domain, with a short validity duration at first (a few hours) while you confirm nothing breaks.
- HSTS with includeSubDomains, which extends the rule to every subdomain, essential if your shop or customer portal lives on a separate subdomain.
- HSTS preload, the final step: your domain gets baked directly into a list shipped inside browsers themselves, which then refuse any HTTP connection from the very first visit, without even needing to receive the header once.
The classic mistake: turning on HSTS before confirming that 100% of the site, including every subdomain and third-party resource, works correctly over HTTPS. Once HSTS is active with a long validity period, walking it back is painful, some browsers remember the rule for months.
Beyond HTTPS: the headers Google and AI crawlers check too
HTTPS protects data in transit. Security headers protect what happens once the page has loaded in the browser, and more and more audit tools, including the ones AI engines use to assess source reliability, check for their presence.
| Header | Main role | Impact if missing |
|---|---|---|
| Content-Security-Policy (CSP) | Restricts which scripts and resources are allowed to run on the page | Open door to malicious script injection (XSS) |
| X-Frame-Options | Prevents your site from being displayed inside a foreign iframe | Exposure to clickjacking |
| X-Content-Type-Options | Stops the browser from guessing a file type other than the declared one | Risk of malicious content disguised as a harmless file type executing |
| Referrer-Policy | Controls what data is sent when a visitor clicks through to another site | Leaked internal URLs or sensitive parameters in third-party logs |
| Permissions-Policy | Restricts access to browser features (camera, geolocation, etc.) | Wider attack surface if a third-party resource is compromised |
None of these headers is a documented, direct Google ranking factor. But together they tell the same story: a properly maintained site, where someone took the time to close doors that don't need to stay open. That's exactly the kind of background signal Google associates with trustworthiness (the "T" in E-E-A-T), and AI engines treat it the same way.
The GEO angle: why AI engines check your headers too
This is the part most general security or SEO guides still don't cover. Answer engines like ChatGPT, Perplexity, or Google AI Overviews don't just index a page, they have to choose, among dozens of possible sources, which one to cite in an answer. That selection factors in technical trust signals, not just text quality.
Two concrete mechanisms are at play here:
- Safe Browsing exclusion. A site flagged as dangerous by Google Safe Browsing (malicious content, a compromised certificate, suspicious redirects) simply disappears from the corpora used to train and feed generative engines' answers. That's not a demotion, it's an exclusion.
- Differentiated crawling by AI bots. GPTBot, ClaudeBot, PerplexityBot and similar crawlers theoretically follow the same security standards as Googlebot, but with less tolerance for TLS misconfiguration, a marginal certificate or outdated cipher suite can simply prevent some of these crawlers from fetching your page correctly, well before citation even enters the picture.
In a typical SeAudit audit, it's not unusual for an otherwise well-ranked B2B SaaS site to show two or three critical security headers missing (no HSTS enabled, no CSP defined) and at least one third-party resource still loaded over plain HTTP on a page that presents itself as fully HTTPS, details invisible to the naked eye, but perfectly visible to an automated audit tool or an AI crawler.
How to audit your site's security in 15 minutes
- Check your current headers. An online security header scanner gives you, in seconds, the list of what's present, missing, or misconfigured on your domain.
- Look for mixed content. Open your browser's developer console on your main pages and look for warnings about resources loaded over HTTP.
- Check Search Console's "Security Issues" report. Google alerts you directly if your site has been flagged as compromised or deceptive, a signal you never want to discover last.
- Check every subdomain, not just the main domain: shop, customer portal, separate blog.
- Test your HSTS configuration before turning it on with a long duration, to make sure nothing breaks once the rule is in place.
Common mistakes to avoid
- Turning on HSTS too early, before confirming that 100% of traffic (including subdomains) works over HTTPS without issues.
- Deploying an overly restrictive CSP all at once, blocking legitimate resources (fonts, analytics scripts, third-party widgets) and silently breaking the layout with no visible error for the user.
- Forgetting to re-test after every infrastructure change (new CDN, new email provider, new tracking tool): every added external resource may require a CSP update.
- Confusing a valid SSL certificate with an actually secure site. A green padlock stops neither XSS injection nor clickjacking if the other headers are missing.
FAQ
Is HTTPS really a Google ranking factor?
Yes, but a light one, confirmed by Google since 2014. Its real-world impact today comes mostly through trust and visitor behavior: a browser security warning drives away traffic before anyone even reads the content.
Can HSTS break my site if it's misconfigured?
Yes, if you enable it with a long validity duration before confirming that every subdomain and third-party resource works correctly over HTTPS. Always start with a short duration, verify, then increase it gradually.
Does a small SaaS or e-commerce site need every security header?
At minimum, HSTS and a basic Content-Security-Policy cover most of the risk. X-Frame-Options, X-Content-Type-Options, and Referrer-Policy require little effort to implement for a real defense-in-depth benefit.
Can a security issue really keep me from being cited by an AI engine?
Directly, rarely, except for a Safe Browsing flag, which triggers outright exclusion from the corpora generative engines draw on. Indirectly, a TLS misconfiguration can prevent some AI crawlers from fetching your page correctly in the first place, which amounts to the same result: no citation possible.
Key takeaways
- HTTPS alone isn't enough anymore: Chrome is moving to block unsecured HTTP by default by the end of 2026.
- HSTS eliminates the redirect round-trip and closes a classic attack window, but roll it out gradually, never all at once.
- Security headers (CSP, X-Frame-Options, Referrer-Policy...) aren't documented ranking factors, but they build the same trust signal that Google and AI engines associate with a well-maintained site.
- A Safe Browsing flag simply excludes your site from AI citation corpora, that's the real risk to watch first.
Want to know if your own site has gaps in its security setup, missing HSTS or headers included? Get your free /100 score in a few minutes, or grab the full PDF report for a detailed, prioritized action plan.