Do security headers affect SEO?
Not directly - HTTPS is the only security signal Google has confirmed as a ranking factor. The indirect effects are real, and one misconfigured header can remove a page from the index entirely.
By Sapun Lamichhane · Arcetis
Directly, no - with one exception. HTTPS has been a confirmed ranking signal since 2014, described by Google at the time as lightweight and used as a tiebreaker. Nothing else in the security header set is a ranking factor, and no amount of A-plus grading on a header scanner will move a position.
Indirectly the picture is different, because several of these headers can break things that do affect rankings.
The header that can deindex you
Content-Security-Policy is the one to be careful with. It decides what the browser is allowed to load, and Googlebot is a browser.
A policy that blocks your own scripts leaves Googlebot rendering the same broken page a user with a blocked script would see. On a client-rendered site that can mean indexing a shell with no content in it. The failure is silent: the HTML returns 200, the server logs look healthy, and the only evidence is a console violation nobody reads.
This is not hypothetical. A CSP written for a development origin and shipped unchanged blocks the production API on every request - the app renders its error state, and that error state is what gets indexed.
- Test with `Content-Security-Policy-Report-Only` before enforcing it.
- Check the rendered output in Search Console's URL Inspection, which shows what Googlebot actually got rather than what your browser gets with your extensions and your cache.
- Confirm every origin your page genuinely calls is named - including your own API on a different subdomain.
The header that breaks your reporting
`Referrer-Policy: no-referrer` strips the referrer from every outgoing request. Your analytics then cannot tell organic search from direct traffic, and the data you use to decide what is working stops describing reality.
`strict-origin-when-cross-origin` is the sensible default: full referrer within your own origin, origin only across origins, nothing at all when downgrading from HTTPS to HTTP. It is also what most browsers now use when no policy is set.
The header that saves crawl budget
Strict-Transport-Security tells the browser to use HTTPS for your domain without asking. Every subsequent request skips the HTTP-to-HTTPS redirect - one fewer round trip per request, for every client that has seen the header.
On a site with a few hundred URLs the saving is negligible. On a large site it is a real reduction in requests spent on redirects rather than content, which matters if crawl budget is your constraint.
The ones with no SEO effect at all
X-Frame-Options, X-Content-Type-Options, Permissions-Policy and Cross-Origin-Opener-Policy are worth setting. They are not worth setting for SEO reasons, and any article telling you they lift rankings is guessing.
Set them because clickjacking and MIME sniffing are real, and because a site that audits other people's security while shipping none of its own is not credible. Not because a scanner grade correlates with a position.
What to actually do
- 1Serve everything over HTTPS with a valid certificate, and 301 HTTP to HTTPS once rather than through a chain.
- 2Add HSTS once you are confident every subdomain can serve HTTPS. It is difficult to reverse.
- 3Set `Referrer-Policy: strict-origin-when-cross-origin`.
- 4Write a CSP, run it in report-only, verify Googlebot's rendered output, then enforce it.
- 5Set the remaining headers for security reasons and do not expect a ranking change.
Our security headers checker reports what each header does to a crawler rather than issuing a letter grade - which headers affect rendering, which affect attribution, and which are purely defensive - so a policy that is about to break Googlebot is distinguishable from one that merely scores badly.