Security-Header und SEO: was passiert, wenn dein Server schweigt

Fangen wir mit dem an, was oft zu vollmundig behauptet wird: Security-Header sind kein Ranking-Faktor. Google bewertet keine Seite besser, weil sie eine Content-Security-Policy mitschickt.

Der Zusammenhang ist trotzdem real, nur indirekt. Fehlende Header führen zu Zuständen, die sehr wohl in die Bewertung eingehen: blockierte Ressourcen, unvollständig gerendertes Markup, Warnungen im Browser und im schlimmsten Fall eine übernommene Seite. Was am Ende zählt, ist nicht die Kopfzeile — es ist das, was ohne sie passiert.

Sechs Kopfzeilen, was sie tun und was ihr Fehlen kostet.

Strict-Transport-Security#

Sagt dem Browser: Diese Domain wird ab sofort nur noch über HTTPS aufgerufen, auch wenn jemand die unverschlüsselte Adresse eintippt.

Ohne sie gibt es bei jedem ersten Aufruf einen kurzen unverschlüsselten Moment, in dem sich eine Verbindung umleiten lässt. Für die Sichtbarkeit relevanter ist der Nebeneffekt: Wer HSTS setzt, hat seine Weiterleitungen aufgeräumt. Wer es nicht setzt, hat oft dieselbe Seite unter vier Adressen erreichbar — und das ist ein handfestes SEO-Problem, weil Google sich dann eine davon aussucht.

Der übliche Wert ist ein Jahr. Vorsicht: Einmal gesetzt, lässt sich das nicht schnell zurücknehmen — der Browser merkt es sich für die gesamte Dauer. Erst prüfen, ob wirklich alles über HTTPS erreichbar ist.

Content-Security-Policy#

Die wirksamste und die unbequemste. Sie legt fest, aus welchen Quellen Skripte, Stile, Bilder und Verbindungen kommen dürfen.

Ohne sie kann eingeschleuster Code beliebige fremde Skripte nachladen. Genau das passiert bei den meisten übernommenen Auftritten: Nicht die Seite wird verändert, sondern ein Skript eingehängt, das Besucher weiterleitet — oft nur solche, die aus der Google-Suche kommen.

Der SEO-Bezug ist hier direkt: Eine zu strenge Regel blockiert eigene Skripte. Wenn ausgerechnet das Skript blockiert wird, das Inhalte nachlädt, sieht Google eine leere Seite. Deshalb gehört jede neue Richtlinie zuerst in den Berichtsmodus, ein paar ruhige Tage lang, bevor sie scharf gestellt wird.

X-Content-Type-Options#

Verbietet dem Browser zu raten, was für ein Dateityp da kommt. Ohne diese Zeile kann eine hochgeladene Datei als Skript interpretiert werden, obwohl sie als Bild deklariert wurde.

Eine Zeile, kein Nebenwirkungsrisiko, kein Grund sie wegzulassen.

X-Frame-Options und frame-ancestors#

Verhindern, dass deine Seite in einem fremden Rahmen eingebettet wird. Das schützt vor Klick-Umleitung — und nebenbei davor, dass jemand deine Inhalte unter eigener Adresse zeigt.

Die moderne Fassung steht in der Content-Security-Policy, die ältere Kopfzeile schadet daneben nicht.

Referrer-Policy#

Bestimmt, wie viel deiner Adresse an fremde Server weitergegeben wird, wenn jemand auf einen Verweis klickt. Der vernünftige Standard übermittelt die eigene Domain, aber nicht den genauen Pfad.

Datenschutzrelevant, sobald deine Adressen personenbezogene Parameter enthalten — was sie nicht sollten, aber häufig tun.

Permissions-Policy#

Schaltet Browser-Fähigkeiten ab, die deine Seite nicht braucht: Kamera, Mikrofon, Standort. Kostet nichts, verkleinert die Angriffsfläche.

Wo diese Zeilen hingehören#

Nicht in die Seite, sondern in die Auslieferung. Bei einem statischen Auftritt in die Konfiguration des Hosters, bei WordPress entweder in die Serverkonfiguration oder in ein kleines Plugin.

Der Fehler, der dabei am häufigsten passiert: Die Header werden gesetzt, aber ein Cache liefert weiter die alte Antwort. Nach jeder Änderung den Cache leeren und mit einem echten Abruf gegenprüfen — nicht im Browser, der ebenfalls zwischenspeichert, sondern mit einem Werkzeug, das den Server direkt fragt. Der Security-Scan zeigt dir, welche Kopfzeilen tatsächlich ankommen.

Der Fall, in dem es doch direkt aufs Ranking geht#

Gemischte Inhalte. Deine Seite läuft über HTTPS, lädt aber ein Bild oder ein Skript unverschlüsselt nach. Moderne Browser blockieren das stillschweigend.

Für Besucher heißt das: Ein Teil der Seite fehlt. Für Google heißt es dasselbe — und was nicht geladen wird, kann nicht bewertet werden. Ist ausgerechnet das Skript betroffen, das die Hauptinhalte aufbaut, sieht der Crawler eine Seite ohne Inhalt und behandelt sie entsprechend.

Die Anweisung upgrade-insecure-requests in der Content-Security-Policy fängt das ab, indem sie solche Aufrufe automatisch auf HTTPS hebt. Das ist ein Pflaster, kein Ersatz für saubere Adressen — aber es verhindert, dass eine vergessene unverschlüsselte Zeile eine ganze Seite unbrauchbar macht.

In welcher Reihenfolge man anfängt#

1. Die drei harmlosen zuerst: X-Content-Type-Options, X-Frame-Options, Referrer-Policy. Kein Risiko, sofort machbar.
2. HSTS, nachdem geprüft ist, dass alles über HTTPS erreichbar ist.
3. Content-Security-Policy im Berichtsmodus, mitlesen, was gemeldet wird, dann scharf stellen.
4. Nachmessen. Nicht annehmen, dass gesetzt ist, was in der Konfiguration steht.

Punkt 4 ist der, an dem es in der Praxis scheitert. Zwischen „ich habe es eingetragen" und „der Server schickt es" liegen ein Cache, eine Reihenfolge von Regeln und manchmal ein Hoster, der eigene Kopfzeilen darüberlegt.