Security
HSTS header
HSTS header is one of the public readiness signals included in isitready.dev reports.
What we check
How the scan observes this signal.
The scanner requests the homepage over HTTPS, reads the Strict-Transport-Security header, and validates that the max-age is long enough for preload eligibility (≥31 536 000 seconds / 1 year) and that includeSubDomains + preload directives are present when appropriate.
Why it matters
Why this shows up on the report card.
Strict transport policy prevents insecure downgrade paths after a browser has seen the site.
Sample evidence
What a passing row looks like.
- GET / (HTTPS)
200 OK- Strict-Transport-Security
max-age=31536000; includeSubDomains; preload- HTTP → HTTPS redirect
301 Moved Permanently- Preload eligibility
eligible
How to improve
Steps in the remediation brief.
Serve Strict-Transport-Security on every HTTPS response from the canonical origin.
Set max-age to at least 31536000 (one year) so browsers keep the pin across sessions.
Add includeSubDomains once you are confident every subdomain speaks HTTPS, then preload once the policy is stable.
Redirect any http:// request to https:// with a 301 before the HSTS header ever gets a chance to be missed.
Common questions
Questions people ask about this check.
- What max-age value should HSTS use?
- At least 31 536 000 seconds — one year. Shorter values work for testing but are rejected by the Chromium preload list. If you're still rolling out HTTPS, start with a week and ratchet up as confidence grows.
- When should I add includeSubDomains and preload?
- includeSubDomains only after every subdomain on the apex can speak HTTPS — otherwise subdomain traffic fails. preload only after the policy is stable, since removal from the preload list takes months.
- Does HSTS replace the HTTP → HTTPS redirect?
- No. HSTS only kicks in after a browser has seen the header at least once. The 301 redirect is still what protects first-time visitors, so keep both.