Decide whether to add includeSubDomains

Why it matters

Without includeSubDomains, subdomains are not forced onto HTTPS by the main domain's policy. Adding it is a choice because it also locks every subdomain, including old or internal ones, to HTTPS.

Risky change. A wrong setting here can take your site or your mail offline. Follow the stages in order, test each one, and keep a way back.

The fix

1. List every subdomain in use. Check your DNS zone, your certificates (certificate transparency logs show names such as the ones at crt.sh) and your mail, staging, intranet and device names. Every one must work over HTTPS with a valid certificate, or it will become unreachable in browsers.
2. Fix or remove subdomains that only work over plain HTTP before going further.
3. Stage 1, add includeSubDomains while max-age is short (300). Test several subdomains in a browser and watch support requests.
4. Stage 2, raise max-age in stages up to one year (31536000), as in the fix for the missing header.
5. Rollback is only effective for visitors who return and are told max-age=0. Treat this change as hard to undo.
6. Leave it off if you cannot guarantee HTTPS on every present and future subdomain.

Strict-Transport-Security: max-age=300; includeSubDomains

Read the documentation ↗(opens in a new tab)

Related

• Reported by the HSTS check
• Add the Strict-Transport-Security (HSTS) header
• Fix the malformed Strict-Transport-Security header
• Re-enable HSTS (max-age is zero)
• Raise the HSTS max-age
• Meet the HSTS preload requirements or remove preload
• Consider submitting the domain to the HSTS preload list