WordPress auf HTTPS umstellen: Adressen, Weiterleitung und Mixed Content beheben

Ein Zertifikat ist schnell eingerichtet, doch damit ist eine WordPress-Website noch nicht vollständig auf HTTPS umgestellt. WordPress speichert seine eigene Adresse in der Datenbank, Beiträge enthalten Bildadressen mit http://, und Themes oder Plugins laden Skripte von fremden Servern. Das Ergebnis sind Weiterleitungsschleifen, fehlende Bilder oder die Browsermeldung „nicht sicher“ trotz gültigem Zertifikat. Diese Anleitung zeigt die Umstellung in der richtigen Reihenfolge: Zertifikat prüfen, Adressen umstellen, alte Links in der Datenbank ersetzen, HTTP dauerhaft umleiten und gemischte Inhalte („Mixed Content“) finden. Alle Schritte wurden im Labor mit WordPress 7.1.2 auf Apache geprüft.

Voraussetzungen

• WordPress: eine aktuelle Installation, getestet mit WordPress 7.1.2 in deutscher Sprache. Die automatische HTTPS-Umstellung im Website-Zustand gibt es seit WordPress 5.7.
• PHP: die Version Ihres Hostings, im Labor PHP 8.4.
• Zertifikat: ein gültiges TLS-Zertifikat für alle genutzten Hostnamen, etwa example.de und www.example.de. Bei den meisten Hostern ist ein Let's-Encrypt-Zertifikat mit wenigen Klicks aktiviert.
• Zugriff: Administrator im Backend, SFTP oder SSH für die .htaccess bzw. die Server-Konfiguration. WP-CLI (getestet mit 2.12.0) für das Ersetzen der Links.
• Backup: eine aktuelle Sicherung von Datenbank und Dateien. Das Ersetzen von Adressen in der Datenbank lässt sich ohne Sicherung nicht rückgängig machen.

Schritt 1: Zertifikat und HTTPS-Erreichbarkeit prüfen

Stellen Sie WordPress erst um, wenn die Website unter https:// bereits funktioniert. Andernfalls sperren Sie sich aus dem Backend aus, denn WordPress leitet nach der Umstellung auf die neue Adresse um. Prüfen Sie von Ihrem Rechner aus:

curl -sI https://www.example.de/ | head -3
curl -sI https://example.de/ | head -3

Beide Aufrufe sollten eine Antwort wie HTTP/2 200 oder eine Weiterleitung liefern, keinen Zertifikatsfehler. Meldet curl einen Fehler wie „SSL certificate problem“, fehlt das Zertifikat für diesen Hostnamen oder die Zwischenzertifikate sind nicht eingebunden. Das klären Sie mit Ihrem Hoster oder in der Verwaltung des Servers.

WordPress prüft das ebenfalls. Unter Werkzeuge > Website-Zustand erscheint ein Hinweis, dass die Website kein HTTPS verwendet, solange die Umstellung aussteht. Im Labor mit einem selbst signierten Zertifikat hielt WordPress die HTTPS-Unterstützung für nicht gegeben und speicherte intern den Fehler „Die SSL-Überprüfung ist fehlgeschlagen.“ In diesem Zustand bietet der Website-Zustand keine Schaltfläche zur Umstellung an, sondern rät, mit dem Hoster zu sprechen. Mit einem gültigen, öffentlich vertrauenswürdigen Zertifikat verschwindet dieser Fehler.

Verifizieren: Die Startseite lädt im Browser unter https:// ohne Warnung, und curl -sI meldet keinen Zertifikatsfehler.

Schritt 2: WordPress-Adressen auf HTTPS umstellen

WordPress kennt zwei Adressen: die WordPress-Adresse, unter der die Programmdateien liegen, und die Website-Adresse, die Besucher aufrufen. Beide stehen unter Einstellungen > Allgemein als „WordPress-Adresse (URL)“ und „Website-Adresse (URL)“. Ändern Sie dort bei beiden nur http:// in https:// und speichern Sie. Danach meldet WordPress Sie ab, und Sie melden sich unter der neuen Adresse wieder an.

Ist die HTTPS-Unterstützung erkannt, bietet Werkzeuge > Website-Zustand dafür die Schaltfläche „Website für HTTPS aktualisieren“. Sie führt die Funktion wp_update_urls_to_https() aus, die beide Adressen umstellt und die Änderung selbstständig zurücknimmt, falls WordPress danach kein HTTPS erkennt. Per WP-CLI erreichen Sie dasselbe mit zwei Befehlen:

wp option update home 'https://www.example.de'
wp option update siteurl 'https://www.example.de'

Sind die Felder im Backend ausgegraut, stehen die Adressen als Konstanten WP_HOME und WP_SITEURL in der wp-config.php. Dann ändern Sie sie dort, denn Konstanten haben Vorrang vor der Datenbank.

Bei einer bestehenden Website mit Inhalten merkt sich WordPress nach dieser Umstellung, dass eine Migration nötig ist (Option https_migration_required). Solange diese gesetzt ist, ersetzt WordPress bei der Ausgabe alte http://-Links auf die eigene Domain automatisch durch https://. Im Labor wurden ein Bild und ein Link mit http:// im Beitragsinhalt ohne weiteres Zutun als https:// ausgeliefert, obwohl in der Datenbank weiter http:// stand.

Verifizieren: wp option get home und wp option get siteurl liefern die https://-Adresse, und der Website-Zustand meldet eine aktive HTTPS-Verbindung.

Schritt 3: Alte Links in der Datenbank ersetzen

Die automatische Ersetzung aus Schritt 2 wirkt nur bei der Ausgabe, nur für die eigene Domain und nur, solange beide Adressen denselben Hostnamen verwenden. Feeds, Exporte, die REST-API für externe Dienste und Plugins, die Daten direkt aus der Datenbank lesen, sehen weiter die alten Adressen. Sauberer ist es, die Links dauerhaft in der Datenbank zu ersetzen. Nutzen Sie dafür wp search-replace, denn es behandelt serialisierte Daten korrekt, ein SQL-REPLACE dagegen beschädigt sie. Lassen Sie die Spalte guid aus, die WordPress-Dokumentation zum Umzug verbietet deren Änderung. Führen Sie zuerst einen Probelauf aus:

wp search-replace 'http://www.example.de' 'https://www.example.de' --skip-columns=guid --dry-run --report-changed-only

Im Labor zeigte der Probelauf:

Table	Column	Replacements	Type
wp_posts	post_content	3	SQL
wp_users	user_url	1	SQL
Success: 4 replacements to be made.

Sieht die Liste plausibel aus, führen Sie den Befehl ohne --dry-run aus. Wiederholen Sie ihn für jede Schreibweise, die Ihre Website früher genutzt hat, etwa ohne www. Ohne SSH bieten Plugins für Suchen und Ersetzen dieselbe Funktion im Backend. Achten Sie dort auf eine Option für serialisierte Daten und nutzen Sie ebenfalls zuerst einen Probelauf.

Verifizieren: wp db query "SELECT COUNT(*) FROM wp_posts WHERE post_content LIKE '%http://www.example.de%'" gibt 0 aus. Passen Sie das Tabellenpräfix an, falls es nicht wp_ lautet.

Schritt 4: HTTP dauerhaft auf HTTPS umleiten

WordPress leitet nur Aufrufe um, die es selbst verarbeitet. Direkte Aufrufe von Bildern, PDFs oder CSS-Dateien unter http:// liefert der Webserver weiter unverschlüsselt aus. Eine Umleitung auf Serverebene erfasst alle Aufrufe. Auf Apache setzen Sie diese Zeilen an den Anfang der .htaccess im WordPress-Verzeichnis, vor den Block # BEGIN WordPress:

# BEGIN HTTPS-Weiterleitung
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>
# END HTTPS-Weiterleitung

Schreiben Sie die Regel nicht zwischen # BEGIN WordPress und # END WordPress, diesen Bereich überschreibt WordPress beim Speichern der Permalinks. Der Statuscode 301 signalisiert Suchmaschinen eine dauerhafte Umleitung. Auf nginx gehört die Umleitung in den Server-Block für Port 80, etwa mit return 301 https://$host$request_uri;. Liegt ein Reverse-Proxy oder ein CDN vor dem Webserver, kommt jede Anfrage dort als HTTP an, und diese Regel erzeugt eine Weiterleitungsschleife. Richten Sie die Umleitung dann im Proxy ein und lesen Sie in der WordPress-Dokumentation zu HTTPS nach, wie WordPress den Header X-Forwarded-Proto auswertet.

Zusätzlich erzwingt die Konstante FORCE_SSL_ADMIN in der wp-config.php HTTPS für Anmeldung und Backend. Laut WordPress-Dokumentation muss sie in der wp-config.php stehen, ein Plugin reicht nicht:

define( 'FORCE_SSL_ADMIN', true );

Verifizieren: curl -sI "http://www.example.de/?p=4&x=1" antwortet mit HTTP/1.1 301 Moved Permanently und Location: https://www.example.de/?p=4&x=1. Im Labor blieben Pfad und Parameter so erhalten, auch /wp-admin/ wurde auf HTTPS umgeleitet.

Schritt 5: Mixed Content finden und beheben

Von „Mixed Content“ spricht man, wenn eine HTTPS-Seite Inhalte über http:// nachlädt. Browser blockieren solche Skripte und Stylesheets, Bilder laden sie teils mit Warnung. Die Folge sind fehlende Funktionen, zerschossene Layouts oder das fehlende Schloss-Symbol. Die automatische Ersetzung von WordPress hilft hier nur bei Links auf die eigene Domain. Im Labor blieb ein Skript von einem fremden Server mit http:// im ausgelieferten Quelltext unverändert stehen.

Einen ersten Überblick liefert eine Suche im Quelltext der wichtigsten Seiten:

curl -s https://www.example.de/ | grep -oE '(src|href)="http://[^"]+"' | sort -u

Die Ausgabe listet alle Quellen, die noch http:// verwenden. Normale Links (href auf andere Websites) sind unkritisch, entscheidend sind Bilder, Skripte, Stylesheets, Schriften und eingebettete Inhalte. Genauer arbeiten die Entwicklerwerkzeuge des Browsers: Öffnen Sie die Konsole (F12) und laden Sie die Seite neu. Blockierte Inhalte meldet der Browser dort mit dem Hinweis auf „Mixed Content“ und der genauen Adresse.

Die Ursache finden Sie meist an einer dieser Stellen: fest eingetragene Adressen in Theme-Einstellungen, Widgets oder Page-Builder-Daten, Tracking- oder Chat-Skripte mit http:// im Einbettungscode, sehr alte Plugins. Ersetzen Sie die Adresse durch https://, sofern der fremde Dienst HTTPS anbietet, andernfalls entfernen Sie die Einbindung. Stehen die Adressen in der Datenbank, hilft ein weiterer Lauf von wp search-replace gezielt für die fremde Domain, wieder zuerst mit --dry-run.

Ein Zertifikat läuft ab, Plugins bringen neue Einbindungen mit, und der Hoster ändert Einstellungen. HTTPS gehört damit zur laufenden Pflege der Website wie Updates und Backups. Wer diese Aufgaben nicht selbst im Blick behalten möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de übernimmt Updates von WordPress, Plugins und Themes, wöchentliche Backups auf externen Speicher und die Einrichtung und Wartung der Firewall.

Verifizieren: Die Suche per curl findet keine src-Einträge mit http:// mehr, die Browser-Konsole zeigt keine Mixed-Content-Meldungen, und der Browser zeigt das Schloss-Symbol ohne Einschränkung.

Typische Fehler

• Weiterleitungsschleife („zu oft umgeleitet“): Die Website liegt hinter einem Proxy oder CDN, der die Verbindung zum Server per HTTP herstellt. WordPress und die .htaccess-Regel sehen dann nie HTTPS. Umleitung im Proxy einrichten und X-Forwarded-Proto auswerten, siehe Schritt 4.
• Nach der Umstellung kein Zugang zum Backend: Die Adressen wurden umgestellt, bevor HTTPS funktionierte. Per WP-CLI mit wp option update home und wp option update siteurl auf http:// zurücksetzen oder die Konstanten WP_HOME und WP_SITEURL vorübergehend in der wp-config.php setzen.
• Website-Zustand bietet keine Umstellung an: WordPress hält HTTPS für nicht unterstützt. Im Labor lag das an einem selbst signierten Zertifikat, intern gespeichert als „Die SSL-Überprüfung ist fehlgeschlagen.“ Zertifikat und Zwischenzertifikate prüfen.
• Einzelne Bilder fehlen nach dem Ersetzen: Die Datenbank enthielt eine andere Schreibweise, etwa ohne www. Probelauf mit dieser Schreibweise wiederholen.
• Layout zerschossen, Skripte fehlen: Mixed Content bei Stylesheets oder Skripten. Browser-Konsole prüfen, siehe Schritt 5.

Häufige Fragen

Brauche ich ein Plugin für die HTTPS-Umstellung?

Nein. Seit WordPress 5.7 übernimmt der Kern die Umstellung der Adressen und ersetzt eigene http://-Links bei der Ausgabe. Für das dauerhafte Ersetzen in der Datenbank genügt WP-CLI. Plugins sind nur bequem, wenn Sie keinen Shell-Zugang haben.

Wirkt sich die Umstellung auf Suchmaschinen aus?

Mit einer 301-Weiterleitung von jeder HTTP-Adresse auf die passende HTTPS-Adresse bleiben Links und Lesezeichen gültig. Prüfen Sie danach, ob Sitemap und Canonical-Angaben Ihres SEO-Plugins die neue Adresse verwenden.

Sollte ich HSTS aktivieren?

HSTS weist Browser an, Ihre Domain nur noch per HTTPS aufzurufen. Aktivieren Sie es erst, wenn HTTPS stabil läuft, denn Browser merken sich die Vorgabe für die angegebene Dauer. Details stehen in der Anleitung WordPress-Sicherheitsheader setzen.

Wo bekomme ich ein Zertifikat?

Die meisten Hoster bieten kostenlose Let's-Encrypt-Zertifikate mit automatischer Erneuerung an. Auf eigenen Servern richten Sie es mit certbot ein, siehe Let's Encrypt mit certbot.

Testumfang

Wir haben die HTTPS-Umstellung mit WordPress 7.1.2 auf einem Apache-Testserver durchgespielt, samt Umleitung per .htaccess und Ersetzen der Links in der Datenbank. Auffällig war, dass WordPress beim selbst signierten Zertifikat eine Fehlermeldung zeigt und ein fremdes Skript Mixed Content verursachte.

Setups mit nginx, Reverse Proxy oder CDN sowie die Zertifikatsausstellung beim Hoster haben wir nicht geprüft. Testen Sie die Umstellung deshalb zuerst auf einer Kopie Ihrer Website.

Fazit

Die Umstellung auf HTTPS gelingt in fünf Schritten: Zertifikat prüfen, Adressen umstellen, alte Links in der Datenbank ersetzen, HTTP per 301 umleiten und Mixed Content beseitigen. Die Reihenfolge ist entscheidend, denn wer die Adressen vor einem funktionierenden Zertifikat umstellt, sperrt sich aus. Wenn Sie Updates, Backups und Firewall lieber abgeben, übernimmt das die WordPress-Wartung von Marcel Schönfelder.

Weiterführende Anleitungen und Quellen

• WordPress-Sicherheitsheader setzen: CSP, HSTS und X-Frame-Options
• Let's Encrypt mit certbot: TLS-Zertifikate ohne Reverse-Proxy
• Let's-Encrypt-SSL im netcup Webhosting einrichten
• WordPress Advanced Administration: HTTPS
• WordPress Developer Reference: wp_update_urls_to_https()
• WP-CLI-Handbuch: wp search-replace