HTTP Header Checker

Submit a URL into a header checker and the tool sends a GET or HEAD request, then displays the full response headers. You'll see status code (200, 301, 404), Server header, Content-Type, Cache-Control, Set-Cookie, security headers, and anything custom the server adds. For technical SEO audits, this is one of the first things I run on a client site — header issues cause real ranking and indexing problems but they're invisible without inspecting the raw response yourself.

The essentials I check on every audit: Strict-Transport-Security (HSTS) for HTTPS enforcement, Content-Security-Policy (CSP) to limit script sources, X-Content-Type-Options: nosniff to prevent MIME sniffing, X-Frame-Options or frame-ancestors in CSP to block clickjacking, Referrer-Policy to control referrer leakage, and Permissions-Policy to restrict browser features. Modern setups should also include Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy. Removing X-Powered-By and minimizing the Server header reduces fingerprinting. None of these are optional for a serious site in 2026 — securityheaders.com gives a quick grade.

Run a header check and look for "Strict-Transport-Security " in the response. The value should specify max-age (in seconds — 31536000 means one year), includeSubDomains (covers all subdomains), and ideally "preload " if you've submitted to the HSTS preload list. Example: `max-age=63072000; includeSubDomains; preload`. Without HSTS, browsers can be tricked into downgrading to HTTP. Once you set a long max-age and includeSubDomains, you're committing — every subdomain must serve valid HTTPS or it will break.

200 OK is the standard success response — the server processed the request and returned the expected resource. For a webpage, it means the page loaded without errors. But "200 OK " alone doesn't guarantee the content is correct — a soft 404 can return 200 while showing an error page, which is bad for SEO. Always cross-check that the actual response body matches what should be there. For audit work, I look at status code AND content together, never just the status.

Headers like "Server ","X-Powered-By ","Cache-Control ","Expires ","ETag ", and "Last-Modified " all appear in the response when you run a header check."Server " reveals the web software (nginx, Apache, etc.) — best to minimize this for security."Cache-Control " tells browsers and CDNs how long to store the response."ETag " and "Last-Modified " enable conditional requests for efficient caching. Misconfigured caching headers cause stale content or unnecessary bandwidth — both common pain points during audits, especially with WordPress sites behind caching plugins.

A lot more than people think. Status codes (200, 301, 302, 404, 410) directly affect crawling and indexing. X-Robots-Tag in the response can apply noindex without needing a meta tag. Cache-Control affects how often Googlebot revisits. Vary headers can cause duplicate content if misconfigured. HSTS and security headers indirectly help — Google has indicated HTTPS and site quality signals matter. Even Server header verbosity affects security posture, which influences trust. Headers are one of the most under-audited parts of technical SEO.

CSP is a browser-enforced policy that restricts what resources (scripts, styles, images, fonts, frames) a page can load and from where. So a strict CSP might say "scripts only from self and cdn.example.com " — anything else gets blocked. This dramatically reduces XSS attack surface because injected scripts from unknown sources won't execute. CSP is powerful but tricky to deploy — start in report-only mode to find legitimate sources before enforcing. Misconfigured CSP can break analytics, ads, and third-party widgets you didn't realize were loaded.

For redirects, run a header check and look at the status code (301, 302, 307, 308) plus the Location header — that's where the request is being sent. Follow the chain until you reach a 200 response. For canonicals, check both the HTML <link rel="canonical"> tag AND any Link: <url>; rel=canonical header (servers can send canonicals via header too). Make sure both point to the same final URL. Inconsistency between header canonical and HTML canonical confuses Googlebot and dilutes ranking signals.

The CDN sits between users and your origin, so it adds, modifies, and sometimes strips headers. You'll often see "CF-Ray " and "CF-Cache-Status " from Cloudflare,"X-Cache " from CloudFront or Fastly, plus modified Cache-Control or Server entries. Edge nodes in different regions may also serve cached responses with different timestamps. So a header check from India might show different values than one from the US, even for the same URL. Always test both edge and origin separately when troubleshooting — the CDN can mask real origin issues.

Strip or minimize "Server ","X-Powered-By ","X-AspNet-Version ", and similar headers that reveal stack details. In nginx, set `server_tokens off`. In Apache, use `ServerTokens Prod` and `ServerSignature Off`. For PHP, set `expose_php = Off` in php.ini. If you're behind a CDN, you can also override these at the edge — Cloudflare lets you remove headers via Transform Rules. Less information about your stack means less to help attackers fingerprint vulnerabilities. It's a small hardening step that takes 5 minutes and pays off.