Response headers are invisible to visitors but read by every browser. They harden a site against common attacks and signal that it is actively maintained. Each one is a single line of server config, and the audit flags the ones you are missing.
A security header is an instruction your server sends with every page, in the HTTP response, telling the browser how to treat the site: force HTTPS, block framing, refuse to guess file types, and so on.
Unlike content, headers are set once in your server or CDN configuration and then apply to every URL automatically. They do not change what a page looks like; they change what a browser is allowed to do with it. That makes them cheap to add and easy to forget, which is exactly why an audit checks for them. A missing header rarely breaks anything visibly, so it sits unnoticed until a security review, a penetration test, or a browser tightening its defaults surfaces it.
They are grouped under an SEO audit for two reasons. First, a hardened, well-configured site is a trust signal, and trust is increasingly part of how sites are judged. Second, one of these headers, HSTS, directly reinforces the HTTPS that Google already treats as a ranking factor.
Six checks, each with the one-line fix.
Strict-Transport-Security tells the browser to only ever connect over HTTPS, closing the brief window where a first request could be intercepted on HTTP. Add Strict-Transport-Security: max-age=31536000; includeSubDomains.
CSP controls which sources of scripts, styles and images the browser will load, which is the primary defence against cross-site scripting. Start restrictive with Content-Security-Policy: default-src 'self' and widen it to the hosts you actually use.
Stops other sites embedding your pages in an iframe, which prevents clickjacking. Add X-Frame-Options: SAMEORIGIN, or the modern equivalent frame-ancestors 'self' inside your CSP.
Stops the browser guessing a file's type and running it as something it is not, a route to executing an upload as script. Add X-Content-Type-Options: nosniff.
Controls how much of your URL is sent to sites your pages link to, so private paths and query strings do not leak. A sensible default is Referrer-Policy: strict-origin-when-cross-origin.
Cookies without the Secure, HttpOnly and SameSite flags can be read over HTTP, stolen by scripts, or sent in cross-site requests. Set all three: Set-Cookie: id=...; Secure; HttpOnly; SameSite=Lax.
Most sites add every header in one place: the server or CDN config.
Because these are response headers, you do not edit page templates to add them. You set them once at the edge, in your web server config or your CDN, and they apply to every URL on the site. In nginx that is a block of add_header directives; on a CDN it is usually a response-header rule in the dashboard. Add the six above, then re-crawl, and the whole category clears at once.
One caution with Content-Security-Policy: it is the one header that can break a page if set too tightly, because it can block a script or stylesheet the page genuinely needs. Roll it out in Content-Security-Policy-Report-Only mode first, watch the browser console for what it would block, widen the policy to cover those legitimate sources, and only then switch it to enforcing.
Not directly, with one exception. Google does not rank a page lower purely because it lacks a Referrer-Policy or an X-Frame-Options header. The exception is HTTPS itself, which HSTS reinforces, and which Google has confirmed as a lightweight ranking signal.
The real value of the rest is defensive. A site that has been compromised, defaced, or used to serve malware will be flagged by Google Safe Browsing and can be dropped from results entirely, and these headers close the common routes to that outcome. They protect the rankings you already have rather than lifting you higher.
If you add only one header today, make it HSTS. It has the clearest search relevance because it locks in the HTTPS that Google already rewards, and it removes the small window on the first visit where a connection could be downgraded to HTTP and intercepted.
Add it only once you are confident every page and subdomain genuinely works over HTTPS, because HSTS is sticky: once a browser has seen the header, it refuses HTTP for that domain for the full max-age period. Test on a short max-age first, confirm nothing breaks, then raise it to a year.
A Content-Security-Policy that only permits HTTPS sources doubles as a guard against mixed content, where an HTTPS page loads an asset over plain HTTP and the browser downgrades the whole page to "not fully secure".
Fixing mixed content at the source, by serving every asset over HTTPS, is the primary fix, but a strict CSP stops a future stray HTTP asset from ever reaching the browser. The two checks reinforce each other, which is why they sit in the same category.
Free to start. The audit lists the exact headers absent on your site and the pages affected.
Start my free audit