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

Eine WordPress-Seite kann vollständig über HTTPS aufgerufen werden und trotzdem unsichere Inhalte enthalten. Dann spricht man von Mixed Content: Die eigentliche Seite lädt verschlüsselt, einzelne Bilder, Skripte, Stylesheets, Fonts oder andere Ressourcen werden aber noch über http:// angefordert.

Im ursprünglichen Gemini-Chat ging es genau um diese Frage: Wo finde ich in WordPress, wo noch HTTP statt HTTPS verwendet wird? Die Antwort ist nicht nur eine einzelne Tabelle oder ein einzelnes Plugin. HTTP-Adressen können an sehr unterschiedlichen Stellen gespeichert sein. Deshalb ist ein systematischer Ablauf sinnvoller als ein blindes Suchen und Ersetzen.

Was bedeutet Mixed Content?

Mixed Content entsteht, wenn eine HTTPS-Seite Ressourcen über unverschlüsseltes HTTP nachlädt. Moderne Browser behandeln das zunehmend streng. Je nach Ressourcentyp wird der Inhalt nur mit Warnung geladen oder direkt blockiert.

Typische Kandidaten sind:

  • Bilder und Logos
  • CSS-Dateien
  • JavaScript-Dateien
  • Webfonts
  • Hintergrundbilder aus Theme- oder Page-Builder-Einstellungen
  • iframes und eingebettete Inhalte
  • hart codierte URLs in Plugins oder Custom CSS

Schritt 1: Fehler direkt im Browser finden

Wenn nur eine bestimmte Seite betroffen ist, beginne im Browser. Öffne die Seite, drücke F12 und öffne die Konsole. Lade die Seite anschließend neu.

Bei echtem Mixed Content zeigt der Browser meist eine Meldung mit der konkret angeforderten HTTP-Adresse. Das ist wertvoller als eine pauschale Datenbanksuche, weil du sofort siehst, welche Ressource auf der aktuellen Seite problematisch ist.

Prüfe zusätzlich den Reiter Network/Netzwerk und filtere nach http. So findest du Ressourcen, die möglicherweise weitergeleitet werden, aber trotzdem unnötig über HTTP angefordert werden.

Schritt 2: WordPress- und Website-Adresse prüfen

Gehe in WordPress zu Einstellungen → Allgemein. Dort sollten sowohl WordPress-Adresse (URL) als auch Website-Adresse (URL) mit https:// beginnen.

Wenn hier noch die alte HTTP-Adresse steht, ist das ein grundlegendes Problem. Bevor du weitere Datenbankeinträge bearbeitest, sollte zuerst diese Basiskonfiguration stimmen.

Wo liegen alte HTTP-Links in der WordPress-Datenbank?

Im Gemini-Chat kam anschließend die Frage: In welcher Tabelle finde ich die Links? Die wichtigsten Tabellen sind:

wp_posts

In wp_posts.post_content liegen Inhalte von Beiträgen, Seiten und bei manchen Buildern auch komplette Layouts. Alte Bild- und Linkadressen aus dem Editor findest du häufig hier.

wp_postmeta

In wp_postmeta.meta_value speichern Plugins und Page Builder zusätzliche Daten. Dort können Hintergrundbilder, Custom Fields, Builder-Daten oder Plugin-Einstellungen mit alten URLs liegen.

wp_options

wp_options enthält zahlreiche Theme- und Plugin-Einstellungen sowie die zentralen WordPress-URLs. Auch Logos, Hintergrundbilder oder Plugin-Konfigurationen können dort gespeichert sein.

wp_comments

Kommentare können ebenfalls alte externe HTTP-Links enthalten. Für Mixed Content sind sie allerdings nur relevant, wenn eine Ressource daraus tatsächlich eingebettet wird.

Wichtig: Das Tabellenpräfix muss nicht wp_ heißen. Viele Installationen verwenden ein anderes Präfix.

Nicht direkt mit SQL ersetzen

Ein einfacher SQL-Befehl wie UPDATE ... REPLACE() wirkt verlockend, kann aber bei serialisierten oder strukturierten Plugin-Daten Schaden verursachen. Deshalb sollte ein WordPress-kompatibles Search-and-Replace-Werkzeug verwendet werden, das serialisierte Daten korrekt behandelt.

Vor jedem echten Ersetzen gilt: Backup erstellen und zuerst einen Testlauf durchführen.

Mit Better Search Replace nach alten Domain-URLs suchen

Eine praktikable Methode ist ein Search-and-Replace-Plugin wie Better Search Replace. Suche nicht pauschal nach jedem http:// im gesamten System, sondern zuerst nach deiner eigenen alten Domain, zum Beispiel:

http://example.de

und ersetze sie gegebenenfalls durch:

https://example.de

Der erste Durchlauf sollte als Dry Run/Testlauf erfolgen. Dadurch siehst du, wie viele Treffer in welchen Tabellen vorhanden sind, ohne bereits Daten zu verändern.

Warum nicht jedes http:// automatisch ersetzen?

Externe Links können weiterhin bewusst HTTP verwenden, weil die Zielseite kein HTTPS unterstützt. Eine globale Ersetzung von http:// zu https:// kann deshalb Links erzeugen, die anschließend gar nicht funktionieren.

Bei der eigenen Domain ist die Ersetzung normalerweise klarer. Bei fremden Domains sollte jede Adresse geprüft werden.

Page Builder und generiertes CSS berücksichtigen

Bei Page Buildern können URLs zusätzlich in generierten CSS-Dateien oder eigenen Datenstrukturen liegen. Nach einer Umstellung von HTTP auf HTTPS reicht die Datenbankkorrektur deshalb manchmal nicht aus.

Je nach verwendetem Builder solltest du danach:

  • generiertes CSS neu erzeugen
  • Builder-Cache leeren
  • WordPress-Cache leeren
  • CDN-Cache leeren
  • Browser mit Hard Reload neu laden

GeneratePress und GenerateBlocks prüfen

Bei GeneratePress/GenerateBlocks liegen problematische URLs häufig in:

  • Container-Hintergrundbildern
  • Global Styles
  • Theme-Einstellungen
  • Custom CSS
  • Elementen/Hooks
  • wiederverwendeten Blöcken oder Patterns

Wenn die Browser-Konsole eine konkrete Bild-URL nennt, suche zuerst genau nach dieser URL oder wenigstens nach dem Dateinamen. Das ist wesentlich effizienter als die komplette Datenbank blind zu durchsuchen.

Theme-Dateien und eigene Snippets nicht vergessen

Wenn die Datenbanksuche keinen Treffer liefert, kann die URL direkt in einer CSS-, JavaScript- oder PHP-Datei stehen. Besonders bei älteren Child Themes oder manuell eingefügten Snippets kommt das vor.

Suche dann nach:

http://

in den eigenen Theme-Dateien beziehungsweise im Snippet-Plugin. Core- und Plugin-Dateien sollte man nicht direkt verändern, weil Änderungen bei Updates überschrieben werden.

Externe Mixed-Content-Ressourcen

Manchmal stammt die problematische HTTP-Adresse gar nicht von deiner Domain. Ein eingebettetes Script, ein altes Tracking-Pixel oder eine externe Schriftdatei kann die Ursache sein.

Prüfe dann zuerst, ob dieselbe Ressource auch über HTTPS erreichbar ist. Wenn ja, ändere die Einbindung. Wenn nein, solltest du die Ressource möglichst ersetzen oder lokal bereitstellen, statt die unsichere Verbindung beizubehalten.

Was ist mit Content-Security-Policy upgrade-insecure-requests?

Im ursprünglichen Gemini-Chat wurde als „Notnagel“ eine Content-Security-Policy mit upgrade-insecure-requests vorgeschlagen. Diese Direktive kann Browser anweisen, HTTP-Anforderungen als HTTPS anzufordern.

Das kann als zusätzliche Schutzschicht sinnvoll sein, ersetzt aber nicht die Ursachenbehebung. Wenn eine externe Ressource kein HTTPS unterstützt, wird sie dadurch nicht plötzlich erreichbar. Außerdem versteckt die Maßnahme leicht, dass in der WordPress-Datenbank oder im Theme weiterhin falsche URLs gespeichert sind.

HTTP-Links sind nicht automatisch Mixed Content

Ein normaler ausgehender Link von deiner HTTPS-Seite zu einer HTTP-Webseite ist technisch etwas anderes als Mixed Content. Mixed Content entsteht erst, wenn die HTTP-Ressource innerhalb deiner Seite geladen wird, etwa als Bild, Script oder iframe.

Für Sicherheit und Nutzervertrauen lohnt es sich trotzdem, alte externe HTTP-Links zu prüfen und nach Möglichkeit auf aktuelle HTTPS-Ziele zu aktualisieren.

Screaming Frog für größere Websites

Bei größeren Websites ist ein Crawler praktisch. Mit Screaming Frog SEO Spider kannst du die Website crawlen und anschließend nach HTTP-URLs, Ressourcen und Weiterleitungen filtern. Das hilft besonders, wenn das Problem nicht nur auf einer einzelnen Seite auftritt.

Sichere Reihenfolge zur Behebung

  1. Betroffene Seite in der Browser-Konsole prüfen.
  2. Die konkrete HTTP-Ressource identifizieren.
  3. WordPress-Adresse und Website-Adresse kontrollieren.
  4. Nach der eigenen alten HTTP-Domain in der Datenbank suchen.
  5. Vor Änderungen Backup erstellen.
  6. Search-and-Replace zuerst als Testlauf durchführen.
  7. Builder-, WordPress-, CDN- und Browser-Cache leeren.
  8. Seite erneut in Konsole und Netzwerk-Tab kontrollieren.
  9. Erst wenn kein Datenbanktreffer existiert, Theme-Dateien und Snippets durchsuchen.

Fazit

Mixed Content in WordPress lässt sich am zuverlässigsten beheben, wenn du nicht einfach jede HTTP-Adresse ersetzt, sondern zuerst die tatsächlich geladene unsichere Ressource identifizierst. Die häufigsten Fundorte sind wp_posts, wp_postmeta und wp_options, aber auch Theme-CSS und Builder-Daten können verantwortlich sein. Mit Browser-Konsole, einem sicheren Search-and-Replace-Testlauf und anschließender Cache-Bereinigung lässt sich das Problem in den meisten Fällen sauber lösen.