HTTP Header Checker — Security Headers, Redirects and Server Response
Inspect every response header a site sends, get a graded security header report, and trace the full redirect chain from first request to final page.
What response headers tell you
Every page a server sends comes with a set of headers the visitor never sees. They control how browsers cache the page, whether it can be embedded in a frame on another site, which scripts are allowed to run, and how cookies behave. They are also the cheapest security improvement available: most take a single line in a config file and cost nothing in performance.
The headers that matter most
- Strict-Transport-Security — forces browsers to use HTTPS on every future visit, closing the window where a first request over plain HTTP can be intercepted.
- Content-Security-Policy — restricts which sources may load scripts, styles and frames. The strongest defence against cross-site scripting, and the one that takes the most care to get right.
- X-Frame-Options — stops your pages being embedded in a frame on someone else's site, which is how clickjacking works.
- X-Content-Type-Options — stops browsers guessing a file's type, which prevents an uploaded image being executed as a script.
- Referrer-Policy — controls how much of your URL is passed to sites your visitors click through to.
- Permissions-Policy — switches off browser features you do not use, such as camera, microphone and geolocation.
Headers that give away too much
Some headers volunteer information that helps nobody but an attacker. A Server header naming an exact version, or an X-Powered-By announcing the PHP release, tells a scanner precisely which exploits to try. Neither is required for anything to work, and removing them is a two-minute change. This tool flags them where it finds them.
Reading the redirect chain
Every redirect between the address typed and the page delivered costs a full round trip, and search engines pass slightly less authority through each hop. A chain like http → https → www → trailing slash is four requests where one would do. The trace below shows each hop with its status code so you can collapse them into a single rule.
Frequently asked questions
What are HTTP security headers?
They are instructions a server sends alongside each page telling the browser how to behave — which sources may load scripts, whether the page can be framed by another site, whether to force HTTPS, and how much referrer information to share. They are set in your web server or application config and take effect immediately.
Which security headers should every site have?
At minimum Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options and Referrer-Policy. These four are safe to add on almost any site and take a single line each. Content-Security-Policy is the most valuable but needs testing, because a strict policy can block legitimate scripts.
Will adding security headers break my site?
The four basic headers are very unlikely to break anything. Content-Security-Policy can, since it blocks any script source you have not listed. Deploy it in report-only mode first, watch the reports for a week, then enforce it once nothing legitimate is being blocked.
Do security headers affect SEO?
Not directly. HTTPS is a ranking signal and HSTS supports it, but headers themselves are not ranked. The indirect effect is real though: a site that gets compromised and serves injected spam loses rankings very quickly, and headers reduce that risk.
Why does my site have several redirects?
Usually because separate rules were added over time — one forcing HTTPS, another adding or removing www, another handling trailing slashes. Each was correct on its own, but they chain. Combining them into one rule that jumps straight to the final URL removes the extra round trips.
Should I hide my server version?
Yes. A Server or X-Powered-By header naming an exact version tells automated scanners which vulnerabilities to try against you. Hiding it is not a security measure on its own, but it removes free reconnaissance and costs nothing.