Your site loads. From the outside it works. But: do returning visitors re-download everything on every click? Can the connection be downgraded from HTTPS to HTTP on public WiFi? Does your homepage count as one site in Google's eyes, or two?
For most static sites: no, yes, and yes. The web server config is the last layer most setups never touch.
Three security headers, three real attack vectors:
- Strict-Transport-Security (blocks HTTPS-to-HTTP downgrade on public WiFi)
- X-Content-Type-Options nosniff (no MIME-type guessing)
- X-Frame-Options DENY (no iframe embedding, no clickjacking)
No others. Static site, no auth, no forms.
Four headers evaluated and skipped:
- Referrer-Policy (already the major browser default)
- Permissions-Policy (blocks browser APIs the site doesn't use)
- Cross-Origin-Opener-Policy (no auth, no tokens, no popups)
- CSP (deferred until the audit fits the schedule)
Adding them would have scored higher on scanners. None would have made the site safer.
Cache strategy follows the build output:
- _astro/* (hashed filenames): immutable, 1 year
- HTML (stable URLs): no-cache, revalidate every visit
- Favicons: 1 hour, must-revalidate
Hashed names mean the URL changes whenever the content changes. So the browser can cache hashed assets forever, safely.
Three small things that quietly matter:
- www to apex 301 (Google sees one domain, not two)
- encode zstd gzip (safety net for files that slip past CI compression)
- ACME email (silent TLS-renewal failure becomes a warning before customers notice)
Generic defaults cover the hard parts. The parts only you can configure (caching, headers, redirects) are the parts that signal intentionality, because only you know what your framework outputs and what your site actually needs.
Full write-up, including each rejected header and why:
https://javedab.com/en/pub/coding/web/astro-caddy-config/
Javed A. Butt