Security Headers SEO Validator & Public Site Hardening Checker

How to use this validator

1. Capture headers from the exact URL you plan to launch or merge, including the final redirected HTTPS URL.
2. Paste the response headers into the validator and run the check.
3. Fix missing or weak HSTS, nosniff, frame protection, referrer policy, permissions policy, and CSP/header pairing issues in your app, CDN, or reverse proxy.
4. Re-test homepage, high-traffic SEO pages, app shell routes, API responses, and preview URLs because edge rules often differ by path.
5. Pair this with CSP, CORS, compression, performance budget, manifest, favicon, Open Graph, JSON-LD, canonical, sitemap, and robots validation before launch.

When to use it

• Run a public-site launch checklist for marketing pages, validator pages, app shells, docs, pricing, checkout, and login routes.
• Compare Vercel preview and production headers before merging framework, middleware, CDN, or reverse-proxy changes.
• Check trust/security posture after adding analytics, embeds, iframes, third-party scripts, auth, payments, or file downloads.
• Turn `curl -I` output into a client-readable hardening review without uploading response headers to another service.
• Pair security header QA with CSP, CORS, compression, performance budget, manifest, favicon, Open Graph, JSON-LD, canonical, sitemap, and robots validation.

Common errors

• Forgetting HSTS on the final HTTPS host after a www/apex redirect or CDN migration.
• Setting HSTS preload before subdomains, staging hosts, or legacy services are ready for forced HTTPS.
• Missing nosniff, which can create MIME-type risk for scripts, styles, downloads, and uploaded assets.
• Using ALLOWALL or omitting frame protections on checkout, login, admin, validator, or lead-capture pages.
• Leaking full URLs with an overly permissive Referrer-Policy when pages contain campaign, lead, account, or private query parameters.
• Assuming security headers are global when CDN rules, middleware, route handlers, static assets, and API responses may differ.

Limitations

• Header syntax and presence checks only; this does not fetch a URL, verify TLS certificates, scan redirects, or prove real browser enforcement.
• Does not replace CSP audits, dependency security reviews, penetration testing, cookie flag checks, auth review, or vulnerability scanning.
• Permissions-Policy is checked structurally, not semantically; confirm the exact directives against current browser support.
• HSTS preload has operational risk. Verify all subdomains and long-term HTTPS readiness before submitting a domain to preload lists.

Tips

• Capture the final redirected HTTPS URL, not just the first URL you typed; redirects often have different headers than destination pages.
• Add HSTS carefully: start with an appropriate max-age, confirm every subdomain supports HTTPS, then consider includeSubDomains and preload.
• Use X-Frame-Options for legacy coverage and CSP frame-ancestors when you need modern, granular embedding control.
• Keep Referrer-Policy conservative for public SEO pages with query parameters; strict-origin-when-cross-origin is a practical default.
• Test through the CDN/edge layer because framework headers can be overwritten or omitted by static hosting, redirects, image routes, and API routes.

Examples

Deep dive

FAQs

Does this fetch my URL or test TLS?

No. It validates pasted response headers in your browser. Use curl, DevTools, security scanners, and TLS tools to collect evidence first.

Should I always enable HSTS preload?

No. Preload is powerful but risky if any subdomain cannot serve HTTPS. Confirm the whole domain is ready before adding preload or submitting to preload lists.

Is X-Frame-Options enough?

It is useful legacy coverage, but CSP frame-ancestors is more flexible and should be reviewed for modern clickjacking protection.

Can I paste Vercel or Cloudflare headers?

Yes. Paste final response headers from previews, production, CDN logs, or curl output to compare edge behavior before and after deploys.

Related validators