HSTS (HTTP Strict Transport Security)

HSTS is a security policy declared via the Strict-Transport-Security response header that tells a browser "always use HTTPS for this domain." The browser remembers the policy for the declared max-age and refuses HTTP connections to the domain during that window.

A typical HSTS header:

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

The three directives:

• max-age=31536000 — 1 year. The browser remembers the policy this long.
• includeSubDomains — applies to every subdomain too (api.bcited.ai, etc.).
• preload — opt-in flag for Chrome's hardcoded preload list. With it, Chrome refuses HTTP even on the FIRST visit (before any header is seen).

Without HSTS, every first visit to a domain has a brief HTTP window vulnerable to downgrade attacks. With HSTS preload, that window closes entirely — the browser never even tries HTTP.

Why it matters for AEO

Mostly indirect: HSTS is part of the broader trust signal that contributes to EEAT scoring. Sites that bother to harden their security posture (proper HTTPS, HSTS, CSP) tend to also be the ones producing trustworthy content. Google's quality raters notice; AI engines' source-selection signals notice.

Direct impact: AI engines occasionally crawl HTTP variants of pages and get redirects or warnings. Clean HSTS makes everything resolve consistently over HTTPS.

What b/cited does about it

• Site readiness audit checks the HSTS header and warns if max-age is too short, includeSubDomains is missing, or preload isn't set (when other prerequisites are met)
• Our own setup — bcited.ai ships with max-age=31536000; includeSubDomains; preload and is submitted to Chrome's HSTS preload list

The audit treats HSTS as a small-but-cheap grade lever — one header, no functional cost, modest trust uplift.