If you have set up HSTS on your WordPress site, you may have come across a recommendation to also submit your site to the HSTS Preload list. It sounds like a simple next step, but it is one of those decisions that is very easy to make and very difficult to undo. This guide covers what the preload list actually does, the real benefits, the real risks, and what you need to know before submitting.
What Is HSTS?
HSTS (HTTP Strict Transport Security) is a security header that tells the browser: “This site only works over HTTPS. Remember that and never try HTTP again.” Once a browser receives this header, it will automatically upgrade all future requests to HTTPS for the duration of the max-age you set, even if the user types http:// manually.
A typical HSTS header looks like this:
Strict-Transport-Security: max-age=31536000; includeSubDomainsThis tells the browser to enforce HTTPS for one year, across all subdomains.
What Is the HSTS Preload List?
The HSTS Preload list takes this one step further. It is a list of domains that is maintained by Google and hardcoded directly into all major browsers, including Chrome, Firefox, Safari, and Edge. Sites on this list are never contacted over HTTP under any circumstances, even on the very first visit, before the browser has ever received an HSTS header from the site.
You can view and submit to the list at hstspreload.org.
The Problem Preloading Solves
Regular HSTS has one weakness: the first visit. When a user visits your site for the very first time, the browser has no way of knowing it should use HTTPS. It sends the first request over HTTP, your server responds with the HSTS header, and from that point on the browser enforces HTTPS.
That first HTTP request is vulnerable. If an attacker is positioned between the user and your server (a coffee shop network, a compromised router, a malicious ISP), they can intercept that first request and perform an SSL stripping attack, serving the user an HTTP version of your site indefinitely while quietly communicating with your server over HTTPS.
Preloading eliminates this window entirely. The browser never sends an HTTP request to your domain, not even the first one.
The Benefits
No first-visit vulnerability. Every single visit, from every user, on every network, goes directly to HTTPS from the first byte. There is no window for SSL stripping attacks.
Protection even without a valid HSTS header. If your server is temporarily misconfigured and fails to send the HSTS header, preloaded browsers still enforce HTTPS. The protection is in the browser itself, not dependent on your server responding correctly.
Covers all subdomains unconditionally. Any subdomain of a preloaded domain automatically gets HTTPS enforcement, even subdomains that do not yet exist.
Recognized by security scanners and auditors. Being on the preload list is a positive signal in security assessments and compliance reviews.
The Risks and Downsides
This is the part that most articles gloss over, and it is the part that matters most before you submit.
It is extremely difficult to undo. Once your domain is on the preload list, removing it is a long process. You submit a removal request at hstspreload.org, but the actual removal from browsers takes 6 to 12 months or more, depending on browser release cycles. During that entire period, your domain is still preloaded in browsers that have not updated yet, which is the majority of users at any given time.
A certificate failure makes your site completely inaccessible. With regular HSTS, if your SSL certificate expires or fails, new visitors and users who have cleared their browser data can still reach your site over HTTP while you fix the issue. With preloading, there is no fallback. Every user with a modern browser gets a hard block, not a warning they can click through. If Let’s Encrypt auto-renewal fails at 3 AM, your site goes down for everyone until you fix the certificate.
Every subdomain must have valid HTTPS, always. The preload list requires includeSubDomains. This means every subdomain, including ones you add in the future, must have a valid SSL certificate at all times. A development subdomain, a staging environment, an internal tool — if it does not have HTTPS, it becomes unreachable for anyone on a preloaded browser.
Third parties hosting on your subdomains lose flexibility. If you ever point a subdomain to a third-party service (a landing page builder, a client portal, a newsletter tool), that service must support HTTPS on your custom domain. Not all do.
Who Should Submit to the Preload List?
Preloading makes sense when all of the following are true:
- Your site and all its subdomains are fully committed to HTTPS, permanently
- You have reliable certificate auto-renewal in place and monitor it
- You understand and accept that you cannot quickly undo the decision
- You handle sensitive data (user accounts, payments, personal information) where eliminating even the first-visit risk is worth the trade-off
- Your hosting infrastructure is stable enough that a certificate failure is genuinely unlikely
Preloading is probably not worth it if:
- You are running a simple blog or informational site where the first-visit risk is theoretical rather than practical
- You frequently add or remove subdomains
- You are on shared hosting with limited control over certificate management
- You are not confident in your ability to respond to a certificate failure quickly
Requirements for Submission
Before you can submit to the preload list, your site must meet all of these requirements:
- Serve a valid HTTPS response on the root domain
- Redirect all HTTP traffic to HTTPS
- Serve the HSTS header on the HTTPS response of the root domain
- The HSTS header must have a max-age of at least 31536000 (one year)
- The HSTS header must include the
includeSubDomainsdirective - The HSTS header must include the
preloaddirective
Your HSTS header must look like this before submitting:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preloadHow to Submit
- Make sure your HSTS header includes
preloadandincludeSubDomainswithmax-age=31536000or higher - Go to hstspreload.org
- Enter your domain in the submission field
- The tool will automatically check whether your site meets all requirements and show any issues
- If all checks pass, click Submit
- You will receive a confirmation and your domain will enter a queue for inclusion in the next browser update
After submission, it typically takes a few weeks to appear in Chrome’s development builds and a few months to reach stable browser releases used by most visitors.
How to Check Your Current Status
You can check whether your domain is currently on the preload list, pending, or not submitted at any time by visiting hstspreload.org and entering your domain. The status will be one of: not preloaded, pending, or preloaded.
The Verdict
HSTS preloading is a meaningful security improvement for sites that handle sensitive data and have the infrastructure to support it. The protection it provides against first-visit SSL stripping is real. But the commitment is also real, and it is permanent in practice.
For most WordPress sites, a well-configured HSTS header with a one-year max-age gives you the vast majority of the protection with none of the risk of being locked into the preload list. If you decide to go further and preload, do it with a clear understanding of what you are committing to, and make sure your certificate auto-renewal is solid before you click Submit.
Need Help?
If you are not sure whether preloading is right for your site, or you need help configuring HSTS correctly before submitting, our team can review your setup and walk you through the decision.