Die Migration von HTTP auf HTTPS ist heute für nahezu jede Website Pflicht – Google markiert HTTP-Seiten als unsicher, viele Browser blockieren sie, und HTTPS ist ein bestätigter (wenn auch kleiner) Rankingfaktor. Trotzdem verlieren viele Websites während der Migration Traffic und Rankings, weil grundlegende SEO-Aspekte übersehen werden. Diese Anleitung zeigt, wie Sie die Migration richtig durchführen.

Warum HTTPS für SEO wichtig ist

Google bestätigte 2014 HTTPS als Rankingfaktor. Seither hat die Bedeutung zugenommen:

Direkter Rankingfaktor: HTTPS wird als Tie-Breaker genutzt – bei sonst gleichen Seiten rankt die HTTPS-Version leicht besser.

Vertrauenssignal: Nutzer sehen das Schloss-Symbol und stufen die Seite als sicherer ein. Das senkt die Absprungrate, besonders auf Kontakt- und Anfrageseiten.

Chrome-Warnungen: Seit Chrome 68 markiert Google alle HTTP-Seiten mit Eingabefeldern als „Nicht sicher”. Das reduziert die Conversion-Rate messbar.

Referrer-Daten: HTTPS-zu-HTTPS-Weiterleitungen übertragen den Referrer-Header vollständig. HTTPS-zu-HTTP verliert ihn – das erschwert Traffic-Analyse.

Websites, die korrekt von HTTP auf HTTPS migriert wurden, verzeichnen im Schnitt einen Anstieg des organischen Traffics von 5–10 % innerhalb von 8 Wochen – durch bessere Nutzersignale und den HTTPS-Boost.

Vor der Migration: Vorbereitung ist alles

Schritt 1: SSL-Zertifikat beschaffen und installieren

Let’s Encrypt (kostenlos): Für die meisten Websites empfehlenswert. Automatische Erneuerung alle 90 Tage. Über Certbot oder direkt im Hosting-Panel (cPanel, Plesk) verfügbar.

Bezahlte Zertifikate: Für E-Commerce oder Enterprise-Websites mit Extended Validation (EV) oder Wildcard-Anforderungen. Anbieter: DigiCert, Comodo, GlobalSign.

Wildcard-Zertifikat: Wenn Sie Subdomains absichern müssen (*.example.de). Let’s Encrypt bietet auch Wildcard-Zertifikate (via DNS-Challenge).

Nach der Installation: Testen Sie HTTPS in mehreren Browsern und mit dem SSL Labs Server Test. Ziel: Mindestens Note A.

Schritt 2: Website auf HTTPS umstellen

Alle internen Links, Bilder, CSS- und JavaScript-Ressourcen müssen auf HTTPS verweisen, bevor Sie Weiterleitungen einrichten:

# WordPress: Einstellungen → Allgemein → WordPress-Adresse und Website-Adresse auf https:// ändern
# Dann Datenbank nach http:// durchsuchen mit Search & Replace DB

WordPress-spezifisch: Nach der URL-Änderung in den Einstellungen alle internen http://-URLs in der Datenbank ersetzen. Tool: Better Search Replace oder WP-CLI:

wp search-replace 'http://example.de' 'https://example.de' --all-tables

Schritt 3: 301-Weiterleitungen einrichten

Alle HTTP-URLs müssen per 301-Redirect auf HTTPS weiterleiten. In der .htaccess (Apache):

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Für Nginx:

server {
    listen 80;
    server_name example.de www.example.de;
    return 301 https://example.de$request_uri;
}

Wichtig: Leiten Sie direkt auf die finale URL weiter, nicht auf eine Zwischenstation. Eine Redirect-Kette (http:// → https:// → ohne www) kostet Link-Juice und verlangsamt die Seite. Mehr dazu in unserem Artikel über 301-Weiterleitungen und SEO.

Praxistipp: Richten Sie die Weiterleitung so ein, dass HTTP und www gleichzeitig auf die kanonische HTTPS-ohne-www-URL weiterleiten. Vier Varianten sollten alle auf eine URL führen: HTTP/www, HTTP ohne www, HTTPS/www – alle auf HTTPS ohne www weiterleiten. Direkte Weiterleitungen sparen einen Request.

Während der Migration: Was sofort getan werden muss

Canonical-Tags aktualisieren

Alle <link rel="canonical"> Tags müssen auf HTTPS verweisen. Wie Sie Canonical Tags richtig einsetzen, haben wir in einem eigenen Artikel erklärt. Wenn Sie Yoast oder Rank Math nutzen, passiert das automatisch nach der URL-Änderung in den WordPress-Einstellungen.

Manuell prüfen:

# Mit curl prüfen ob canonical korrekt ist
curl -s https://example.de/seite/ | grep canonical

Sitemap aktualisieren

Generieren Sie eine neue XML-Sitemap, die ausschließlich HTTPS-URLs enthält. Reichen Sie diese in der Google Search Console für die neue HTTPS-Property ein.

Search Console: Neue Property anlegen

HTTPS und HTTP sind für Google Search Console getrennte Properties. Legen Sie eine neue Property für https://example.de an und verifizieren Sie sie. Reichen Sie dort die neue Sitemap ein.

Wichtig: Lassen Sie die alte HTTP-Property bestehen! Dort sehen Sie, ob Google die HTTP-URLs noch crawlt, und können etwaige Indexierungsprobleme identifizieren.

Mixed Content: Der häufigste Fehler

Mixed Content bedeutet, dass eine HTTPS-Seite Ressourcen über HTTP lädt. Das blockiert Browser und erzeugt Fehlermeldungen.

Arten von Mixed Content:

Passive Mixed Content (Warnung): Bilder, Audio, Video über HTTP. Browser laden sie trotzdem, zeigen aber eine Warnung.

Active Mixed Content (Fehler): JavaScript, CSS, iFrames über HTTP. Browser blockieren diese – Ihre Seite kann komplett kaputt aussehen.

Mixed Content finden:

# Mit curl und grep auf einer Seite
curl -s https://example.de | grep -i 'src="http://'

# Mit Chrome: DevTools → Console → Mixed Content Fehler
# Mit dem Tool "Mixed Content Scan" für komplette Websites

Mixed Content beheben:

Alle internen Ressourcen-URLs auf HTTPS updaten (Datenbank-Replace wie oben)
Externe Ressourcen: Prüfen ob Anbieter HTTPS unterstützt, wenn ja URL ändern
Externe Ressourcen ohne HTTPS: Lokal hosten oder Anbieter wechseln

Mixed Content ist der häufigste Grund warum HTTPS-Migrationen scheitern – über 60 % aller fehlerhaften HTTPS-Implementierungen haben aktivem Mixed Content, der CSS oder JavaScript blockiert.

Nach der Migration: Monitoring

Google Search Console überwachen

Nach der Migration täglich prüfen (erste 2 Wochen):

Indexierungsabdeckung: Werden HTTPS-URLs indexiert?
Crawling-Fehler: Gibt es 404-Fehler auf alten HTTP-URLs?
Verlinkungsberichte: Verweisen externe Backlinks auf HTTP-URLs (→ Weiterleitungen prüfen)?

Rankings monitoren

Nutzen Sie ein Rank-Tracking-Tool (Sistrix, Ahrefs, Serpstat) und vergleichen Sie Rankings vor und nach der Migration. Kleine Schwankungen (±3 Plätze) sind normal in den ersten 4 Wochen. Starke Einbrüche (>10 Plätze) deuten auf technische Fehler hin.

Traffic-Vergleich in Analytics

In Google Analytics: Vergleichen Sie organischen Traffic 4 Wochen vor vs. 4 Wochen nach der Migration. Berücksichtigen Sie saisonale Schwankungen. Ein Traffic-Rückgang von mehr als 15 % ist ein Warnsignal.

HSTS: Die nächste Sicherheitsstufe

HTTP Strict Transport Security (HSTS) teilt Browsern mit, dass eine Domain ausschließlich über HTTPS aufgerufen werden darf. Das verhindert Downgrade-Angriffe und beschleunigt wiederholte Seitenaufrufe (kein HTTP-Redirect mehr nötig).

# In .htaccess oder server config
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Vorsicht: HSTS mit preload ist sehr schwer rückgängig zu machen. Erst aktivieren, wenn Sie sicher sind, dass Ihre Website dauerhaft HTTPS nutzt.

HSTS Preload List: Websites können in Googles HSTS Preload List aufgenommen werden. Browser laden diese Liste und erzwingen HTTPS direkt ohne HTTP-Redirect. Das verbessert TTFB um 50–100 ms für Erstbesucher. Anmelden unter hstspreload.org.

Checkliste HTTPS-Migration

Vor der Migration:

SSL-Zertifikat installiert und gültig (SSL Labs: Note A)
Website auf HTTPS umgestellt (WordPress-Einstellungen)
Datenbank-Replace für interne http:// URLs durchgeführt
301-Weiterleitungen konfiguriert (direkte Weiterleitung, keine Kette)
Mixed Content geprüft und behoben
Neue Sitemap mit HTTPS-URLs generiert

Nach der Migration:

Search Console: Neue HTTPS-Property angelegt und Sitemap eingereicht
Canonical-Tags auf HTTPS prüfen
Robots.txt auf HTTPS prüfen
Alle externen Backlinks mit wichtigem Linkjuice auf neue URL aktualisieren (wenn möglich)
Analytics-Property für HTTPS verifiziert
Rankings und Traffic 4 Wochen überwachen

HTTPS-Migration ohne Ranking-Verlust: Anleitung