Der Checkout lädt über HTTPS, doch der Browser blockiert ein Zahlungsskript von einer HTTP-Adresse. Gleichzeitig fehlt eine Schrift, weil ein Stylesheet sie über ein unsicheres CDN importiert. Das Ergebnis sind Funktions- und Darstellungsfehler, obwohl die Seite selbst ein gültiges Zertifikat hat.
Bei CSS und JavaScript muss die erste unsichere Quelle gefunden werden. Sie kann in einer WordPress-Enqueue-Funktion, Plugin-Option, Theme-Datei, Build-Konfiguration oder externen Abhängigkeit liegen.
- Was das Thema bedeutet
- Ein realistisches WordPress-Beispiel
- Warum es wichtig ist und wann es eingesetzt wird
- Der einfache Weg für Einsteiger
- Der technische Weg
- Risiken, häufige Fehler, Backup und Rollback
- Wie AIOWS unterstützt: AIOWS SSL Manager
- Passende AIOWS-Artikel
- Fazit und empfohlener Weg
- Offizielle Quellen
Was aktiver Mixed Content ist
Skripte und Stylesheets können Verhalten und Darstellung einer Seite verändern. Browser blockieren HTTP-Ressourcen auf einer HTTPS-Seite deshalb häufig vollständig. Auch Fonts, Module, Worker und API-Aufrufe können Teil derselben unsicheren Abhängigkeitskette sein.
Die sichtbare URL kann direkt von WordPress ausgegeben, in CSS per @importoder url()eingebettet oder beim Build in ein Bundle geschrieben worden sein. Korrigiert werden muss die Quelle, nicht die generierte Cache-Datei.
Ein realistisches WordPress-Beispiel
Ein Theme liest die Basis-URL des Zahlungsanbieters aus einer Option und registriert damit ein Skript. Nach der HTTPS-Umstellung bleibt der alte Wert bestehen. Das blockierte Skript lädt seinerseits ein Stylesheet, das eine Schrift per HTTP anfordert.
Der Administrator korrigiert die Option, prüft den HTTPS-Endpunkt des Anbieters und erstellt die versionierten Assets neu. Erst danach werden Seiten-, CDN- und Browsercache geleert. Checkout und Layout funktionieren wieder ohne Konsolenwarnung.
Warum die Initiatorkette wichtig ist
Ein einzelner HTTP-Eintrag kann mehrere Folgefehler erzeugen. Wer nur die letzte Font-URL ersetzt, lässt das blockierte Ursprungsskript unverändert. Änderungen am Minifikat verschwinden beim nächsten Build und sind deshalb kein dauerhafter Fix.
Die Methode ist besonders nach Domainwechseln, HTTPS-Migrationen, Theme-Releases oder CDN-Änderungen nötig. Prüfen Sie immer die Funktion der Seite, nicht nur das Schloss-Symbol.
Der einfache Weg für Einsteiger
- Speichern Sie die Konsolenmeldung und die vollständige unsichere URL.
- Öffnen Sie in der Netzwerkansicht den Initiator der Anfrage.
- Prüfen Sie, ob die Ressource über gültiges HTTPS erreichbar ist.
- Korrigieren Sie die URL in Theme, Plugin-Einstellung oder Quellkonfiguration.
- Erstellen Sie generierte Assets neu und leeren Sie danach die Caches.
- Testen Sie Frontend, Checkout, Formulare und Editor in einem privaten Fenster.
Der technische Weg
Ordnen Sie Script- und Stylesheet-Handles ihren Enqueue-Callbacks zu. Durchsuchen Sie Quell-CSS, Build-Eingaben, Source Maps und Pluginwerte nach dem alten Host. Prüfen Sie Subresource-Integrity-Attribute und Abhängigkeitsreihenfolge nach jeder URL-Änderung.
- Beziehen Sie CSS-Imports, Fonts, Module, Worker und API-Aufrufe ein.
- Vergleichen Sie Origin-HTML mit minifizierter und gecachter Ausgabe.
- Verwenden Sie keine CSP-Aufwertung als Ersatz für einen fehlenden HTTPS-Endpunkt.
- Ersetzen Sie externe Anbieter, wenn sie die benötigte Ressource nicht sicher ausliefern.
Risiken, häufige Fehler, Backup und Rollback
Blinder Datenbankersatz findet keine fest eingebettete Bundle-URL und kann fremde Werte beschädigen. Das Entfernen von Integritäts- oder Sicherheitsprüfungen, damit ein Skript „wieder lädt“, schafft ein größeres Risiko.
- Versionieren Sie Quell- und Build-Konfiguration.
- Sichern Sie Theme- und Pluginwerte vor der Änderung.
- Behalten Sie die vorherigen Assets bis zum Ablauf alter Caches erreichbar.
- Rollen Sie zurück, wenn Checkout, Editor oder Consent-Logik fehlschlagen.
Wie AIOWS unterstützt:
AIOWS SSL Manager
AIOWS SSL Manager unterstützt die WordPress-seitige HTTPS-Prüfung und hilft zu klären, ob die Basisadressen der Website korrekt sind. Sind WordPress-Adresse und Website-Adresse bereits sicher, kann die weitere Diagnose auf den konkreten Asset-Erzeuger konzentriert werden.
Notieren Sie die blockierte Ressource und vergleichen Sie die Origin-Ausgabe mit der gecachten Seite. Prüfen Sie anschließend mit SSL Manager den unterstützten HTTPS-Zustand und testen Sie dieselbe Vorlage ohne Admin-Cookies. Die tatsächliche Skript-, CSS- oder Font-URL muss an ihrer Quelle geändert werden, beispielsweise in einer Plugin-Option, im Theme oder in der Build-Pipeline.
Das Modul kompiliert keine Assets neu, verändert keine externen CDN-Endpunkte und kann fehlendes TLS eines Drittanbieters nicht ersetzen. Sichern Sie daher die ursprünglichen Werte und halten Sie die vorherige Asset-Version verfügbar. Wenn nach der Korrektur Funktionen oder Styling ausfallen, rollen Sie die Quelländerung zurück und prüfen Abhängigkeiten sowie Integritätsattribute. AIOWS ist hier für die Abgrenzung und abschließende HTTPS-Kontrolle relevant; die Code- und Build-Korrektur bleibt beim verantwortlichen Theme, Plugin oder Anbieter.
Passende AIOWS-Artikel
- WordPress trotz SSL nicht sicher: Vollständige Fehlerbehebung
- Mixed-Content-Bilder in WordPress gezielt beheben
- WordPress-Formulare und AJAX durch Mixed Content blockiert
Fazit und empfohlener Weg
Korrigieren Sie die früheste maßgebliche URL in Enqueue-, Plugin- oder Build-Konfiguration. Erstellen Sie versionierte Assets neu und akzeptieren Sie die Änderung erst, wenn wichtige Seiten ohne unsichere Anfrage vollständig funktionieren.
