HTTP auf HTTPS umleiten in WordPress

Deine WordPress-Seite von HTTP auf HTTPS umzustellen ist längst keine Option mehr. Browser kennzeichnen HTTP-Seiten als "Nicht sicher", Google nutzt HTTPS als Ranking-Signal, und die Daten deiner Besucher werden ohne Verschlüsselung im Klartext übertragen. Nach der Installation eines SSL-Zertifikats musst du den gesamten HTTP-Traffic korrekt auf HTTPS umleiten und verbleibende Mixed-Content-Probleme beheben. Dieser Leitfaden deckt jeden Schritt des Prozesses ab, vom Erhalten eines Zertifikats bis zum Debugging von Redirect-Loops hinter Load Balancern.

Warum HTTPS über die reine Sicherheit hinaus wichtig ist

Der offensichtliche Grund für HTTPS ist Verschlüsselung. Ohne sie kann alles zwischen dem Browser deines Besuchers und deinem Server (Formular-Eingaben, Login-Daten, Cookies, persönliche Daten) von jedem im selben Netzwerk abgefangen werden. Aber HTTPS ist aus mehreren weiteren Gründen wichtig, die den Erfolg deiner Seite direkt beeinflussen:

• SEO-Ranking-Faktor: Google hat im August 2014 bestätigt, dass HTTPS ein Ranking-Signal ist. Obwohl es ein leichtes Signal ist, wird bei ansonsten gleichen Bedingungen die HTTPS-Version einer Seite höher ranken als die HTTP-Version. In umkämpften Nischen zählt jedes Signal.
• Browser-Warnungen: Chrome, Firefox, Safari und Edge zeigen alle "Nicht sicher"-Warnungen für HTTP-Seiten an, besonders bei solchen mit Formulareingaben. Das untergräbt das Vertrauen der Besucher und erhöht die Absprungrate. Chrome hat diese Warnungen seit Chrome 68 (Juli 2018) schrittweise deutlicher gemacht.
• HTTP/2- und HTTP/3-Unterstützung: Moderne Protokolle wie HTTP/2 und HTTP/3, die die Ladegeschwindigkeit durch Multiplexing und Header-Komprimierung drastisch verbessern, erfordern in der Praxis HTTPS. Alle großen Browser unterstützen HTTP/2 nur über TLS.
• Referrer-Daten: Wenn ein Besucher auf einer HTTPS-Seite auf einen Link zu einer HTTP-Seite klickt, entfernt der Browser den Referrer-Header. Das bedeutet, du verlierst Analytics-Daten darüber, woher dein Traffic kommt. Wenn deine Seite auf HTTPS ist, bleiben Referrer-Daten von anderen HTTPS-Seiten erhalten.
• Service Workers und PWA: Progressive Web App Features wie Offline-Caching, Push-Benachrichtigungen und der "Zum Startbildschirm hinzufügen"-Prompt erfordern HTTPS.

Kostenloses SSL-Zertifikat mit Let's Encrypt erhalten

Du musst nicht für ein SSL-Zertifikat bezahlen. Let's Encrypt stellt kostenlose, automatisierte, Domain-validierte (DV) Zertifikate bereit, denen alle großen Browser vertrauen. Die meisten Hosting-Anbieter haben Let's Encrypt in ihre Control Panels integriert, aber wenn du deinen eigenen Server verwaltest, richtest du es so mit Certbot ein:

# Certbot auf Ubuntu/Debian installieren
sudo apt update
sudo apt install certbot

# Für Apache
sudo apt install python3-certbot-apache
sudo certbot --apache -d example.com -d www.example.com

# Für Nginx
sudo apt install python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

Certbot konfiguriert deinen Webserver automatisch für die Nutzung des Zertifikats und richtet einen Cron-Job für die automatische Verlängerung ein. Let's-Encrypt-Zertifikate sind 90 Tage gültig, aber der Auto-Renewal-Prozess handhabt das transparent. So überprüfst du, ob die automatische Verlängerung funktioniert:

# Verlängerungsprozess testen (verlängert nicht tatsächlich)
sudo certbot renew --dry-run

# Verlängerungs-Timer prüfen
sudo systemctl status certbot.timer

Wenn dein Hosting-Anbieter Ein-Klick-SSL über sein Control Panel anbietet (SiteGround, Bluehost, HostGator usw.), nutze das stattdessen. Es ist dasselbe Let's-Encrypt-Zertifikat, aber von deinem Host verwaltet, was eine Sache weniger zum Warten bedeutet.

Schritt 1: WordPress-URLs aktualisieren

Bevor du Weiterleitungen einrichtest, teile WordPress mit, dass deine Seite jetzt HTTPS nutzt. Gehe zu Einstellungen > Allgemein und aktualisiere beide Felder:

• WordPress-Adresse (URL): Ändere http://example.com zu https://example.com
• Website-Adresse (URL): Ändere http://example.com zu https://example.com

Wenn du nicht auf das Admin-Dashboard zugreifen kannst (zum Beispiel wenn du bereits in einem Redirect-Loop feststeckst), kannst du diese Werte direkt in wp-config.php setzen:

define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

Oder aktualisiere die Datenbank direkt per WP-CLI:

wp option update siteurl 'https://example.com'
wp option update home 'https://example.com'

Schritt 2: Server-Level HTTP-zu-HTTPS-Weiterleitung

Die Weiterleitung muss auf Server-Ebene erfolgen (nicht in PHP), aus zwei Gründen: sie ist schneller, weil WordPress nicht geladen werden muss, und sie stellt sicher, dass alle Anfragen (einschließlich statischer Dateien, Bilder und API-Aufrufe) umgeleitet werden, nicht nur WordPress-verarbeitete URLs.

Apache (.htaccess)

Füge dies ganz oben in deine .htaccess-Datei ein, vor den WordPress-Rewrite-Regeln (vor dem # BEGIN WordPress-Kommentar):

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

Das R=301-Flag sendet eine permanente Weiterleitung, die Suchmaschinen mitteilt, ihren Index auf die HTTPS-Version zu aktualisieren. Verwende kein R=302 (temporäre Weiterleitung), weil Suchmaschinen die Link-Autorität nicht auf die neue URL übertragen werden.

Nginx

Erstelle in deiner Nginx-Konfiguration einen separaten Server-Block für HTTP, der alles auf HTTPS umleitet:

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

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # ... restliche Konfiguration
}

Die Verwendung von return 301 in Nginx ist effizienter als rewrite, weil keine Regex-Verarbeitung erforderlich ist.

Schritt 3: HTTPS in wp-config.php erzwingen

Füge diese Zeilen zu deiner wp-config.php hinzu, oberhalb des "That's all, stop editing!"-Kommentars:

// SSL für den WordPress-Adminbereich erzwingen
define('FORCE_SSL_ADMIN', true);

// SSL hinter einem Reverse Proxy oder Load Balancer handhaben
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

Die Konstante FORCE_SSL_ADMIN stellt sicher, dass die WordPress-Login-Seite und das Admin-Dashboard immer HTTPS verwenden, auch wenn jemand versucht, sie direkt über HTTP aufzurufen.

Redirect-Loops hinter Load Balancern und Reverse Proxies beheben

Das ist eines der häufigsten Probleme bei WordPress-HTTPS-Setups, und es bringt viele Leute zum Stolpern. Wenn deine Seite hinter einem Load Balancer, Cloudflare, einem Reverse Proxy oder einem CDN steht, ist die Verbindung zwischen dem Proxy und deinem Server oft einfaches HTTP, obwohl die Verbindung zwischen dem Besucher und dem Proxy HTTPS ist. Dein Server sieht eine HTTP-Anfrage und versucht auf HTTPS umzuleiten, der Proxy sendet die Anfrage als HTTP zurück, und du landest in einem endlosen Redirect-Loop. Der Browser zeigt "ERR_TOO_MANY_REDIRECTS."

Die Lösung ist die oben gezeigte X-Forwarded-Proto-Header-Prüfung. Der Proxy fügt diesen Header hinzu, um deinem Server mitzuteilen, welches Protokoll die ursprüngliche Anfrage verwendet hat. Wenn WordPress sieht, dass das weitergeleitete Protokoll HTTPS ist, behandelt es die Verbindung als sicher und löst keine Weiterleitung aus.

Wenn die Standard-Header-Prüfung nicht funktioniert, verwendet dein Proxy möglicherweise einen anderen Header. Frage bei deinem Hosting-Anbieter nach. Gängige Variationen sind:

// Für einige Load Balancer, die X-Forwarded-Ssl verwenden
if (isset($_SERVER['HTTP_X_FORWARDED_SSL']) && $_SERVER['HTTP_X_FORWARDED_SSL'] === 'on') {
    $_SERVER['HTTPS'] = 'on';
}

// Für Cloudflare (das auch X-Forwarded-Proto setzt, aber sicherheitshalber)
if (isset($_SERVER['HTTP_CF_VISITOR'])) {
    $visitor = json_decode($_SERVER['HTTP_CF_VISITOR']);
    if (isset($visitor->scheme) && $visitor->scheme === 'https') {
        $_SERVER['HTTPS'] = 'on';
    }
}

Schritt 4: HTTP-URLs in der Datenbank ersetzen

Deine WordPress-Datenbank enthält hartcodierte HTTP-URLs in Beitragsinhalten, Widget-Einstellungen, Theme-Optionen und serialisierten Daten. Du musst sie alle durch HTTPS-Versionen ersetzen. Das beste Werkzeug dafür ist der search-replace-Befehl von WP-CLI:

# Zuerst einen Dry-Run durchführen, um zu sehen, was sich ändern würde
wp search-replace 'http://example.com' 'https://example.com' --all-tables --dry-run

# Wenn der Dry-Run gut aussieht, die tatsächliche Ersetzung durchführen
wp search-replace 'http://example.com' 'https://example.com' --all-tables

# Auch www/nicht-www-Varianten handhaben, falls zutreffend
wp search-replace 'http://www.example.com' 'https://www.example.com' --all-tables

Das --dry-run-Flag ist wichtig. Es zeigt dir genau, wie viele Ersetzungen in jeder Tabelle vorgenommen werden, ohne tatsächlich etwas zu ändern. Überprüfe die Ausgabe, bevor du die echte Ersetzung durchführst. Das --all-tables-Flag stellt sicher, dass benutzerdefinierte Tabellen (von Plugins wie WooCommerce, ACF oder Page Buildern) einbezogen werden.

WP-CLI handhabt serialisierte Daten korrekt, was entscheidend ist. Wenn du versuchst, ein einfaches SQL-Suchen-und-Ersetzen durchzuführen, wirst du serialisierte Arrays beschädigen, weil die Stringlängen-Werte nicht mehr übereinstimmen. Führe niemals eine rohe SQL-REPLACE()-Abfrage für diesen Zweck aus.

Mixed-Content-Probleme beheben

Mixed Content tritt auf, wenn deine HTTPS-Seite Ressourcen (Bilder, Skripte, Stylesheets, Iframes) über HTTP lädt. Browser blockieren gemischte aktive Inhalte (Skripte, Stylesheets) vollständig und warnen möglicherweise vor gemischten passiven Inhalten (Bilder). Das führt zu defekter Funktionalität oder gelben Warnsymbolen in der Adressleiste.

So findest du Mixed-Content-Probleme:

1. Browser-Konsole: Öffne die DevTools (F12) und schau dir den Console-Tab an. Mixed-Content-Warnungen erscheinen als gelbe oder rote Meldungen, die die genauen URLs der betroffenen Ressourcen auflisten.
2. InspectWP: Führe einen Scan durch und prüfe den HTML-Bereich. InspectWP erkennt unsichere (HTTP-)Ressourcen, die auf HTTPS-Seiten geladen werden, und listet jede einzelne auf.
3. Why No Padlock: Die Seite whynopadlock.com scannt deine Seite und meldet alle Mixed-Content-Ressourcen mit ihren Quell-URLs.

Häufige Quellen von Mixed Content und wie man sie behebt:

• Hartcodierte URLs in Theme-Dateien: Durchsuche die PHP- und CSS-Dateien deines Themes nach http://-Referenzen. Ersetze sie durch https:// oder verwende besser protokollrelative URLs (//) oder WordPress-Funktionen wie esc_url().
• Bilder in Beitragsinhalten: Der WP-CLI search-replace-Befehl (Schritt 4) behandelt die meisten davon. Für hartnäckige Fälle prüfe das rohe HTML im Text-Editor.
• Widgets und Customizer-Einstellungen: Bild-URLs in Widgets, benutzerdefinierten Headern und Customizer-Einstellungen werden als serialisierte Daten gespeichert. WP-CLI search-replace handhabt diese korrekt.
• Page-Builder-Inhalte: Elementor, Beaver Builder, Divi und andere Page Builder speichern ihre Inhalte in benutzerdefinierten Formaten. WP-CLI mit --all-tables erfasst diese normalerweise, aber verifiziere es, indem du Seiten lädst, die mit deinem Page Builder erstellt wurden.
• Externe Ressourcen: Wenn du Schriftarten, Skripte oder Bilder von externen Domains über HTTP lädst, aktualisiere diese URLs. Die meisten CDNs und Schriftarten-Dienste (Google Fonts, cdnjs usw.) unterstützen HTTPS.

Really Simple SSL als Alternative verwenden

Wenn dir der manuelle Ansatz zu aufwendig erscheint, automatisiert das Really Simple SSL Plugin den Großteil des Prozesses. Installiere es, aktiviere es, und es wird:

• Dein SSL-Zertifikat automatisch erkennen.
• Die WordPress-Site-URL und Home-URL auf HTTPS aktualisieren.
• Eine 301-Weiterleitung von HTTP zu HTTPS per PHP (oder .htaccess wenn möglich) einrichten.
• Mixed Content beheben, indem HTTP-URLs im laufenden Betrieb ersetzt werden.

Der Nachteil von Really Simple SSL ist, dass es Mixed Content dynamisch bei jedem Seitenaufruf behebt, was einen kleinen Verarbeitungs-Overhead hinzufügt. Es ist besser, die Ursachen zu beheben (Datenbank-URLs, hartcodierte Referenzen) und dann das Plugin zu entfernen. Betrachte es als nützliche Brücke während der Migration, nicht als permanente Lösung.

Schritt 5: HSTS-Header hinzufügen

HTTP Strict Transport Security (HSTS) teilt Browsern mit, für deine Domain immer HTTPS zu verwenden, auch wenn der Nutzer http:// in die Adressleiste tippt. Nachdem du bestätigt hast, dass HTTPS auf deiner Seite korrekt funktioniert (kein Mixed Content, keine Redirect-Loops), füge den HSTS-Header hinzu:

Apache (.htaccess)

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

Nginx

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Der Wert max-age=31536000 (ein Jahr) teilt Browsern mit, die HSTS-Richtlinie für 12 Monate zu speichern. Beginne mit einem kürzeren Wert wie max-age=86400 (ein Tag) während des Testens und erhöhe ihn, sobald du sicher bist, dass alles funktioniert. Die Direktive includeSubDomains erweitert die Richtlinie auf alle Subdomains. Füge preload nur hinzu, wenn du planst, deine Domain bei der HSTS-Preload-Liste (hstspreload.org) einzureichen, die die HTTPS-Anforderung deiner Domain direkt in die Browser einprogrammiert.

CDN- und Cloudflare-HTTPS-Konfiguration

Wenn du Cloudflare oder ein anderes CDN verwendest, hat die HTTPS-Konfiguration eine zusätzliche Komplexitätsebene:

• Cloudflare Flexible SSL: Der Traffic ist zwischen dem Besucher und Cloudflare verschlüsselt, aber die Verbindung zwischen Cloudflare und deinem Server ist einfaches HTTP. Das ist am einfachsten einzurichten (kein SSL-Zertifikat auf deinem Server nötig), bietet aber unvollständige Sicherheit. Daten zwischen Cloudflare und deinem Server sind unverschlüsselt.
• Cloudflare Full SSL: Der Traffic ist auf beiden Seiten verschlüsselt, aber Cloudflare verifiziert das Zertifikat deines Servers nicht. Du brauchst ein SSL-Zertifikat auf deinem Server, aber es kann selbstsigniert sein.
• Cloudflare Full (Strict) SSL: Die empfohlene Einstellung. Der Traffic ist auf beiden Seiten verschlüsselt und Cloudflare verifiziert das Zertifikat deines Servers. Verwende ein gültiges Let's-Encrypt-Zertifikat oder ein Cloudflare-Origin-Zertifikat.

Wenn du von Flexible auf Full (Strict) wechselst, stelle sicher, dass dein Server zuerst ein gültiges SSL-Zertifikat installiert hat. Andernfalls geht deine Seite offline, weil Cloudflare keine sichere Verbindung zu deinem Server herstellen kann.

Cloudflare bietet auch "Immer HTTPS verwenden" unter SSL/TLS > Edge-Zertifikate an, das die HTTP-zu-HTTPS-Weiterleitung am Cloudflare-Edge durchführt. Das ist schneller als eine Weiterleitung auf deinem Origin-Server, weil der Besucher deinen Server für die HTTP-Anfrage nie erreicht.

SSL-Zertifikat-Ablauf und automatische Verlängerung prüfen

Ein abgelaufenes SSL-Zertifikat ist schlimmer als gar kein Zertifikat. Browser zeigen eine ganzseitige Warnung an, durch die die meisten Besucher nicht klicken werden, und deine Seite geht effektiv offline. So überwachst du dein Zertifikat:

# Zertifikat-Ablaufdatum prüfen
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

# Tage bis zum Ablauf prüfen
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -enddate

Wenn du Let's Encrypt mit Certbot nutzt, sollte die automatische Verlängerung automatisch konfiguriert sein. Aber verifiziere, dass sie tatsächlich funktioniert, indem du die Certbot-Verlängerungs-Logs prüfst:

# Certbot-Verlängerungs-Log prüfen
cat /var/log/letsencrypt/letsencrypt.log | tail -20

# Alle Zertifikate und ihre Ablaufdaten auflisten
sudo certbot certificates

Für Produktionsseiten richte ein Monitoring ein, das dich warnt, wenn dein Zertifikat sich dem Ablauf nähert. Dienste wie UptimeRobot, StatusCake oder sogar ein einfacher Cron-Job, der das Zertifikatsdatum prüft, können dich vor unerwarteter Downtime bewahren.

HTTPS-Setup mit InspectWP überprüfen

Nach Abschluss der Migration führe einen InspectWP-Scan durch, um zu überprüfen, dass alles korrekt funktioniert. InspectWP prüft mehrere HTTPS-bezogene Aspekte:

• SSL/TLS-Erkennung: Bestätigt, dass deine Seite über HTTPS ausgeliefert wird.
• Mixed Content: Erkennt HTTP-Ressourcen (Bilder, Skripte, Stylesheets), die auf deinen HTTPS-Seiten geladen werden.
• HSTS-Header: Verifiziert, dass der Strict-Transport-Security-Header vorhanden und korrekt konfiguriert ist.
• HTTP-Weiterleitung: Prüft, ob die HTTP-Version deiner Seite korrekt auf HTTPS umleitet.
• Sicherheits-Header: Überprüft andere sicherheitsrelevante Header, die dein HTTPS-Setup ergänzen.

Wenn InspectWP Mixed-Content-Warnungen meldet, nutze die Browser-Konsole, um die spezifischen Ressourcen zu identifizieren, und behebe sie mit den oben beschriebenen Methoden. Führe nach jeder Korrektur einen erneuten Scan durch, bis der Bericht sauber zurückkommt.