{"id":1989,"date":"2026-08-22T16:56:34","date_gmt":"2026-08-22T13:56:34","guid":{"rendered":"https:\/\/allinonewpsettings.com\/blog\/?p=1989"},"modified":"2026-08-04T11:29:01","modified_gmt":"2026-08-04T11:29:01","slug":"mixed-content-bei-css-und-javascript-in-wordpress-beheben","status":"publish","type":"post","link":"https:\/\/allinonewpsettings.com\/blog\/de\/mixed-content-bei-css-und-javascript-in-wordpress-beheben\/","title":{"rendered":"Mixed Content bei CSS und JavaScript in WordPress beheben"},"content":{"rendered":"

Der Checkout l\u00e4dt \u00fcber HTTPS, doch der Browser blockiert ein Zahlungsskript von einer HTTP-Adresse. Gleichzeitig fehlt eine Schrift, weil ein Stylesheet sie \u00fcber ein unsicheres CDN importiert. Das Ergebnis sind Funktions- und Darstellungsfehler, obwohl die Seite selbst ein g\u00fcltiges Zertifikat hat.<\/p>\n

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\u00e4ngigkeit liegen.<\/p>\n

\nInhaltsverzeichnis<\/strong><\/p>\n
    \n
  1. Was das Thema bedeutet<\/a><\/li>\n
  2. Ein realistisches WordPress-Beispiel<\/a><\/li>\n
  3. Warum es wichtig ist und wann es eingesetzt wird<\/a><\/li>\n
  4. Der einfache Weg f\u00fcr Einsteiger<\/a><\/li>\n
  5. Der technische Weg<\/a><\/li>\n
  6. Risiken, h\u00e4ufige Fehler, Backup und Rollback<\/a><\/li>\n
  7. Wie AIOWS unterst\u00fctzt: AIOWS SSL Manager<\/a><\/li>\n
  8. Passende AIOWS-Artikel<\/a><\/li>\n
  9. Fazit und empfohlener Weg<\/a><\/li>\n
  10. Offizielle Quellen<\/a><\/li>\n<\/ol>\n<\/div>\n

    Was aktiver Mixed Content ist<\/h2>\n

    Skripte und Stylesheets k\u00f6nnen Verhalten und Darstellung einer Seite ver\u00e4ndern. Browser blockieren HTTP-Ressourcen auf einer HTTPS-Seite deshalb h\u00e4ufig vollst\u00e4ndig. Auch Fonts, Module, Worker und API-Aufrufe k\u00f6nnen Teil derselben unsicheren Abh\u00e4ngigkeitskette sein.<\/p>\n

    Die sichtbare URL kann direkt von WordPress ausgegeben, in CSS per @import<\/code> oder url()<\/code> eingebettet oder beim Build in ein Bundle geschrieben worden sein. Korrigiert werden muss die Quelle, nicht die generierte Cache-Datei.<\/p>\n

    Ein realistisches WordPress-Beispiel<\/h2>\n

    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\u00e4dt seinerseits ein Stylesheet, das eine Schrift per HTTP anfordert.<\/p>\n

    Der Administrator korrigiert die Option, pr\u00fcft 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.<\/p>\n

    Warum die Initiatorkette wichtig ist<\/h2>\n

    Ein einzelner HTTP-Eintrag kann mehrere Folgefehler erzeugen. Wer nur die letzte Font-URL ersetzt, l\u00e4sst das blockierte Ursprungsskript unver\u00e4ndert. \u00c4nderungen am Minifikat verschwinden beim n\u00e4chsten Build und sind deshalb kein dauerhafter Fix.<\/p>\n

    Die Methode ist besonders nach Domainwechseln, HTTPS-Migrationen, Theme-Releases oder CDN-\u00c4nderungen n\u00f6tig. Pr\u00fcfen Sie immer die Funktion der Seite, nicht nur das Schloss-Symbol.<\/p>\n

    Der einfache Weg f\u00fcr Einsteiger<\/h2>\n
      \n
    1. Speichern Sie die Konsolenmeldung und die vollst\u00e4ndige unsichere URL.<\/li>\n
    2. \u00d6ffnen Sie in der Netzwerkansicht den Initiator der Anfrage.<\/li>\n
    3. Pr\u00fcfen Sie, ob die Ressource \u00fcber g\u00fcltiges HTTPS erreichbar ist.<\/li>\n
    4. Korrigieren Sie die URL in Theme, Plugin-Einstellung oder Quellkonfiguration.<\/li>\n
    5. Erstellen Sie generierte Assets neu und leeren Sie danach die Caches.<\/li>\n
    6. Testen Sie Frontend, Checkout, Formulare und Editor in einem privaten Fenster.<\/li>\n<\/ol>\n

      Der technische Weg<\/h2>\n

      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\u00fcfen Sie Subresource-Integrity-Attribute und Abh\u00e4ngigkeitsreihenfolge nach jeder URL-\u00c4nderung.<\/p>\n