77% of WordPress Sites Send No Security Headers

Method

On 16 August 2026 we requested the homepage of 59 sites ranking in the top twenty for web design, hosting, WordPress, freelancing and SEO queries, from a host in Helsinki. Fifty eight returned a 200 and one returned a 500 server error.

For each response we recorded six headers: HSTS, Content Security Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy. None of this is a scan and none of it puts load on the site. It is simply what the server sends in reply to one ordinary request.

The numbers

Thirty five of the 58 sent none of the six. Two sent all six: hostnegar.com and seokar.com, neither of which runs WordPress.

And the split that matters:

Why WordPress is behind

Not because WordPress is insecure. Because these headers are configured somewhere else entirely.

All six belong to the web server, or to a layer in front of it such as a CDN. Adding them means a few lines in an nginx or Apache config, or a few switches in a CDN panel. A WordPress site typically sits on shared hosting where the owner has no access to that configuration, so the work never happens. Sites built on other frameworks are more often deployed by a technical team onto their own server, where this is simply part of the deployment.

So the figure says more about the type of hosting than about WordPress. Which is also what makes it fixable.

What each header actually does

Only what they really do, with no inflation. The precise definition of each is in the MDN reference on HTTP headers.

HSTS tells the browser to always open this site over HTTPS. It closes the attack that intercepts that very first unencrypted request. If you already have an SSL certificate this is almost free, and we have written about why the certificate alone is not enough.

X-Frame-Options stops your site being displayed inside a frame on someone else's. The attack it prevents is the one where a user thinks they are clicking something on the attacker's page and are in fact clicking a button on yours.

X-Content-Type-Options tells the browser not to guess file types. Without it, a file a user uploaded may end up being executed as something else.

Referrer-Policy controls how much of the current URL travels with a visitor who clicks away from your site. It matters if your page addresses carry sensitive parameters.

Permissions-Policy restricts access to camera, microphone and location. For most sites all of them should be off.

Content Security Policy is the strongest and the hardest. It decides where a script is allowed to run from. It is hard because a bad policy breaks the site, which is exactly why it has the lowest rate in our table.

The order we suggest

The first three are lowest risk: X-Content-Type-Options, X-Frame-Options and Referrer-Policy. They almost never break anything and take minutes to add.

Then HSTS, provided you are certain the whole site works over HTTPS. If any part is still on HTTP, this header removes it from reach and undoing that takes time, because the browser has cached the instruction.

Content Security Policy last, and in report-only mode first. That mode tells you what would have been blocked without blocking anything.

What these headers do not do

This has to be said plainly because it is the most common misreading. None of these six stops a site being compromised through a vulnerable plugin. If a plugin on your site allows code execution, the attacker walks in the front door and no header is standing there.

The real priority order is this: current versions of core, theme and plugins; strong passwords and two-factor login; a backup that has actually been tested; and then these headers. Somebody who adds the headers while running a plugin that has not been updated in two years has locked the door and left the window open. The signs a site is at risk start from that end.

Frequently asked

Is WordPress secure? WordPress core is among the most heavily tested code on the web and its vulnerabilities get patched quickly. Almost every compromise seen in practice comes from a plugin, a theme or a weak password rather than from core.

What is the best WordPress security plugin? Before picking one, know this: a security plugin does things like limiting login attempts and scanning files. The headers in this article are set elsewhere. If a plugin promises both, check whether the header actually appears in the server response.

What are the key WordPress security practices? In order of effect: keep everything updated, use two-factor login, delete unused plugins and themes, run automatic backups stored elsewhere, and limit admin access to the people who genuinely need it.

How do I secure my site? By starting with what is most likely rather than what is loudest. Plugin vulnerabilities are many times more common than the attacks these headers prevent.

How do I see which headers my site sends? Open the browser developer tools, the Network tab, reload the page and click the first request. The response headers are listed right there.

If your site is in that 77 per cent and you have no access to the server configuration, this gets solved from the hosting side rather than from WordPress. Reviewing the server configuration and response headers is part of what we do, and the output is the same table you just read, this time for your own site.