Skip to main content
← Zurück zum Blog

SEO Guide Schritt 7: Sicherheit — Die Basis, die Google 2026 erwartet

·11 Min. Lesezeit·von LANGR SEO

SEO Guide Schritt 7: Sicherheit

Dies ist Schritt 7 des 13-Schritte SEO Leitfadens. Sicherheit bedeutet nicht nur, Nutzer zu schützen — sie hat direkten Einfluss auf deine Suchrankings. Google verwendet seit 2014 HTTPS als Ranking-Signal, und die Erwartungen sind nur gestiegen.

Die meisten Website-Besitzer betrachten Sicherheit als binär: „Wir haben SSL, also sind wir sicher.“ In Wirklichkeit bewertet Google Dutzende von Sicherheits-Signalen. Seiten mit korrekten Sicherheitsheadern, gültigen Zertifikaten und ohne Mixed Content haben höhere Platzierungen als Seiten mit nur einem grundlegenden SSL-Zertifikat — alles andere vorausgesetzt.

Die gute Nachricht: Die meisten Sicherheitskorrekturen sind einmalige Konfigurationen. Stelle sie einmal ein, und sie schützen deine Rankings dauerhaft.

SSL-Konfiguration

SSL (technisch TLS) verschlüsselt die Verbindung zwischen deinem Server und den Besuchern. Seit 2014 hat Google HTTPS ausdrücklich als Ranking-Signal bestätigt. Im Jahr 2026 ist das Fehlen von HTTPS nicht nur ein Ranking-Problem — Chrome markiert HTTP-Seiten in der Adressleiste als „Nicht Sicher“ und zerstört das Vertrauen der Nutzer.

Anforderungen für korrektes SSL:

| Anforderung | Warum | Wie prüfen | |-------------|-----|--------------| | Gültiges Zertifikat | Abgelaufen = Browser-Warnung = abspringende Nutzer | Ablaufdatum überprüfen | | Vollständige Kette | Unvollständige Ketten scheitern auf einigen Geräten | SSL Labs-Test | | TLS 1.2+ | Ältere Versionen haben bekannte Sicherheitsanfälligkeiten | SSL Labs-Test | | Kein SHA-1 | Abgekündigt, Browser lehnen es ab | Zertifikatsdetails | | SAN-Abdeckung | www und non-www müssen beide abgedeckt sein | Zertifikatsdetails | | Automatische Erneuerung | Verhindert Ablaufkatastrophen | Let's Encrypt / Anbieter-Konfiguration |

SSL-Bewertung:

100% = Gültiges Zertifikat + Vollständige Kette + TLS 1.3 + Starker Algorithmus + Automatische Erneuerung
  0% = Abgelaufenes oder fehlendes Zertifikat

Häufige SSL-Fehler:

  1. Zertifikat läuft ohne Vorwarnung ab — Überwache (Schritt 6) mindestens 30 Tage vor Ablauf
  2. Unvollständige Zertifikatkette — Der Server muss Zwischenzertifikate senden, nicht nur das Blatt
  3. Mixed Content — HTTPS-Seite lädt HTTP-Ressourcen (Bilder, Skripte, Stylesheets)
  4. Umleitungsloops — HTTP → HTTPS → HTTP-Zyklen durch fehlerhaft konfiguriertes CDN/Proxy
  5. Nicht-www vs www Mismatch — Zertifikat deckt eine Seite, aber nicht die andere ab

Schneller Gewinn: Lass deine Domain durch SSL Labs (ssllabs.com/ssltest) laufen. Alles unter einer „A“-Bewertung hat umsetzbare Probleme. Die meisten Hosting-Anbieter beheben diese mit einem Klick.

Sicherheitsheader

Sicherheitsheader sind HTTP-Antwortheader, die den Browser anweisen, wie er sich beim Laden deiner Seite verhalten soll. Sie verhindern ganze Kategorien von Angriffen — und Googles Crawler überprüfen sie.

Die wesentlichen Sicherheitsheader:

Content-Security-Policy (CSP)

CSP ist der mächtigste Sicherheitsheader. Er sagt den Browsern genau, welche Ressourcen (Skripte, Styles, Bilder, Schriftarten) auf deinen Seiten geladen werden dürfen.

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' https://fonts.gstatic.com; connect-src 'self' https://api.example.com; frame-ancestors 'none';

Was CSP verhindert:

  • Cross-Site-Scripting (XSS) Angriffe
  • Dateninjektionsangriffe
  • Clickjacking (über frame-ancestors)
  • Unautorisierte Skriptausführung (Cryptominer, Ad-Injector)

CSP-Bereitstellungsstrategie:

  1. Beginne mit Content-Security-Policy-Report-Only (protokolliert Verstöße ohne zu blockieren)
  2. Überwache Berichte für 1-2 Wochen
  3. Erstelle eine Whitelist für legitime Quellen
  4. Wechsle in den Durchsetzungsmodus
  5. Füge report-uri oder report-to für fortlaufende Verstöße hinzu

X-Frame-Options

Verhindert, dass deine Seite in iframes auf anderen Domains eingebettet wird (Clickjacking-Schutz).

X-Frame-Options: DENY

Oder wenn du das Einbetten derselben Ursprungsseite erlauben musst:

X-Frame-Options: SAMEORIGIN

X-Content-Type-Options

Verhindert, dass Browser MIME-Type-Sniffing durchführen (Dateien als andere Typen interpretieren als deklariert).

X-Content-Type-Options: nosniff

Dieser Einzeiler verhindert Angriffe, bei denen eine .jpg-Datei verstecktes JavaScript enthält, das der Browser möglicherweise ausführt.

Referrer-Policy

Steuert, wie viele Referrer-Informationen gesendet werden, wenn Nutzer auf Links von deiner Seite klicken.

Referrer-Policy: strict-origin-when-cross-origin

Dies sendet die vollständige URL für Anfragen vom gleichen Ursprung, jedoch nur den Ursprung (Domain) für Anfragen über verschiedene Ursprünge. Es balanciert den Bedarf an Analysen mit Datenschutz.

Permissions-Policy

Steuert, welche Browserfunktionen (Kamera, Mikrofon, Geolokalisierung usw.) auf deiner Seite verwendet werden können.

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()

Das Deaktivieren von Funktionen, die du nicht verwendest, verhindert, dass Drittanbieter-Skripte sie missbrauchen.

Beispiel für Header-Implementierung (Next.js):

// next.config.js
module.exports = {
  async headers() {
    return [{
      source: '/(.*)',
      headers: [
        { key: 'X-Content-Type-Options', value: 'nosniff' },
        { key: 'X-Frame-Options', value: 'SAMEORIGIN' },
        { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
        { key: 'Permissions-Policy', value: 'camera=(), microphone=(), geolocation=()' },
        { key: 'Strict-Transport-Security', value: 'max-age=31536000; includeSubDomains; preload' },
      ]
    }]
  }
}

Header-Implementierung (Apache .htaccess):

Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Header-Implementierung (Nginx):

add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Schneller Gewinn: Füge alle 5 obigen Header zu deiner Serverkonfiguration hinzu. Das dauert 5 Minuten und verbessert sofort deine Sicherheitslage in jedem Scan-Tool.

HSTS Preload

HTTP Strict Transport Security (HSTS) sagt Browsern, immer HTTPS für deine Domain zu verwenden — sogar bevor die erste Anfrage erfolgt. Ohne HSTS könnte der erste Besuch auf deiner Seite noch HTTP verwenden (anfällig für Abhörangriffe), bevor die Weiterleitung zu HTTPS erfolgt.

HSTS-Header:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Die drei Direktiven:

| Direktive | Bedeutung | |-----------|-----------| | max-age=31536000 | 1 Jahr (in Sekunden) merken | | includeSubDomains | Auch auf alle Subdomains anwenden | | preload | Bitte um Aufnahme in Browser-Preload-Listen |

HSTS-Preload-Liste:

Der ultimative HSTS-Schutz. Browser werden mit einer integrierten Liste von Domains ausgeliefert, die immer HTTPS verwenden müssen. Die Einreichung deiner Domain bei hstspreload.org bedeutet:

  • Erstbesucher erhalten sofort HTTPS (keine HTTP → HTTPS-Umleitung)
  • Angreifer können keine Verbindungen herabstufen
  • Permanent (schwierig zu entfernen, nachdem sie eingereicht wurde)

Anforderungen für HSTS Preload:

  1. Gültiges HTTPS-Zertifikat
  2. Alle HTTP-Anfragen auf HTTPS umleiten (einschließlich Subdomains)
  3. HSTS-Header mit max-age >= 31536000
  4. HSTS-Header enthält includeSubDomains
  5. HSTS-Header enthält preload
  6. Alle Subdomains müssen HTTPS unterstützen

Achtung: Reiche nur dann für Preload ein, wenn ALLE deine Subdomains HTTPS unterstützen. Die Direktive includeSubDomains bedeutet, dass jeder HTTP-nur-Subdomain unzugänglich wird.

Schneller Gewinn: Wenn du bereits HTTPS auf allen Subdomains hast, füge den vollständigen HSTS-Header hinzu und reiche ihn bei hstspreload.org ein. Die Bearbeitung dauert ein paar Wochen, aber der Schutz ist permanent.

Schwachstellenscan

Automatisierte Schwachstellenscans identifizieren bekannte Sicherheitsprobleme in deinem Stack, bevor Angreifer sie ausnutzen.

Was der Schwachstellenscan überprüft:

  • Veraltete Software: WordPress, Plugins, JavaScript-Bibliotheken mit bekannten CVEs
  • Exponierte Dateien: .env, .git, wp-config.php, Datenbank-Dumps
  • Informationsleck: Serverversionsheader, Debug-Modus, Stack-Traces
  • Standardkennwörter: Admin-Seiten ohne Authentifizierung, Standardpasswörter
  • Offene Ports/Dienste: Unnötige Dienste, die dem Internet ausgesetzt sind
  • Injektionspunkte: Formulare ohne CSRF-Schutz, nicht validierte Eingaben

Häufige Schwachstellen nach Plattform:

| Plattform | Hauptschwachstelle | Lösung | |----------|-------------------|-----| | WordPress | Veraltete Plugins | Automatische Aktualisierung + WAF | | Shopify | Berechtigungen von Drittanbieter-Apps | Vierteljährliche Überprüfung der App-Liste | | Next.js | Exponierte API-Routen | Auth-Middleware + Ratenbegrenzung | | Statische Seiten | CDN-Fehlkonfiguration | Überprüfung der Cache-Regeln | | Benutzerdefiniert | SQL-Injektion | Parametrisierte Abfragen |

Scan-Häufigkeit:

  • Täglich: Automatisierter Oberflächen-Scan (SSL, Header, exponierte Dateien)
  • Wöchentlich: Überprüfung auf Abhängigkeitsschwachstellen (npm audit, WordPress-Plugin-Scanner)
  • Monatlich: Tiefenscan mit authentifiziertem Test
  • Nach jedem Deployment: Regressionstest

Schneller Gewinn: Führe npm audit (Node.js) aus oder überprüfe deine CMS-Plugin-Liste auf veraltete Komponenten. Behebe kritische/hohe Schwereprobleme sofort.

Mixed Content

Mixed Content tritt auf, wenn eine HTTPS-Seite Ressourcen (Bilder, Skripte, Stylesheets, iframes) über HTTP lädt. Dies bricht teilweise die Verschlüsselung und löst Warnungen im Browser aus.

Arten von Mixed Content:

| Typ | Schwere | Beispiel | Verhalten des Browsers | |------|----------|---------|------------------| | Aktiv | Hoch | HTTP-Skript, iframe, CSS | Standardmäßig blockiert | | Passiv | Mittel | HTTP-Bild, Video, Audio | Mit Warnung geladen |

Aktiver Mixed Content wird von modernen Browsern blockiert — das bedeutet, deine Skripte und Styles werden einfach nicht geladen. Passiver Mixed Content wird geladen, zeigt aber Sicherheitswarnungen.

Mixed Content finden:

  1. Öffne Chrome DevTools → Konsole
  2. Suche nach „Mixed Content“-Warnungen
  3. Alternativ scanne mit einem Crawler (Screaming Frog, LANGR)

Häufige Quellen für Mixed Content:

  • Hardcodierte http:// URLs im Inhalt (Blogbeiträge, Produktbeschreibungen)
  • Drittanbieter-Widgets, die HTTP-Ressourcen laden
  • Eingebettete Inhalte (alte YouTube-Embedcodes, Social Media-Widgets)
  • CSS background-image mit HTTP-URLs
  • Schriften, die über HTTP geladen werden

Mixed Content beheben:

<!-- Schlecht -->
<img src="http://example.com/image.jpg" />

<!-- Gut -->
<img src="https://example.com/image.jpg" />

<!-- Am besten (protokollrelativ, passt sich dem Seitenprotokoll an) -->
<img src="//example.com/image.jpg" />

Datenbankfix (WordPress):

UPDATE wp_posts SET post_content = REPLACE(post_content, 'http://yourdomain.com', 'https://yourdomain.com');
UPDATE wp_postmeta SET meta_value = REPLACE(meta_value, 'http://yourdomain.com', 'https://yourdomain.com');

Schneller Gewinn: Öffne deine Homepage in Chrome, drücke F12, und überprüfe den Tab „Konsole“ auf Warnungen zu Mixed Content. Behebe alle, die erscheinen — diese sind direkt für Google sichtbar.

Risiken durch Drittanbieter-Skripte

Jedes externe Skript, das du lädst, ist eine potenzielle Sicherheits-(und Leistungs-)Haftung. Drittanbieter-Skripte können:

  • Kompromittiert werden (Angriffe auf die Lieferkette)
  • Deine Nutzer ohne Zustimmung verfolgen (Verstoß gegen die DSGVO)
  • Deine Seite verlangsamen (render-blockierend, Netzwerk-Latenz)
  • Die Funktionalität beeinträchtigen (Versionsupdates, Ausfälle)
  • Unerwünschte Inhalte injizieren (fehlerhafte Ad-Skripte)

Auditiere deine Drittanbieter-Skripte:

| Skript | Notwendig? | Risikostufe | Alternative | |--------|-----------|------------|-------------| | Google Analytics | Oft ja | Niedrig | Serverseitiges Tracking | | Chat-Widgets | Vielleicht | Mittel | Selbst gehostete Lösungen | | Buttons zum Teilen in sozialen Medien | Selten | Mittel | Statische Share-Links | | A/B-Tests | Manchmal | Hoch | Serverseitiges Testen | | Retargeting-Pixels | Geschäftliche Entscheidung | Hoch | Erstparteidaten | | Schriftarten-CDNs | Praktisch | Niedrig | Selbst gehostete Schriften |

Risikominderung für essentielle Drittanbieter-Skripte:

  1. Subressourcen-Integrität (SRI): Hash-Bestätigung verhindert das Laden manipulierten Skripte
<script src="https://cdn.example.com/lib.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxAE+sO0..."
        crossorigin="anonymous"></script>
  1. CSP-Beschränkungen: Erlaube nur Skripte von bekannten Domains
  2. Sandboxed iframes: Isoliere Drittanbieter-Widgets
  3. Regelmäßige Audits: Vierteljährliche Überprüfung aller externen Ressourcen
  4. Überwachung: Alarm bei neuen externen Domains, die in deinen Seiten erscheinen

Schneller Gewinn: Liste jedes