← Security & domain health
Security headers

Browsers judge your site by headers you have never heard of.

Every page your website serves comes with a set of instructions to the browser that nobody ever sees. Send the right ones and whole categories of attack stop working. Send none and the browser is left to guess, which it does generously.

What we check, every week
  • Content-Security-PolicyLimits where scripts, styles and images may load from
  • Clickjacking protectionStops other sites wrapping yours in an invisible frame
  • X-Content-Type-OptionsStops browsers reinterpreting a file as a different type
  • Referrer-PolicyStops full page URLs leaking to every site you link to
  • HSTSTells browsers to refuse the insecure version of your site

What a header is, if nobody has ever explained it

When someone visits your website, your server sends the page, and alongside it a set of short instructions that the browser reads and the visitor never sees. Some are mundane, like what type of file this is. A handful are security instructions: rules the browser will enforce on your behalf if you bother to send them.

The important thing about them is that they are opt-in. A browser does not assume you want protection. If your server says nothing, the browser applies the loosest possible behaviour, which is the behaviour that keeps old websites working.

The ones that matter, and what each prevents

Content-Security-Policy is the significant one. It lists where scripts and other resources are allowed to load from. Its value is what happens when something goes wrong: if an attacker manages to inject a script into one of your pages, a policy that only permits scripts from your own domain means the injected script simply does not run. Without it, it runs with the full authority of your site.

Clickjacking protection stops another website loading yours inside an invisible frame and tricking visitors into clicking things they cannot see. It matters most for anything with a login or a form.

X-Content-Type-Options with the value nosniff stops browsers second-guessing what a file is. Without it a browser may decide an uploaded file is really a script and execute it.

Referrer-Policy controls how much of the current URL is passed on when a visitor clicks a link out. Without a sensible policy, the full address, including anything sensitive in the path or query, is handed to every site you link to.

Don't know what these are? Don't worry, we've got you!

Why so many sites send none of them

Because nothing breaks without them, nobody is ever prompted to add them, and they are not visible in the browser. There is no warning triangle, no notice in your hosting panel, no customer complaint. A site can run for a decade sending nothing.

They are also genuinely fiddly to get right the first time. A Content-Security-Policy that is too strict breaks your own site, which is why the honest advice is that a loose policy is dramatically better than none, and you tighten it once you know what your site actually loads.

We had this exact problem

When we ran our own scanner against this website in September 2026, it sent none of these headers. A product that grades other people A to F on security headers was sending zero of them, which was embarrassing and entirely typical: the site was built, it worked, and nobody was prompted.

We fixed it the same day. It took one configuration change. That is the honest shape of this problem: the fix is small, the discovery is the hard part, and knowing it is still in place next month is the part that needs a tool.

Common questions

  1. Do security headers affect my Google ranking?

    Not directly, with the exception of HTTPS itself, which is a long-standing signal. Headers protect visitors rather than rankings. The ranking damage comes later, if a site is compromised because it had no defences.

  2. What is the single most valuable header to add?

    A Content-Security-Policy, because it is the one that contains the damage when something else has already gone wrong. Even a permissive policy beats sending nothing.

  3. Will adding these break my website?

    A badly configured Content-Security-Policy can, because it blocks things your own pages rely on. The rest are safe to add. Start loose, confirm the site still works, then tighten.

Fixed once is not fixed

Everything on this page is a one-off job for whoever manages your website or your DNS. The reason it is a product rather than an afternoon is that all of it drifts: records get dropped in a migration, renewals break, a new tool starts sending email on your behalf and nobody updates the list. We check every week and show you what changed, in plain English, with the fix attached.