--- title: "WordPress auf HTTPS umstellen: Adressen, Weiterleitung und Mixed Content beheben" date: 2026-09-30T21:27:06+02:00 modified: 2026-11-10T17:20:02+01:00 category: wordpress type: how_to author: Marcel Schönfelder canonical: https://s-edv.com/anleitungen/wordpress-https-umstellen-ssl-mixed-content-beheben keywords: - WordPress - HTTPS - SSL - Mixed Content - Sicherheit reading_time: 9 --- # 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. **Kurzfassung:** Prüfen Sie zuerst, ob die Website unter `https://` mit gültigem Zertifikat erreichbar ist. Stellen Sie dann unter *Einstellungen > Allgemein* beide Adressen auf `https://` um oder nutzen Sie die Schaltfläche im Website-Zustand. Ersetzen Sie alte `http://`-Links in der Datenbank mit `wp search-replace`, ohne die Spalte `guid`. Leiten Sie HTTP per `.htaccess` oder Server-Konfiguration mit 301 auf HTTPS um. Suchen Sie danach im Quelltext nach verbliebenen `http://`-Quellen, die WordPress nicht selbst ersetzen kann. ## Voraussetzungen - [ ] **WordPress:** eine aktuelle Installation, getestet mit WordPress 7.1.2 in deutscher Sprache. Im beschriebenen Beispiel läuft das Update auf WordPress 7.1.3 ohne Fehler und ohne Datenbank-Update. `wp search-replace` mit `--dry-run` und `wp option get siteurl` arbeiten danach wie beschrieben. 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: ```bash $ 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. > **Prüfen:** 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: ```bash $ 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. > **Prüfen:** `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: ```bash $ wp search-replace 'http://www.example.de' 'https://www.example.de' --skip-columns=guid --dry-run --report-changed-only ``` Im Labor zeigte der Probelauf: ```plaintext 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. > **Prüfen:** `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`: ```apache # BEGIN HTTPS-Weiterleitung RewriteEngine On RewriteCond %{HTTPS} off RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] # 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: Datei: `wp-config.php` ```php define( 'FORCE_SSL_ADMIN', true ); ``` > **Prüfen:** `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: ```bash $ 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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=artikel&utm_campaign=45) übernimmt Updates von WordPress, Plugins und Themes, wöchentliche Backups auf externen Speicher und die Einrichtung und Wartung der Firewall. > **Prüfen:** 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](https://s-edv.com/anleitungen/wordpress-sicherheitsheader-csp-hsts-x-frame-options). ### 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](https://s-edv.com/anleitungen/lets-encrypt-certbot-tls-zertifikate). ## 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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=fazit&utm_campaign=45). ## Weiterführende Anleitungen und Quellen - [WordPress-Sicherheitsheader setzen: CSP, HSTS und X-Frame-Options](https://s-edv.com/anleitungen/wordpress-sicherheitsheader-csp-hsts-x-frame-options) - [Let's Encrypt mit certbot: TLS-Zertifikate ohne Reverse-Proxy](https://s-edv.com/anleitungen/lets-encrypt-certbot-tls-zertifikate) - [Let's-Encrypt-SSL im netcup Webhosting einrichten](https://s-edv.com/anleitungen/netcup-webhosting-lets-encrypt-ssl-wcp-plesk-einrichten) - [WordPress Advanced Administration: HTTPS](https://developer.wordpress.org/advanced-administration/security/https/) - [WordPress Developer Reference: wp_update_urls_to_https()](https://developer.wordpress.org/reference/functions/wp_update_urls_to_https/) - [WP-CLI-Handbuch: wp search-replace](https://developer.wordpress.org/cli/commands/search-replace/)