X-Frame-Options and Clickjacking Protection, What the Header Does and How to Add It
No X-Frame-Options or frame-ancestors. That is the flag when a site does not tell browsers who is allowed to embed it in a frame. It is not one of the heavier security checks, and it is worth being straight about what it does and does not do before you rush to fix it.
The honest version is this. X-Frame-Options is a credit header, not a penalty header. A site that sends it earns points toward the security score, a site that does not simply misses that credit, and nothing is deducted for the absence. The header is also being replaced by the frame-ancestors directive inside a Content-Security-Policy, which does the same job with more control, so the modern fix is often to add frame-ancestors to a policy you already run rather than bolt on a separate header.
The invisible iframe attack
Clickjacking is the attack this header exists to stop. An attacker builds a page that loads your site inside an invisible iframe, then lays transparent buttons over it. The visitor thinks they are clicking the attacker’s button, but the click actually lands on your site, on a button the attacker positioned underneath. That is how a visitor ends up authorising a payment, changing a setting, or submitting a form on your site without ever meaning to.
The attack is silent because nothing looks wrong. The page the victim sees is the attacker’s page, and your site is invisible behind it, doing whatever the misplaced click told it to do. It works best against sites with actions a victim would not deliberately take, which is why it is aimed at banking, admin panels, and account settings far more than at content sites.
Framing protection sits outside SEO audits
This flag rarely appears in SEO tools for the same reason the other security headers do not. Framing protection is not a ranking factor. It has nothing to do with keywords, links, or crawlability, and it will never move a position in search results. It is about what happens when a visitor’s browser loads your page inside someone else’s page, which is a browser security conversation, not a search one.
We look at these headers because of where we come from. The people behind Enterramon and Enterrahost have spent more than thirty years combined in ISP networks, network security, and hosting, and that experience predates both brands. Security headers are not an afterthought bolted onto an SEO report here, they are the core of what we check. When a flag like this shows up, it is a real gap in how your site behaves in a browser, and it is the kind of thing a ranking tool will simply never mention.
The fix has a decision in it
Most security headers are a straight yes or no. This one is not, because the answer depends on whether you ever legitimately embed your site elsewhere. The question is who should be allowed to frame your pages, and there are three answers with real differences between them.
DENY says nobody may frame the site, full stop. SAMEORIGIN says only your own domain may frame it, which covers the case where your own pages embed each other in iframes. frame-ancestors in a Content-Security-Policy goes further and lets you name specific origins that are allowed, which is the right tool when a partner or a widget host genuinely needs to embed you. The blanket DENY is the safest default, but if your site has a legitimate reason to be embedded somewhere, SAMEORIGIN or an explicit frame-ancestors allowlist is the correct answer, and a blanket DENY would quietly break that integration.
Adding X-Frame-Options or frame-ancestors
On Apache or LiteSpeed, the header goes in the virtual host or an .htaccess file with mod_headers enabled. LiteSpeed speaks the Apache config language, so the same block works on both.
Header always set X-Frame-Options "SAMEORIGIN"
On nginx, the same header inside the server block with the always keyword. If any location block declares its own add_header, the line has to be repeated inside that location block too, because nginx silently drops inherited headers when a child block sets its own.
add_header X-Frame-Options "SAMEORIGIN" always;
If you already run a Content-Security-Policy, the modern route is the frame-ancestors directive inside it rather than a separate header. The two are related, and a browser honours frame-ancestors when both are present, so there is no point setting X-Frame-Options DENY and then allowing origins in the policy.
Content-Security-Policy: ...; frame-ancestors 'self' https://partner.example.com
Behind Cloudflare, add X-Frame-Options as a response header transform rule, or add frame-ancestors to an existing Content-Security-Policy managed at the edge. If your Content-Security-Policy is already missing, that is a separate flag in the same report, and the missing Content-Security-Policy guide covers building one, which is also where frame-ancestors belongs.
Making sure the framing rule is live
You can see the header in a browser, no terminal needed. The server check tool returns the headers a domain serves, each security header on its own row, so find the x-frame-options line or the frame-ancestors entry in the content-security-policy. If you prefer the terminal, curl -I https://yourdomain.com shows the same headers.
Then run another Enterramon test and the flag should clear, which adds the framing credit back onto your security score. If the report also flagged a missing Content-Security-Policy, fixing that one first is the better order, because frame-ancestors can live inside the policy and cover this flag at the same time.
