Sicherheit, der unsichtbare SEO Rankingfaktor

SEO und Sicherheit? Was hat das eine eigentlich mit dem anderen zu tun? Sicherheit ist nicht nur ein Tech-Thema, sondern hat auch direkten Einfluss auf SEO und Vertrauen. Web-Security spielt heute eine wichtige Rolle für Vertrauen und User Experience. UX ist ein elementarer Bestandteil von SEO. 

Schon seit Längerem bezieht Google sicherheitsrelevante Themen in die Rankings ein. So werden HTTPS-Seiten bevorzugt und Chrome warnt aktiv bei unsicheren Formularen. Generell sollte man aber wissen, dass Sicherheit nur ein leichter SEO-Faktor ist. In den Core Web Vitals spielt Security nicht direkt mit, sondern mittelbar über UX‑Signale.

Bei SEO-Audits verschaffe ich mir meist einen schnellen Überblick mit dem SEO-Tool Screaming Frog. Beim Crawl werden auch sicherheitsrelevante Dinge betrachtet und meist kommen dieselben Fehler oder Vernachlässigungen zum Vorschein.

Probleme wie diese können nicht nur für Sicherheitslücken sorgen, sondern auch das Vertrauen der Nutzer schmälern und das Ranking beeinflussen.

Die 9 häufigsten Sicherheitslücken mit Auswirkungen auf dein SEO

Unsichere Websites kosten nicht nur Vertrauen, sondern auch Sichtbarkeit. Fehlende Sicherheits‑Header und Sicherheitsprobleme im Quellcode verschwenden Crawling Budget, behindern die Indexierung und drücken dein Ranking. Am Ende der Seite steht eine kostenfreie Checkliste zum Download bereit, die bei der Behebung in wenigen Schritten unterstützt.

Fehlende Sicherheits-Header

Sicherheits-Header sind Anweisungen, die der Webserver beim Laden einer Seite an den Browser sendet. Sie legen fest, wie Inhalte angezeigt, geladen oder geschützt werden sollen. Diese Header sieht man nicht, aber die Auswirkungen sind immens. Fehlen sie, ist deine Website wie ein Auto ohne Airbags: funktionstüchtig, aber man ist ungeschützt.

X-Content-Type-Options fehlt

Der Header X-Content-Type-Options: nosniff verhindert, dass Browser versuchen, den Dateityp selbst zu „erraten“ (sog. MIME-Sniffing).
Das ist wichtig, weil Angreifer z. B. eine CSS-Datei als JavaScript tarnen könnten. Der Browser würde den manipulierten Inhalt dann möglicherweise ausführen.

Dieser Schutz sorgt dafür, dass der Browser sich an den vom Server gelieferten Dateityp hält, und nicht selbst entscheidet, was eine Datei „sein könnte“.

Beispiel: Apache

Header set X-Content-Type-Options "nosniff"

Beispiel: nginx

add_header X-Content-Type-Options "nosniff";

X-Frame-Options fehlt

Mit diesem Header gibst du an, ob deine Seite in einem  <iframe> eingebettet werden darf. Ohne diesen Schutz könnte ein Angreifer deine Website in ein unsichtbares Fenster einbetten und den Nutzer unbemerkt dazu bringen, auf Buttons zu klicken (das nennt man Clickjacking).

Du verhinderst damit, dass jemand deine Seite in seine eigene Seite „einrahmt“, um Nutzer zu täuschen.

Es gibt verschiedene Optionen, die du hinterlegen kannst:

• DENY – Verbot jeglicher Einbettung
• SAMEORIGIN – Nur Einbettung von derselben Domain erlaubt
• ALLOW-FROM uri – (veraltet, nur noch von alten Browsern unterstützt)

Ich empfehle in der Regel SAMEORIGIN, außer du betreibst bewusst eine App (Seite), die sich einbetten lässt (z. B. externes Widget).

Zusätzlich solltest du auch in der CSP die Direktive „frame-ancestors“ konfigurieren. Dies ist der modernere und zukunftsweisendere Weg. Trotzdem solltest du die X-Frame-Options der Kompatibilität wegen zusätzlich einfügen bzw. behalten, auch wenn die Chrome Dev-Tools sie als „legacy“ vermerken.

Beispiel: Apache

Header always set X-Frame-Options "SAMEORIGIN"

Beispiel: nginx

add_header X-Frame-Options "SAMEORIGIN";

Content-Security-Policy (CSP) fehlt

CSP ist eine Art Sicherheitsfilter, der dem Browser sagt, welche Inhalte (z. B. Skripte, Bilder, Styles)und von wo diese geladen werden dürfen. Damit lässt sich z. B. verhindern, dass schädlicher Code von Dritten eingeschleust und ausgeführt wird (z. B. bei einem XSS-Angriff).

Oder ganz einfach gesagt: Du gibst dem Browser eine Liste: „Nur Inhalte von diesen Quellen dürfen geladen werden. Alles andere wird dann blockiert.“

Die CSP ist eines der komplexeren Themen. Denn nicht nur die offensichtlichen Quellen wie z.B. externe Dateien müssen berücksichtigt werden, sondern sämtliche weitere Quellen wie z.B. Google Analytics, Tracking-Scripte von Meta, Bing & Co, oder unerwartete Dateien, die über Plugins geladen werden.

Beispiel CSP für Apache:

Bei Einsatz dieser einfachen CSP dürfen nur Dateien vom eigenen Server geladen werden.

Header set Content-Security-Policy "default-src 'self';"

Diese komplexere CSP erlaubt alle Dateien vom eigenen Server, Bing Tracking (Skripte, Bilder und Datenverbindungen über bat.bing.com und bat.bing.net), Google Ads Tracking, Google Analytics, OpenStreetMap-Daten (über alle relevanten Subdomains), sowie alle notwendigen WordPress-Ressourcen (z. B. Inhalte von s.w.org und api.wordpress.org, inklusive Inline-Skripte und -Styles).

Header always set Content-Security-Policy "default-src 'self'; \
    script-src 'self' 'unsafe-inline' 'unsafe-eval' \
        https://bat.bing.com \
        https://www.google-analytics.com \
        https://www.googleadservices.com \
        https://pagead2.googlesyndication.com \
        https://s.w.org \
        https://api.wordpress.org; \
    style-src 'self' 'unsafe-inline'; \
    img-src 'self' data: \
        https://bat.bing.net \
        https://www.google-analytics.com \
        https://www.googleadservices.com \
        https://pagead2.googlesyndication.com \
        https://*.openstreetmap.org \
        https://s.w.org; \
    font-src 'self' data: https://s.w.org; \
    connect-src 'self' \
        https://bat.bing.com \
        https://bat.bing.net \
        https://www.google-analytics.com \
        https://www.googleadservices.com \
        https://pagead2.googlesyndication.com \
        https://api.wordpress.org \
        https://*.openstreetmap.org; \
    frame-src 'self'; \
    media-src 'self'; \
    object-src 'none'; \
    base-uri 'self'; \
    form-action 'self';"

Wichtiger Hinweis: Ich habe hier die Elemente untereinander geschrieben um es ein wenig übersichtlicher und verständlicher zu machen. Eine CSP muss aber beim apache Server zwingend in der .htaccess in einer einzigen Zeile angegeben werden. Bei nginx Servern ist dies nicht der Fall, dort kann die CSP auch mehrzeilig abgebildet werden.

Referrer-Policy fehlt

Der Referrer-Policy-Header bestimmt, wie viele Informationen über die vorherige Seite an den nächsten Link übergeben werden. Das kann wichtig sein, um z. B. keine Session-IDs, persönliche Pfade oder sensible Daten an Dritte zu leaken. Du kontrollierst, ob der Browser beim Klicken auf einen Link verrät, von welcher Unterseite der Besucher kam.

Empfohlene Werte:

• same-origin – Nur innerhalb der eigenen Seite die Referrer-Infos zulassen
• no-referrer – Keine Infos weitergeben
• strict-origin-when-cross-origin – Nur bei internen Links die komplette URL übergeben

Beispiel Referrer-Policy für Apache:

Header set Referrer-Policy "strict-origin-when-cross-origin"

Best Practice: Nutze strict-origin-when-cross-origin für eine gute Balance aus Privatsphäre & Analysefunktion.

Strict-Transport-Security (HSTS) fehlt

Mit dem HSTS-Header teilst du dem Browser mit, dass deine Seite dauerhaft nur per HTTPS erreichbar sein soll. Selbst wenn der Nutzer einmal eine HTTP-Adresse eintippt, wird automatisch auf HTTPS umgeleitet (vom Browser, ohne neuen Server-Call).

Einfach erklärt: Der Browser merkt sich: „Diese Seite darf ich ab jetzt nur noch verschlüsselt aufrufen!“

Parameter:

• max-age=63072000 = 2 Jahre
• includeSubDomains = Gilt auch für z. B. shop.domain.de
• preload = Google kann die Domain in eine Liste aufnehmen, die HSTS erzwingt

Beispiel Strict-Transport-Security (HSTS) für Apache:

Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

Typische Sicherheitsprobleme im Quellcode / Content von Seiten

Selbst wenn deine Server‑Header perfekt konfiguriert sind, können HTML‑Fragmente, CMS‑Plugins oder redaktionelle Fehler neue Sicherheitslücken öffnen, und damit Crawling (immer an das Crawling Budget denken), Rankings und das Nutzer‑Vertrauen gefährden. Im folgenden Abschnitt siehst du die häufigsten Stolperfallen direkt im Code oder Content, die du mit wenigen Handgriffen beheben kannst.

Gemischter Inhalt (Mixed Content)

Wenn eine HTTPS-Seite Inhalte per HTTP lädt (z. B. Bilder, Skripte), spricht man von „Mixed Content“. Browser blockieren solche Inhalte zunehmend, bzw. warnen Nutzer davor. Deine Seite ist eigentlich sicher, versucht aber Inhalte von unsicheren Quellen zu laden. Irgendwie ein wenig kontraproduktiv, oder?

Behebung des Problems:

Suche nach allen http:// Ressourcen im Quelltext und beseitige diese, setze sie auf https:// oder bei internen Links auf eine relative URL.

Es gibt aber noch eine Trumpf als Sofortmaßnahme. Man kann in der CSP einfach den Vermerk „upgrade-insecure-requests“ vornehmen. Dann werden automatisch alle http-Anfragen in https umgeschrieben. So bekommt man mit nur einer Zeile eine schnelle Lösung und kann sich dann an die händischen Anpassungen machen.

CSP Hack gegen gemischten Content

Content-Security-Policy: upgrade-insecure-requests

HTTP Verlinkungen intern oder extern

Links, die auf HTTP verweisen, entweder zu eigenen Seiten oder zu externen Quellen, gelten als veraltet oder unsicher.

Formular auf HTTP-URL

Formulare, die Nutzerdaten über unsichere Verbindungen versenden (z. B. auf einer HTTP-Seite), sind ein massives Risiko. Moderne Browser zeigen hier teils Warnungen an.

Best Practice:

• Stelle sicher, dass Formulare nur über HTTPS erreichbar sind
• Achte bei eingebetteten Formularen (z. B. von Drittanbietern) ebenfalls auf HTTPS

Unsichere Cross-Origin-Links

Wenn du einen Link mit target="_blank" öffnest, kann die neue Seite JavaScript verwenden, um auf die ursprüngliche Seite zuzugreifen, z. B. sie umleiten oder manipulieren.

Das liegt daran, dass die neue Seite über window.opener Zugriff auf das alte Tab hat.

Was bedeutet „Cross-Origin“ eigentlich?

„Origin“ bedeutet auf gut Deutsch: Herkunft einer Webseite.

Ein Origin wird durch drei Dinge bestimmt:

• Protokoll (http vs. https)
• Domainname (z. B. example.com)
• Port (z. B. :80, :443)

Wenn sich eine Ressource (Skript, Bild, Linkziel etc.) in mindestens einem dieser Punkte unterscheidet, spricht man von einer Cross-Origin-Situation.

Was hilft dagegen?

Das Attribut rel="noopener" (besser: rel="noopener noreferrer") in externen Verlinkungen mit dem Attribut target=“_blank“ verhindert genau das.

Kurze Zusammenfassung

Neun typische Konfigurations‑ und Content‑Fehler kosten dich im schlimmsten Fall Vertrauen, Conversions und Sichtbarkeit.

Priorisieren heißt gewinnen: Setze zuerst die Header mit hohem Security‑Nutzen und geringem Aufwand (X‑Content‑Type‑Options, Referrer‑Policy). Plane anschließend CSP & Mixed‑Content‑Bereinigung als Mini‑Projekt, denn dort liegen die größten kombinierten UX‑ und SEO‑Effekte. Wenn du diese neun Punkte beherrscht, hast ein gutes Fundament für sowohl sichere als auch suchmaschinenfreundliche Websites gelegt.