Verify
Deployedcheck actual response headers on the public domainSecurity Headers
Review deployed headers as a release artifact, not just a config file.
The root `_headers` file is only useful when the hosting platform applies it correctly. Use this page to check intent, deployment, and follow-up risk.
Protect
Staticpublic text files, manifest, sitemap, and well-known routes need reviewStage
CSPtest report-only or staging before enforcing new policyRecord
Changeheader changes belong in release notes and QA checksReview Checklist
What to inspect before shipping header changes
Compare file to deployment
Open `_headers`, then inspect response headers on Home, one page under `/pages/`, public text files, sitemap, manifest, and `/.well-known/security.txt`.
Confirm baseline protections
Review expectations for content type, frame embedding, referrer behavior, permissions policy, and whether static assets inherit the right defaults.
Check public indexing files
Confirm `robots.txt`, `sitemap.xml`, `llms.txt`, `humans.txt`, and `site.webmanifest` still load after header or routing changes.
Do CSP separately
Content Security Policy changes should be tested through the CSP staging checklist before enforcement, because module and tool behavior can break quietly.
Keep cache changes intentional
If cache headers change, check generated assets, route data, search index, sitemap, and tool runtime query keys so users are not stuck on stale behavior.
Document the decision
Record what changed, what was verified, and what still needs deployed-domain inspection in release notes or QA notes.
Practical rule: a passing local build does not prove headers are deployed. Always inspect the live response after Cloudflare Pages or the final host publishes the site.