WordPress: Unsichere HTTP-Inhalte auf einer HTTPS-Seite finden

Eine WordPress-Seite kann mit https:// beginnen und trotzdem im Browser als nicht vollständig sicher erscheinen. Der häufigste Grund ist Mixed Content: Das HTML wird verschlüsselt über HTTPS geladen, einzelne Bilder, CSS-Dateien, Skripte, Fonts oder andere Ressourcen werden aber weiterhin über unverschlüsseltes HTTP angefordert.

Im ursprünglichen Verlauf war genau das Problem: Die Adresszeile zeigte HTTPS, der Browser meldete trotzdem eine unsichere Verbindung. Die richtige Lösung ist nicht, wahllos jedes http:// in der Datenbank zu ersetzen, sondern zuerst herauszufinden, welche konkrete Ressource noch unsicher geladen wird.

1. Warum HTTPS allein nicht genügt

Ein gültiges TLS-Zertifikat schützt die Verbindung zur Hauptseite. Wenn die Seite danach beispielsweise dieses Bild lädt:

http://deinedomain.de/wp-content/uploads/bild.jpg

entsteht eine gemischte Verbindung.

Dasselbe gilt für:

  • JavaScript
  • CSS
  • Webfonts
  • iframes
  • Audio/Video
  • Hintergrundbilder in Stylesheets
  • externe Tracking- oder Widget-Skripte

2. Passive und aktive Mixed-Content-Ressourcen

Browser behandeln verschiedene Ressourcentypen unterschiedlich. Bilder können je nach Browser automatisch auf HTTPS hochgestuft oder mit Warnung geladen werden. Unsichere aktive Inhalte wie JavaScript werden häufig komplett blockiert.

Deshalb kann die Seite gleichzeitig „fast normal“ aussehen und trotzdem Funktionen verlieren.

3. Die Browser-Konsole ist der beste erste Schritt

Öffne die betroffene Seite und anschließend die Entwicklerwerkzeuge:

  • Chrome/Edge: F12 oder Rechtsklick → Untersuchen
  • Firefox: F12

Wechsle zum Bereich Console/Konsole. Mixed-Content-Warnungen nennen meistens direkt die problematische URL.

Typische Meldung:

Mixed Content: The page was loaded over HTTPS, but requested an insecure resource 'http://...'

Diese URL ist dein konkreter Ansatzpunkt.

4. Netzwerk-Tab zusätzlich verwenden

Im Tab Network/Netzwerk kannst du die Seite neu laden und nach http:// beziehungsweise nach blockierten Anfragen suchen.

Besonders hilfreich sind die Spalten:

  • Request URL
  • Type
  • Status
  • Initiator

Der Initiator zeigt oft, welche CSS-Datei oder welches Skript die unsichere Ressource anfordert.

5. Security-Panel prüfen

Chromium-basierte Browser besitzen zusätzlich einen Security-Bereich. Dort lässt sich erkennen, ob Zertifikat und Hauptverbindung korrekt sind und ob unsichere Unterressourcen beteiligt sind.

Das ist wichtig, weil nicht jede „Nicht sicher“-Anzeige automatisch Mixed Content bedeutet. Auch ein abgelaufenes oder falsch ausgestelltes Zertifikat kann Ursache sein.

6. Im Seitenquelltext nach http:// suchen

Mit „Seitenquelltext anzeigen“ und Browser-Suche nach:

http://

findest du viele hart codierte URLs direkt.

Aber Achtung: Nicht jeder http://-Text ist problematisch. Ein Link zu einer externen Informationsseite verursacht nicht automatisch Mixed Content. Kritisch sind Ressourcen, die der Browser in die HTTPS-Seite einbettet oder lädt.

7. Typische WordPress-Ursache: alte Domain-URLs in Inhalten

Nach einer Umstellung von HTTP auf HTTPS können alte Beiträge weiterhin vollständige URLs enthalten:

http://example.de/wp-content/uploads/2024/03/bild.jpg

Das passiert besonders bei:

  • älteren Classic-Editor-Beiträgen,
  • manuell eingefügtem HTML,
  • alten Page-Builder-Daten,
  • Widgets und Custom Fields.

8. WordPress-Adresse und Website-Adresse prüfen

Unter:

Einstellungen → Allgemein

sollten WordPress-Adresse (URL) und Website-Adresse (URL) auf der korrekten HTTPS-Adresse stehen.

Wenn dort noch HTTP eingetragen ist, können Plugins und WordPress selbst weiterhin HTTP-Links erzeugen.

9. Bei Proxy/CDN-Szenarien besonders aufpassen

Wenn Cloudflare, Reverse Proxy oder Load Balancer vor WordPress sitzt, kann WordPress intern glauben, die Anfrage sei HTTP, obwohl der Besucher HTTPS verwendet.

Dann entstehen gelegentlich falsche URLs oder Redirect-Schleifen. In diesem Fall muss die HTTPS-Erkennung des Servers beziehungsweise Proxys korrekt konfiguriert werden – nicht nur einzelne Datenbank-URLs ersetzt werden.

10. Theme und Custom CSS durchsuchen

Unsichere URLs stecken häufig in CSS-Hintergrundbildern:

background-image: url('data:image/svg+xml,%3Csvg%20xmlns=%22http://www.w3.org/2000/svg%22%20viewBox=%220%200%20%20%22%3E%3C/svg%3E#}https://example.de/wp-content/uploads/hero.jpg');

Prüfe:

  • „Zusätzliches CSS“
  • Child-Theme-Dateien
  • CSS-Snippet-Plugins
  • GenerateBlocks Custom CSS / Styles
  • Customizer-Einstellungen

11. Externe Fonts und Skripte

Ältere Themes können beispielsweise Google Fonts noch mit einer festen HTTP-Adresse laden. Moderne Ressourcen sollten über HTTPS beziehungsweise protokollrelative oder lokale Einbindungen geladen werden.

Bei einem externen Anbieter musst du zuerst prüfen, ob er überhaupt HTTPS unterstützt. Ein blindes Ersetzen von:

http://fremder-server.example/datei.js

durch:

https://fremder-server.example/datei.js

hilft nur, wenn die Ressource dort tatsächlich per HTTPS existiert.

12. Datenbank sicher durchsuchen

Wenn viele alte URLs vorhanden sind, ist eine WordPress-aware Suche sinnvoll. WP-CLI besitzt dafür search-replace und verarbeitet laut aktueller WordPress-Dokumentation auch serialisierte PHP-Daten korrekt.

Vor jeder Änderung zuerst nur testen:

wp search-replace 'http://example.de' 'https://example.de' --all-tables-with-prefix --dry-run

Mit --dry-run wird nichts gespeichert. Du erhältst nur einen Bericht über mögliche Treffer.

13. Warum rohe SQL-Ersetzungen riskant sind

Viele WordPress-Optionen und Plugin-Daten liegen serialisiert vor. Eine einfache SQL-Anweisung wie:

UPDATE wp_options SET option_value = REPLACE(...)

kann Längenangaben innerhalb serialisierter Daten zerstören.

Deshalb sollte für globale WordPress-Suchen ein Werkzeug verwendet werden, das Serialisierung versteht.

14. Vor einem echten Search-and-Replace Backup erstellen

Ein Live-Suchlauf kann Tausende Datenbankfelder verändern. Deshalb:

  1. vollständiges Datenbank-Backup erstellen,
  2. --dry-run ausführen,
  3. Trefferzahlen prüfen,
  4. nur die eigene alte Domain ersetzen,
  5. anschließend Frontend und Backend testen.

15. Nicht jedes http:// global ersetzen

Eine Suche nach:

http://

und Ersetzung durch HTTPS über die komplette Datenbank ist zu grob. Darin können vorkommen:

  • externe Links, die kein HTTPS besitzen,
  • API-Endpunkte,
  • Dokumentationstexte,
  • Beispielcode,
  • interne technische Werte.

Ersetze deshalb bevorzugt die konkrete eigene alte Domain.

16. Bilder in der Mediathek

Ein Bild muss nicht neu hochgeladen werden, nur weil sein alter Link HTTP enthält. Wenn dieselbe Datei unter der HTTPS-Domain erreichbar ist, genügt die Korrektur der gespeicherten URL beziehungsweise des Inhalts.

Prüfe bei einzelnen problematischen Bildern zuerst, wo die URL gespeichert wird.

17. Widgets und Footer-Inhalte

Besonders alte Text-/HTML-Widgets enthalten gerne harte Links. Wenn Mixed Content auf jeder Seite erscheint, solltest du globale Bereiche prüfen:

  • Header
  • Footer
  • Sidebar
  • Cookie-/Consent-Banner
  • Bewertungswidgets
  • globale GeneratePress Elements

18. Page Builder und Block-Metadaten

Elementor, Bricks und andere Builder speichern Layoutdaten teilweise in Post Meta oder eigenen Strukturen. Eine normale Suche im sichtbaren Post-Content findet solche URLs nicht unbedingt.

Verwende bei Builder-Seiten deren eigene Migration-/URL-Replacement-Werkzeuge beziehungsweise einen serialisierungsfähigen WordPress-Search-Replace.

19. Plugin-Einstellungen

Ein Plugin kann eine alte Basis-URL in seinen Optionen gespeichert haben. Besonders typische Kandidaten:

  • Slider
  • Galerien
  • Tracking
  • Cookie-Tools
  • externe Widgets
  • alte CDN-Einstellungen

Wenn die Konsole eine bestimmte Datei nennt, lässt sich anhand des Pfades oft erkennen, welches Plugin beteiligt ist.

20. Really Simple SSL / Really Simple Security

Plugins aus dieser Familie können bei HTTPS-Migrationen helfen und bestimmte Mixed-Content-Probleme abfangen. Sie ersetzen aber nicht die Diagnose. Ein Runtime-Fixer kann Symptome beheben, während die Datenbank weiterhin alte URLs enthält.

Für eine langfristig saubere Installation ist es besser, die eigentliche Quelle der HTTP-Adresse zu korrigieren.

21. Browsercache und WordPress-Cache

Nach einer Korrektur kann der Browser noch alte HTML-, CSS- oder JavaScript-Dateien besitzen. Leere deshalb bei Bedarf:

  • WordPress-/Caching-Plugin,
  • Servercache,
  • CDN-Cache,
  • Browsercache.

Ein privates Browserfenster ist ein schneller Gegencheck.

22. Service Worker und PWA

Wenn die Website als PWA arbeitet, kann ein Service Worker ältere Assets aus seinem eigenen Cache liefern. Dann reicht ein normaler Browser-Refresh möglicherweise nicht. Prüfe im DevTools-Application-Bereich die registrierten Service Worker und Caches.

23. Nach der Korrektur erneut komplett laden

Im Network-Tab sollte „Disable cache“ aktiviert sein, während die Developer Tools geöffnet sind. Lade die Seite anschließend neu und kontrolliere, ob noch HTTP-Unterressourcen erscheinen.

24. Externe Links sind nicht automatisch Mixed Content

Ein normaler Link wie:

<a href="http://example.org">Quelle</a>

macht deine aktuelle Seite nicht zu Mixed Content, weil die fremde Ressource erst nach einem Klick als eigene Seite geladen wird. Trotzdem ist HTTPS bei externen Links vorzuziehen, wenn der Anbieter es unterstützt.

25. Zertifikatsfehler von Mixed Content unterscheiden

Wenn keinerlei HTTP-Unterressource gefunden wird, prüfe das Zertifikat:

  • abgelaufen?
  • richtige Domain?
  • www und non-www beide enthalten?
  • vollständige Zertifikatskette?
  • Systemdatum des Geräts korrekt?

Ein Zertifikatsfehler lässt sich nicht mit Search-and-Replace beheben.

26. Sinnvolle Diagnose-Reihenfolge

  1. Browser-Konsole öffnen.
  2. konkrete unsichere Ressourcen notieren.
  3. Network/Initiator prüfen.
  4. WordPress Home/Site URL kontrollieren.
  5. Beitrag/Seite/Widget/CSS nach der konkreten URL durchsuchen.
  6. bei vielen eigenen alten Domain-URLs WP-CLI search-replace --dry-run nutzen.
  7. Backup erstellen.
  8. gezielte Korrektur durchführen.
  9. alle Caches leeren.
  10. im privaten Fenster erneut prüfen.

27. Beispiel für eine sichere Domain-Korrektur

Erst nur Bericht:

wp search-replace 'http://www.example.de' 'https://example.de' --all-tables-with-prefix --dry-run

Wenn die Treffer plausibel sind und ein Backup existiert, kann derselbe Befehl anschließend ohne --dry-run ausgeführt werden.

Bei einer www-/non-www-Umstellung solltest du vorher sicherstellen, dass die gewählte Zieldomain wirklich die kanonische Hauptdomain ist.

Fazit

Eine HTTPS-Seite kann wegen einzelner HTTP-Unterressourcen weiterhin als unsicher erscheinen. Die Browser-Konsole und der Network-Tab zeigen normalerweise direkt, welche Datei betroffen ist. Korrigiere anschließend gezielt die Quelle – im Beitrag, CSS, Plugin oder bei vielen alten Domain-URLs mit einem serialisierungsfähigen WordPress-Search-and-Replace. Eine globale blinde Ersetzung aller HTTP-Adressen ist dagegen unnötig riskant.

Aktuell geprüft

WP-CLI dokumentiert weiterhin, dass wp search-replace serialisierte Daten verarbeitet und mit --dry-run einen Testlauf ohne Speicherung durchführen kann.