HTTP auf HTTPS umleiten in WordPress

Deine WordPress-Seite von HTTP auf HTTPS umzustellen ist laengst keine Option mehr. Browser kennzeichnen HTTP-Seiten als "Nicht sicher", Google nutzt HTTPS als Ranking-Signal, und die Daten deiner Besucher werden ohne Verschluesselung im Klartext uebertragen. 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 ueber die reine Sicherheit hinaus wichtig ist

Der offensichtliche Grund fuer HTTPS ist Verschluesselung. Ohne sie kann alles zwischen dem Browser deines Besuchers und deinem Server (Formular-Eingaben, Login-Daten, Cookies, persoenliche Daten) von jedem im selben Netzwerk abgefangen werden. Aber HTTPS ist aus mehreren weiteren Gruenden wichtig, die den Erfolg deiner Seite direkt beeinflussen:

• SEO-Ranking-Faktor: Google hat im August 2014 bestaetigt, dass HTTPS ein Ranking-Signal ist. Obwohl es ein leichtes Signal ist, wird bei ansonsten gleichen Bedingungen die HTTPS-Version einer Seite hoeher ranken als die HTTP-Version. In umkaempften Nischen zaehlt jedes Signal.
• Browser-Warnungen: Chrome, Firefox, Safari und Edge zeigen alle "Nicht sicher"-Warnungen fuer HTTP-Seiten an, besonders bei solchen mit Formulareingaben. Das untergaebt das Vertrauen der Besucher und erhoeht die Absprungrate. Chrome hat diese Warnungen seit Chrome 68 (Juli 2018) schrittweise deutlicher gemacht.
• HTTP/2- und HTTP/3-Unterstuetzung: Moderne Protokolle wie HTTP/2 und HTTP/3, die die Ladegeschwindigkeit durch Multiplexing und Header-Komprimierung drastisch verbessern, erfordern in der Praxis HTTPS. Alle grossen Browser unterstuetzen HTTP/2 nur ueber 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 darueber, 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 hinzufuegen"-Prompt erfordern HTTPS.

Kostenloses SSL-Zertifikat mit Let's Encrypt erhalten

Du musst nicht fuer ein SSL-Zertifikat bezahlen. Let's Encrypt stellt kostenlose, automatisierte, Domain-validierte (DV) Zertifikate bereit, denen alle grossen 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

# Fuer Apache
sudo apt install python3-certbot-apache
sudo certbot --apache -d example.com -d www.example.com

# Fuer Nginx
sudo apt install python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

Certbot konfiguriert deinen Webserver automatisch fuer die Nutzung des Zertifikats und richtet einen Cron-Job fuer die automatische Verlaengerung ein. Let's-Encrypt-Zertifikate sind 90 Tage gueltig, aber der Auto-Renewal-Prozess handhabt das transparent. So ueberpruefst du, ob die automatische Verlaengerung funktioniert:

# Verlaengerungsprozess testen (verlaengert nicht tatsaechlich)
sudo certbot renew --dry-run

# Verlaengerungs-Timer pruefen
sudo systemctl status certbot.timer

Wenn dein Hosting-Anbieter Ein-Klick-SSL ueber 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): Aendere http://example.com zu https://example.com
• Website-Adresse (URL): Aendere 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 Gruenden: sie ist schneller, weil WordPress nicht geladen werden muss, und sie stellt sicher, dass alle Anfragen (einschliesslich statischer Dateien, Bilder und API-Aufrufe) umgeleitet werden, nicht nur WordPress-verarbeitete URLs.

Apache (.htaccess)

Fuege 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 (temporaere Weiterleitung), weil Suchmaschinen die Link-Autoritaet nicht auf die neue URL uebertragen werden.

Nginx

Erstelle in deiner Nginx-Konfiguration einen separaten Server-Block fuer 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

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

// SSL fuer 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 ueber HTTP aufzurufen.

Redirect-Loops hinter Load Balancern und Reverse Proxies beheben

Das ist eines der haeufigsten 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 zurueck, und du landest in einem endlosen Redirect-Loop. Der Browser zeigt "ERR_TOO_MANY_REDIRECTS."

Die Loesung ist die oben gezeigte X-Forwarded-Proto-Header-Pruefung. Der Proxy fuegt diesen Header hinzu, um deinem Server mitzuteilen, welches Protokoll die urspruengliche Anfrage verwendet hat. Wenn WordPress sieht, dass das weitergeleitete Protokoll HTTPS ist, behandelt es die Verbindung als sicher und loest keine Weiterleitung aus.

Wenn die Standard-Header-Pruefung nicht funktioniert, verwendet dein Proxy moeglicherweise einen anderen Header. Frage bei deinem Hosting-Anbieter nach. Gaengige Variationen sind:

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

// Fuer 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 enthaelt hartcodierte HTTP-URLs in Beitragsinhalten, Widget-Einstellungen, Theme-Optionen und serialisierten Daten. Du musst sie alle durch HTTPS-Versionen ersetzen. Das beste Werkzeug dafuer ist der search-replace-Befehl von WP-CLI:

# Zuerst einen Dry-Run durchfuehren, um zu sehen, was sich aendern wuerde
wp search-replace 'http://example.com' 'https://example.com' --all-tables --dry-run

# Wenn der Dry-Run gut aussieht, die tatsaechliche Ersetzung durchfuehren
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 tatsaechlich etwas zu aendern. Ueberpruefen die Ausgabe, bevor du die echte Ersetzung durchfuehrst. 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 durchzufuehren, wirst du serialisierte Arrays beschaedigen, weil die Stringlaengen-Werte nicht mehr uebereinstimmen. Fuehre niemals eine rohe SQL-REPLACE()-Abfrage fuer diesen Zweck aus.

Mixed-Content-Probleme beheben

Mixed Content tritt auf, wenn deine HTTPS-Seite Ressourcen (Bilder, Skripte, Stylesheets, Iframes) ueber HTTP laedt. Browser blockieren gemischte aktive Inhalte (Skripte, Stylesheets) vollstaendig und warnen moeglicherweise vor gemischten passiven Inhalten (Bilder). Das fuehrt zu defekter Funktionalitaet oder gelben Warnsymbolen in der Adressleiste.

So findest du Mixed-Content-Probleme:

1. Browser-Konsole: Oeffne 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: Fuehre einen Scan durch und pruefe 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.

Haeufige 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. Fuer hartnaekkige Faelle pruefe 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 laedt, die mit deinem Page Builder erstellt wurden.
• Externe Ressourcen: Wenn du Schriftarten, Skripte oder Bilder von externen Domains ueber HTTP laedt, aktualisiere diese URLs. Die meisten CDNs und Schriftarten-Dienste (Google Fonts, cdnjs usw.) unterstuetzen HTTPS.

Really Simple SSL als Alternative verwenden

Wenn dir der manuelle Ansatz zu aufwendig erscheint, automatisiert das Really Simple SSL Plugin den Grossteil 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 moeglich) 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 hinzufuegt. Es ist besser, die Ursachen zu beheben (Datenbank-URLs, hartcodierte Referenzen) und dann das Plugin zu entfernen. Betrachte es als nuetzliche Bruecke waehrend der Migration, nicht als permanente Loesung.

Schritt 5: HSTS-Header hinzufuegen

HTTP Strict Transport Security (HSTS) teilt Browsern mit, fuer deine Domain immer HTTPS zu verwenden, auch wenn der Nutzer http:// in die Adressleiste tippt. Nachdem du bestaetigt hast, dass HTTPS auf deiner Seite korrekt funktioniert (kein Mixed Content, keine Redirect-Loops), fuege 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 fuer 12 Monate zu speichern. Beginne mit einem kuerzeren Wert wie max-age=86400 (ein Tag) waehrend des Testens und erhoehe ihn, sobald du sicher bist, dass alles funktioniert. Die Direktive includeSubDomains erweitert die Richtlinie auf alle Subdomains. Fuege 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 zusaetzliche Komplexitaetsebene:

• Cloudflare Flexible SSL: Der Traffic ist zwischen dem Besucher und Cloudflare verschluesselt, aber die Verbindung zwischen Cloudflare und deinem Server ist einfaches HTTP. Das ist am einfachsten einzurichten (kein SSL-Zertifikat auf deinem Server noetig), bietet aber unvollstaendige Sicherheit. Daten zwischen Cloudflare und deinem Server sind unverschluesselt.
• Cloudflare Full SSL: Der Traffic ist auf beiden Seiten verschluesselt, 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 verschluesselt und Cloudflare verifiziert das Zertifikat deines Servers. Verwende ein gueltiges Let's-Encrypt-Zertifikat oder ein Cloudflare-Origin-Zertifikat.

Wenn du von Flexible auf Full (Strict) wechselst, stelle sicher, dass dein Server zuerst ein gueltiges 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 durchfuehrt. Das ist schneller als eine Weiterleitung auf deinem Origin-Server, weil der Besucher deinen Server fuer die HTTP-Anfrage nie erreicht.

SSL-Zertifikat-Ablauf und automatische Verlaengerung pruefen

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 ueberwachst du dein Zertifikat:

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

# Tage bis zum Ablauf pruefen
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 Verlaengerung automatisch konfiguriert sein. Aber verifiziere, dass sie tatsaechlich funktioniert, indem du die Certbot-Verlaengerungs-Logs pruefst:

# Certbot-Verlaengerungs-Log pruefen
cat /var/log/letsencrypt/letsencrypt.log | tail -20

# Alle Zertifikate und ihre Ablaufdaten auflisten
sudo certbot certificates

Fuer Produktionsseiten richte ein Monitoring ein, das dich warnt, wenn dein Zertifikat sich dem Ablauf naehert. Dienste wie UptimeRobot, StatusCake oder sogar ein einfacher Cron-Job, der das Zertifikatsdatum prueft, koennen dich vor unerwarteter Downtime bewahren.

HTTPS-Setup mit InspectWP ueberpruefen

Nach Abschluss der Migration fuehre einen InspectWP-Scan durch, um zu ueberpruefen, dass alles korrekt funktioniert. InspectWP prueft mehrere HTTPS-bezogene Aspekte:

• SSL/TLS-Erkennung: Bestaetigt, dass deine Seite ueber 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: Prueft, ob die HTTP-Version deiner Seite korrekt auf HTTPS umleitet.
• Sicherheits-Header: Ueberpruefen andere sicherheitsrelevante Header, die dein HTTPS-Setup ergaenzen.

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