CSP is a security policy declared via the Content-Security-Policy response header that whitelists which sources the browser is allowed to load resources from. If your page tries to execute a script from a domain not on the whitelist, the browser blocks it.
A modern CSP looks something like:
Content-Security-Policy:
default-src 'self';
script-src 'self' 'nonce-abc123' 'strict-dynamic';
style-src 'self' 'unsafe-inline';
img-src 'self' data: https:;
frame-ancestors 'none';
base-uri 'self';
Key concepts:
'self'— only resources from the same origin allowed'nonce-...'— a random per-request token; inline scripts must carry the matchingnonceattribute or they're blocked'strict-dynamic'— trust extends to scripts loaded by nonced scripts, without listing every hostframe-ancestors 'none'— blocks the page from being iframed (clickjacking defense)
CSPs that allow 'unsafe-inline' for scripts are mostly security theater — that's the directive that lets ANY inline script run, including injected XSS payloads. Modern CSPs use nonces or hashes instead.
Why it matters for AEO
Like HSTS, CSP contributes indirectly to EEAT — well-secured sites read as more trustworthy to both Google and AI engines. A CSP that survives security scrutiny (e.g., a clean Mozilla Observatory grade) shows up as a baseline-trust signal in audits that some LLM training corpora include.
Direct impact: CSP doesn't change how AI engines parse content. But misconfigured CSPs can break JSON-LD insertion (rare) or block legitimate analytics, which can knock other AEO signals offline.
What b/cited does about it
- Site readiness audit checks for CSP presence and flags
'unsafe-inline'onscript-srcas a critical security finding - Our own setup —
bcited.aiships a per-request CSP nonce +'strict-dynamic', no'unsafe-inline'on scripts (seemiddleware.ts)
The audit treats CSP as a medium-impact lever: requires real effort to implement (especially with React/Next.js), but the EEAT trust signal is meaningfully better than the no-CSP baseline.