
Mixed Content bei CSS und JavaScript in WordPress beheben
So finden Sie unsichere Skript-, Stylesheet- und Font-URLs, korrigieren Enqueue- oder Build-Quellen und testen die Website nach dem Asset-Neubau.
Ein Zertifikat ist leicht zu installieren und erstaunlich leicht so zu installieren, dass das Schloss trotzdem fehlt. Am Zertifikat selbst liegt es selten — schief geht meist alles darum herum: Ressourcen, die weiterhin über http angefordert werden, Weiterleitungen, die sich im Kreis drehen, ein Proxy, der WordPress nicht mitteilt, dass die Verbindung gesichert war.
Diese Anleitungen beginnen beim Zertifikat: eines installieren, lesen, was tatsächlich darin steht, den Ablauf prüfen, bevor ein Browser es tut, und die Fehler verstehen, die erscheinen, wenn der Name im Zertifikat nicht zu der eingegebenen Adresse passt.
Die größte Gruppe behandelt Mixed Content, den Grund dafür, dass die meisten Websites nach einem Wechsel auf https „Nicht sicher“ anzeigen. Ein einziges über http geladenes Stylesheet, Skript oder Bild genügt, um das Schloss auf einer ansonsten korrekten Seite zu zerstören, und die Browser-Konsole benennt es genau, sofern bekannt ist, wo zu suchen ist. Formulare und AJAX-Anfragen scheitern auf dieselbe Weise, nur sichtbarer.
Danach die Weiterleitungen, denn beim Erzwingen von https zerlegen sich Websites am häufigsten selbst: eine Regel zu viel, und jede Anfrage springt so lange hin und her, bis der Browser aufgibt. Von http zu https sollte genau ein Sprung nötig sein, und dasselbe gilt für die Entscheidung zwischen www und ohne www.
Zum Schluss die Header, die https dauerhaft machen — HSTS und seine Preload-Liste, die sich nur sehr schwer rückgängig machen lässt. Die Risiken gehören vor der Übermittlung gelesen.

So finden Sie unsichere Skript-, Stylesheet- und Font-URLs, korrigieren Enqueue- oder Build-Quellen und testen die Website nach dem Asset-Neubau.

So bringen Sie nach einem WordPress-Umzug DNS, Zertifikate, WordPress-URLs, Medien, Redirects und externe Callbacks auf einen konsistenten HTTPS-Stand.

So wählen Sie einen kanonischen HTTPS-Host, sichern beide Domainvarianten per Zertifikat und leiten Pfade sowie Query-Parameter in genau einem Schritt weiter.

So übergeben Reverse Proxy und Load Balancer das bei der ursprünglichen Anfrage verwendete HTTPS-Protokoll sicher an WordPress, ohne Redirect-Schleifen oder unsichere Cookies.

So sichern Sie WordPress-Login und wp-admin mit FORCE_SSL_ADMIN, korrekter Proxy-Erkennung, sicheren Cookies und einem erreichbaren Notfallzugang.

HSTS Preload schützt bereits den ersten Aufruf, verpflichtet aber den gesamten Domainraum zu HTTPS. So prüfen Sie Voraussetzungen, Zuständigkeit und Ausstiegsplan.

So führen Sie HSTS mit kurzer Laufzeit ein, prüfen alle HTTPS-Hosts und erweitern die Richtlinie erst später um includeSubDomains oder Preload.

So beenden Sie Redirect-Schleifen zwischen Cloudflare und WordPress, stellen den Origin auf HTTPS um und verwenden Full (strict) mit genau einer Weiterleitungsregel.

So beheben Sie Zertifikatsfehler bei www, Hauptdomain und Subdomains, indem Sie SAN-Einträge, SNI, DNS, CDN und Virtual Hosts korrekt zuordnen.

So grenzen Sie TLS-Handshake-Fehler vor WordPress ein und prüfen SNI, Zertifikatskette, Protokolle, Cipher, CDN und Ursprung systematisch.