Free Security Headers Checker
Enter an address and see which HTTP security headers the server returns, which are missing, and the exact line to add for each one. The check also opens a TLS connection to read the certificate, because a header telling browsers to insist on HTTPS is no use if the certificate behind it is about to expire.
What this checks
HTTP to HTTPS: whether the plain HTTP address redirects to the secure one, or quietly serves the site over an unencrypted connection.
Strict-Transport-Security: HSTS is set, so browsers refuse plain HTTP for this domain without being asked twice.
Content-Security-Policy: whether a CSP is present to restrict where scripts, styles and frames may be loaded from.
Clickjacking protection X-Frame-Options, or a frame-ancestors directive inside the CSP — either one satisfies the check.
X-Content-Type-Options: nosniff is set, so a browser cannot guess a file type and run an uploaded image as a script.
TLS availability a direct connection to port 443, so a certificate that fails to serve at all is reported rather than assumed.
Certificate expiry: the exact number of days left on the certificate, with a warning inside the last fortnight.
Firewall or CDN whether the response fingerprints as Cloudflare, Sucuri, Wordfence, Imperva, or AWS sitting in front of the origin.
What a security header actually is
Every page your server sends comes with a set of headers the visitor never sees — short instructions attached to the response, read by the browser before it renders a thing. Most of them are housekeeping: content type, length, caching. A handful are security instructions, and they all take the same form: your server tells the browser to be stricter than it would be by default.
That is why they are cheap. You are not installing software or changing your site. You are adding a few lines to a server configuration file, and from the next request onwards every browser on earth enforces them for you. It is one of the few security improvements that costs nothing and applies to every page at once.
It is also why they are not a complete defence. A header cannot patch a vulnerable plugin or stop somebody guessing a weak password. What it does is make a whole class of attacks — clickjacking, protocol downgrade, injected scripts, content-type confusion — much harder to land on a site that is otherwise sound.
How to actually add these on WordPress
There are three places to set headers, and the right one depends on what you control. Setting them at the server is best, because they apply to every response including images, PDFs and files PHP never touches. On Apache, add them to .htaccess above the WordPress block, using Header always set — for example: Header always set X-Content-Type-Options "nosniff". On nginx, they go in the server block as add_header directives, and you need the always parameter if you want them on error responses too. Reload the configuration, then run this check again.
If the site is behind Cloudflare, Transform Rules under Rules → Transform Rules → Modify Response Header will set them at the edge without touching the server at all. That is often the fastest route on managed hosting where you cannot edit the server configuration, and it is easy to roll back — you delete the rule. The catch is that the header exists only while traffic goes through Cloudflare, so if you ever move the DNS back to the origin, the headers go with it.
A plugin is the last resort and a perfectly reasonable one. Really Simple Security and Redirection both write headers, and a few lines hooked to send_headers in a small site-specific plugin will do it too. The downside is that PHP has to run for the header to be sent, so a cached page served straight from disk or from a CDN may not carry it. Check the result rather than trusting the setting.
Do not enforce a CSP on day one
This is the one that breaks sites, and it breaks them silently. A Content-Security-Policy tells the browser which sources are allowed. Anything you forgot to list is blocked — and on a typical WordPress site that means your page builder's inline styles, your booking widget, your chat bubble, your Google fonts, your Tag Manager container and the inline script your theme uses to open the mobile menu. The page still loads. It just stops working, usually in a way nobody notices until a week of enquiries has gone missing.
So roll it out in report-only mode first. Send Content-Security-Policy-Report-Only with exactly the policy you intend to enforce. The browser will not block anything; it will simply log every violation to the console, and to a reporting endpoint if you set one. Leave it for a week or two, covering a full cycle of your site — someone completing checkout, someone submitting the contact form, an editor working in the builder — and collect what it would have broken.
Then widen the policy until the report is empty, and only then rename the header to Content-Security-Policy. Expect the first draft to need 'unsafe-inline' for styles on a builder-heavy site; that is a weaker policy than the textbook version and it is still far better than none. Tighten it later if the site ever moves to a stack that allows it.
What this checker does not tell you
It reads the headers on one response — the homepage — and reports what is there. It does not grade the contents of your Content-Security-Policy, because a policy that is right for one site is useless on another, and a scanner that scored policies would mostly be scoring your stack. A CSP full of wildcards will pass this check while doing very little; that is a judgement for a person, not a header test.
It also cannot see whether your headers survive the whole site. Caching layers, CDNs, plugins that take over certain routes and separate configurations for subdomains all mean the homepage is not always representative. If the headers matter to you, check a cached page, an admin-ajax response and a static file as well as the homepage.
And headers are the outermost layer, not the whole of your security. A site with a perfect header set and an unpatched plugin is an unpatched site. The certificate check here reports validity and days remaining, not the strength of the cipher suite or the completeness of the chain — the domain health check covers those, and Qualys SSL Labs remains the deepest free test of a TLS configuration if you need it.
The headers, one at a time
Below is what each one does in plain English. The checker reports on the first four plus the certificate; the last three are explained because you will meet them in every article on this subject and because they are worth adding, even though they are not scored here.
They are not equally urgent. If you only have ten minutes, set nosniff, set clickjacking protection and make sure plain HTTP redirects to HTTPS — those three are safe on essentially any site and take one line each. HSTS is next, once you have confirmed your subdomains. A Content-Security-Policy is the one that repays real effort and the one that punishes carelessness, so give it its own afternoon rather than tacking it on to the end of a deployment.
- Strict-Transport-Security (HSTS) tells the browser never to talk to this domain over plain HTTP again, for the duration you set. Without it, the very first request a visitor makes — typing your domain without https:// — still goes out unencrypted, and that first request is where session hijacking on public wifi begins. Use max-age=31536000; includeSubDomains, and only after you are certain every subdomain works over HTTPS, because it is hard to undo.
- Content-Security-Policy (CSP) a list of the places the browser is allowed to load scripts, styles, images and frames from. If a compromised plugin injects a script pointing at somebody else's server, a CSP stops it from running. It is the strongest control on this list and the only one that takes real work, because you have to know every legitimate source your own site uses.
- X-Frame-Options and frame-ancestors stop another site from loading yours inside an invisible frame and tricking your visitors into clicking things they cannot see — usually a button in your admin area. X-Frame-Options: SAMEORIGIN is the old way; a frame-ancestors directive in your CSP is the modern one, and either satisfies this check.
- X-Content-Type-Options: nosniff stops the browser from second-guessing what a file is. Without it, a file uploaded as an image but containing script can end up being executed as script. One line, no side effects, no reason not to.
- Referrer-Policy controls how much of your URL is handed to the next site when a visitor clicks away. It matters on any page with an identifier in the address — an order confirmation, a reset link, a private preview. strict-origin-when-cross-origin is the sensible default and does not affect your analytics.
- Permissions-Policy switches off browser features your site does not use — camera, microphone, geolocation, payment — so an injected or embedded script cannot access them. A brochure site can safely deny all of them: Permissions-Policy: camera=(), microphone=(), geolocation=().
- Cookie flags: Secure, HttpOnly, and SameSite are set per cookie rather than as a page header. Secure means the cookie is never sent over plain HTTP, HttpOnly means JavaScript cannot read it, and SameSite=Lax stops it from riding along on requests from other sites. Together they are what keeps a stolen script from walking off with a logged-in session. WordPress sets sensible flags on its own auth cookies over HTTPS; anything your plugins set is worth checking by hand in the browser's Application tab.
- TLS version the encryption protocol the connection negotiates. TLS 1.2 and 1.3 are current; anything older is deprecated by browsers and no longer permitted under PCI DSS. This checker confirms that port 443 answers and reads the certificate; if you want the negotiated protocol version reported, run the domain health check, which tests it directly.
Questions people ask
Is this security headers checker free?
Yes. There is no account, no install and nothing to configure. A fair-use limit applies so it cannot be used for bulk scanning, but you will not run into it checking your own sites.
Do security headers affect SEO?
Not directly. There is no ranking factor for HSTS or a Content-Security-Policy, and adding them will not move you up a results page. HTTPS itself is a lightweight ranking signal, and a site that browsers mark "Not secure" loses visitors before Google gets involved. The real SEO argument is the indirect one: a hacked site gets injected spam links, a Safe Browsing warning and sometimes a manual action, and recovering from that costs far more than the ten minutes these headers take.
Will adding these headers break my site?
Four of them are safe on almost any site: X-Content-Type-Options, Referrer-Policy, Permissions-Policy, and X-Frame-Options — although X-Frame-Options will stop anyone legitimately embedding your pages, so check first if you run an embeddable booking or widget.
Two need care. A Content-Security-Policy will break your own JavaScript if it is written carelessly, which is why it should always go out in report-only mode first. HSTS is safe but effectively permanent for the duration of its max-age, so confirm every subdomain works over HTTPS before you set it.
What is a good score on this check?
HTTPS enforced, HSTS set, clickjacking protection present, nosniff set, and a healthy certificate is a genuinely good result, and it is achievable on any site in an afternoon. A Content-Security-Policy on top of that puts you ahead of the large majority of business websites.
Do not chase a perfect score for its own sake. A weak, wildcard-heavy CSP added purely to turn a line green is worse than no CSP, because it creates the belief that the problem is handled.
Does running this check change anything on my website?
No. It makes a request to your homepage, a request to the plain HTTP address to see where it redirects, and one TLS connection to port 443 to read the certificate. Nothing is submitted, nothing is written, and no login is attempted.
Do I have to give you my email address?
The headers found and missing are shown immediately. The complete fix list, with the configuration lines to paste, is behind an email address. You are asked once and never again on the same browser.
My host says they handle security. Do I still need these?
Run the check and see. Some managed WordPress hosts set a good baseline, most set one or two headers, and plenty set none. Whatever a host tells you, the response is the evidence — this tool simply shows you what your server is actually sending right now.
Why does my site show headers in one tool and not another?
Usually caching. If the header is set by a PHP plugin, a page served from a full-page cache or from a CDN edge may never run that code, so the header appears on an uncached request and vanishes on a cached one. That is exactly why setting headers at the server or the CDN is more reliable than setting them in WordPress.
Want these headers added without breaking anything?
Adding headers is ten minutes. Adding a Content-Security-Policy to a WordPress site with a page builder, three tracking scripts and an embedded booking widget is an afternoon of testing. We do that part. Send us the address and we will tell you which headers this site can take today and which need staging first.
