HSTS Monitor
HSTS preloading bakes "always use HTTPS" into the browser itself — a domain on the preload list can never be visited over plain HTTP from a modern browser, even on the very first request. This check queries the official preload status API to see whether your domain is on the list and what state it's in.
What we check
A request to hstspreload.org/api/v2/status?domain=<your-domain>, the official status endpoint maintained by the Chromium team. The response identifies the domain's preload state and, when applicable, the parent domain it inherits preloading from.
Why it matters
Sending a regular HSTS header protects users who have visited the site at least once over HTTPS, but the very first visit is still vulnerable to a downgrade attack. Preloading closes that gap by shipping the policy with the browser.
This monitor is most relevant for domains where HSTS preloading is part of the security model. If you've never intended to preload, removing the monitor is reasonable — the warning isn't free if it doesn't apply.
Status outcomes
The domain is on the preload list — either directly or via a preloaded parent domain.
The domain is queued for addition to or removal from the list (pending or pending-removal). The state will resolve on its own once Chromium ships an update.
The domain is not on the list (unknown), was rejected during submission (rejected), or has been removed (removed).
How to fix
To submit a domain for preloading: serve a valid certificate, redirect all HTTP to HTTPS, and serve an HSTS header of the form Strict-Transport-Security: max-age=63072000; includeSubDomains; preload on the apex. Then submit at hstspreload.org.
Be aware that preloading is effectively permanent — removal takes months and your subdomains lose the option to ever be reached over HTTP. It's not a decision to make casually.