Security Headers & KI-Vertrauen: CSP und HSTS als Signal

Ein gültiges HTTPS-Zertifikat sagt für sich genommen noch nichts darüber aus, ob eine Website auch zusätzliche Sicherheits-Header wie CSP oder HSTS ausliefert – beides sind technisch getrennte Bausteine.

Definition: Security Headers sind HTTP-Antwort-Header wie Content-Security-Policy (CSP), Strict-Transport-Security (HSTS) oder X-Content-Type-Options, über die ein Server dem Browser mitteilt, welche Inhaltsquellen erlaubt sind und wie eine Seite ausschließlich verschlüsselt aufgerufen werden darf.

Was der Web Almanac 2025 über Security Headers zeigt

Der Web Almanac 2025 des HTTP Archive liefert die aktuellste breite Bestandsaufnahme zu Security Headers im offenen Web. Laut dem Web Almanac 2025 von HTTP Archive (Autoren Vik Vanderlinden und Gertjan Franken) liegt die HTTPS-Nutzung auf mobilen Startseiten bei 97,3 Prozent, aber nur 36 Prozent der untersuchten Seiten setzen Strict-Transport-Security ein und lediglich 21,9 Prozent Content-Security-Policy. (https://almanac.httparchive.org/en/2025/security)

Diese Lücke lässt sich technisch einordnen. Aus unserer Sicht liegt das auch an der Natur der Maßnahmen: Verschlüsselung lässt sich als Standardeinstellung ausliefern, CSP und HSTS erfordern dagegen eine bewusste, zusätzliche Serverkonfiguration. Für die GEO-Praxis heißt das zunächst nur: Ein gültiges SSL/TLS-Zertifikat sagt nichts darüber aus, ob ein Server auch die zusätzlichen Header ausliefert, die SSL/TLS-Zertifikate als KI-Vertrauenssignal beschreibt.

Google und HTTPS: Was das für Security Headers bedeutet

Google hat HTTPS bereits 2014 offiziell als Ranking-Signal eingeführt, die Bedeutung dieses Signals dabei aber ausdrücklich eingeordnet. Laut dem Search Central Blog von Google stuft das Unternehmen HTTPS selbst als “very lightweight signal” ein. (https://developers.google.com/search/blog/2014/08/https-as-ranking-signal)

Wenn schon die Verschlüsselung selbst als leichtgewichtiges Signal gilt, folgt daraus für zusätzliche Security Headers wie CSP und HSTS: Sie sind bislang kein dokumentierter eigenständiger Ranking- oder Zitierfaktor, weder bei Google noch bei KI-Suchsystemen. Ob ChatGPT, Perplexity oder Google AI Overviews Security Headers überhaupt als eigenes Signal auswerten, ist öffentlich nicht dokumentiert. Was diese Header technisch leisten, ist unabhängig von der Ranking-Frage: Sie schützen die Integrität einer Seite, und diese Integrität ist eine Voraussetzung dafür, dass Inhalte unverändert bei einem Crawler ankommen.

CSP und HSTS: Was die Header technisch absichern

Content-Security-Policy und Strict-Transport-Security lösen unterschiedliche Probleme. Eine Content-Security-Policy setzt an der Ressourcen-Ebene an: Sie legt fest, aus welchen Quellen eine Seite Skripte, Styles, Bilder oder andere Inhalte laden darf, wie die Definition zu Beginn dieses Beitrags beschreibt.

Strict-Transport-Security wirkt auf einer anderen Ebene. Laut Mozilla MDN teilt der HSTS-Header dem Browser mit, einen Host künftig ausschließlich über HTTPS anzusprechen, wodurch Nutzer Zertifikatsfehler auf dieser Domain danach nicht mehr umgehen können. (https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Strict-Transport-Security)

Vier zentrale Security Headers im Überblick:

Header	Funktion	Quelle
Content-Security-Policy	Legt erlaubte Quellen für Skripte, Styles, Bilder fest	OWASP
Strict-Transport-Security	Erzwingt HTTPS-Aufruf, blockiert Zertifikats-Bypass	MDN
X-Content-Type-Options	Verhindert MIME-Type-Sniffing durch den Browser	OWASP
Referrer-Policy	Steuert, welche Referrer-Daten an Drittseiten gehen	OWASP

Wie GPTBot und ClaudeBot auf Security Headers reagieren

Ein CSP- oder HSTS-Header hat keinen Einfluss darauf, ob GPTBot, ClaudeBot oder PerplexityBot eine Seite crawlen dürfen. Bot-Zugriffe laufen serverseitig, Security Headers wirken primär im Browser-Kontext; das eigentliche Zugriffsrecht regeln robots.txt-Anweisungen und die Server-Antwort auf die jeweilige Bot-Anfrage.

Für die Frage, ob ein Zugriff überhaupt vom echten Bot stammt, veröffentlichen die Anbieter eigene Referenzlisten. Laut OpenAI stellt das Unternehmen die IP-Bereiche von GPTBot und OAI-SearchBot in maschinenlesbaren JSON-Dateien bereit, damit Seitenbetreiber echte Crawler-Zugriffe von Spoofing unterscheiden können. (https://developers.openai.com/api/docs/bots)

Laut Anthropic stellt das Unternehmen für ClaudeBot, Claude-User und Claude-SearchBot ebenfalls eine IP-Liste (bots.json) zur Verifikation bereit und betont, dass alle drei Bots robots.txt-Sperrsignale respektieren. (https://privacy.claude.com/en/articles/8896518-does-anthropic-crawl-data-from-the-web-and-how-can-site-owners-block-the-crawler)

Diese Bot-Verifikation ist ein eigenständiges Thema, das KI-Crawler Fingerprinting: Echte Bots von Fälschungen unterscheiden vertieft. Für Security Headers bleibt relevant: Eine zu restriktive CSP kann eigene Ressourcen wie Schema-Markup-Skripte oder eingebettete Inhalte blockieren, wenn Quellen falsch konfiguriert sind – ein Rendering-Fehler, der dann auch für Crawler sichtbar wird, unabhängig vom User-Agent.

Security Headers als Teil deines technischen Vertrauensprofils

Security Headers gehören technisch zur gleichen Kategorie wie Serverkonfiguration, Cache-Steuerung und Zertifikatsverwaltung: Sie sind Teil der Infrastruktur, die eine Seite überhaupt verlässlich erreichbar und unverändert ausliefert. Das ist eine notwendige Grundlage für Sichtbarkeit, egal ob klassisches SEO, GEO oder KI-Suche über Systeme wie ChatGPT und Perplexity, auch wenn Security Headers selbst kein eigenständiger Ranking-Hebel sind.

Wer die eigene Serverkonfiguration ohnehin überarbeitet, sollte Security Headers gemeinsam mit angrenzenden Themen wie Cache-Header und Serverkonfiguration für KI-Crawler prüfen. Ob und wie stark einzelne Security Headers künftig in die Bewertung von Websites durch Suchsysteme einfließen, ist nach heutigem Stand nicht abschließend belegt.

Häufig gestellte Fragen

Blockieren Security Headers wie CSP das Crawling durch KI-Bots? Nein, eine Content-Security-Policy wirkt im Browser und steuert, welche Ressourcen eine Seite nachladen darf. Sie hat keinen direkten Einfluss darauf, ob GPTBot, ClaudeBot oder PerplexityBot eine Seite abrufen dürfen. Das regeln robots.txt-Anweisungen und die Server-Antwort auf die Bot-Anfrage.

Ist HSTS ein Ranking-Faktor für KI-Suchmaschinen? Laut Google Search Central ist bereits die reine HTTPS-Verschlüsselung nur ein “very lightweight signal” für das klassische Ranking. Für Security Headers wie HSTS gibt es öffentlich keine dokumentierte eigenständige Gewichtung, weder bei Google noch bei KI-Suchsystemen.

Wie prüfe ich, ob meine Website Security Headers korrekt einsetzt? Browser-Entwicklertools zeigen die tatsächlich ausgelieferten Response-Header einer Seite direkt im Netzwerk-Tab an. Für einen schnellen Überblick über Konfigurationslücken helfen spezialisierte Header-Checker.

Muss ich meine CSP anpassen, damit GPTBot oder ClaudeBot Inhalte korrekt erfassen? Eine CSP betrifft in erster Linie das Rendering im Browser, nicht den reinen Server-Abruf durch einen Crawler. Relevant wird sie dann, wenn eine zu restriktive Policy eigene Skripte oder eingebettete Inhalte blockiert und dadurch das Rendering verfälscht, das auch Crawler beim Abruf sehen.