HTTP Headers Checker
Response headers, redirect chain and a security-header grade for any URL.
Browsers hide the problems that live in response headers, which is exactly where this looks. Give us a URL and we follow the whole redirect chain hop by hop, read the final response, and grade its security headers A+ to F with the one-line fix for each one that's missing. It catches what you can't see in a tab: a lazy three-hop redirect bleeding link equity, an HTML page shipping uncompressed because gzip was never turned on, a missing HSTS that leaves the first visit open to an SSL-stripping downgrade. We run the same checks a security auditor or an SEO would, instantly and from outside your network, so you see what crawlers and visitors actually get.
Queries run through the PacketNebula lookup service. We log nothing.
The lookup service is not reachable.
In local preproduction, start it with npm run api then . The rest of the site works without it.
Self-test passed: grading logic verified against reference header sets on load.
Reading the grade like an auditor
The grade weighs the final response's defensive headers toward the ones that block real attacks. An A means returning visitors are pinned to HTTPS, a content security policy exists, browsers will not sniff content types, and nobody can iframe the page into a clickjacking overlay. An F usually means the site serves none of them, which stays astonishingly common: these are response headers, set once in your nginx, Apache, CDN or framework config, and they cost nothing at runtime. Each row gives the one-line fix, and OWASP's secure headers project is the reference if you want the long version.
The redirect chain is an SEO finding, not trivia
Type the bare http domain on purpose, the way an old backlink or a typed address arrives, and count the hops. One redirect to the canonical HTTPS URL is ideal, two is tolerable, three or more costs a round trip each on the first visit and burns crawl budget on a large site. We show the status code and latency of every hop, so the chat with whoever owns the load balancer starts from numbers instead of vibes.
Headers worth deleting
The audit also flags information leaks. A Server header announcing
Apache/2.4.29 (Ubuntu) hands an attacker the exact CVE list to
open, and X-Powered-By does the same for your stack. Neither does anything
for a legitimate client. While you are in there, check that your error pages
get the same headers as the homepage, because security headers love to exist
only on the happy path.
Frequently asked questions
Which security headers actually matter?
Four do most of the work: Strict-Transport-Security forces HTTPS on returning visitors, Content-Security-Policy contains XSS damage, X-Content-Type-Options stops MIME sniffing, and frame-ancestors (or the older X-Frame-Options) blocks clickjacking. Referrer-Policy and Permissions-Policy are easy extra points. The rest is situational.
Do security headers affect SEO?
Not as a direct ranking factor, but indirectly yes: HSTS plus a clean single-hop redirect to HTTPS preserves crawl budget and link equity, while a three-hop chain dilutes both. Chrome also flags insecure experiences, and visitors bouncing off warnings is a signal you do not want.
Why does my redirect chain have several hops?
Usually rules piling up: http to https, then non-www to www, then a trailing-slash rewrite, each its own redirect. Every hop adds a round trip and leaks a little link equity. The fix is collapsing them into one rule that jumps straight to the canonical URL, and we show you exactly how many hops you pay today.
Why does it refuse to check my intranet URL?
By design. We fetch the URL from a small service, and a service that fetches arbitrary URLs has to refuse private address space (10.x, 192.168.x, 127.x and friends), or it becomes a proxy into internal networks, an attack class called SSRF. Check internal sites with curl -I from inside.