Mixed Content beheben — Zertifikat da, Schloss trotzdem weg.

Was Mixed Content ist.

Wird eine Seite über https ausgeliefert, erwartet der Browser, dass auch alles Nachgeladene verschlüsselt kommt. Findet er eine Adresse, die mit http:// beginnt, hat er ein Problem: Dieser Teil ließe sich unterwegs mitlesen oder verändern. Also entfernt er das Schloss und warnt — bei bestimmten Inhalten blockiert er sie sogar ganz. Das ist kein Fehler deines Zertifikats, sondern ein Hinweis auf Reste aus der Zeit davor. Fehlt das Zertifikat ganz, ist das ein anderes Thema („Nicht sicher“-Warnung).

Aktiv und passiv.

Diese Unterscheidung erklärt, warum manche Seiten nur die Warnung zeigen, während bei anderen das Layout zerfällt oder ein Formular nicht mehr funktioniert. Fällt gleichzeitig die Darstellung auseinander, lohnt der Blick auf kaputtes Layout — die Ursache kann dieselbe sein.

Verursacher finden.

Der schnellste Weg führt über die Entwicklerwerkzeuge des Browsers: mit F12 öffnen, auf den Reiter Konsole wechseln, die Seite neu laden. Dort steht zu jedem unsicheren Bestandteil die vollständige Adresse. Damit weißt du sofort, ob es ein Bild aus deiner Mediathek ist, eine Schrift von einem fremden Server oder ein eingebundenes Skript.

Wichtig: Prüfe nicht nur die Startseite. Die häufigsten Fundstellen sind alte Beiträge mit eingefügten Bildern, Seiten mit eingebundenen Karten oder Videos und der Fußbereich mit Zahlungslogos. Nimm dir eine Handvoll typischer Seiten vor — Startseite, eine Leistungsseite, einen alten Beitrag, die Kontaktseite, bei einem Shop eine Produktseite und die Kasse.

Adressen in der Datenbank.

Bilder, die vor der Umstellung eingefügt wurden, stehen mit voller http-Adresse im Beitragstext. Diese Einträge müssen ersetzt werden. Das erledigt ein Suchen-und-Ersetzen-Werkzeug, das auch mit den serialisierten Daten umgehen kann, in denen Page Builder ihre Einstellungen ablegen. Ein einfaches Ersetzen über phpMyAdmin ist hier riskant: Es zerstört solche Datenstrukturen, weil sich die Länge der Zeichenketten ändert. Vor jedem Durchlauf ein Backup ziehen (Backup erstellen).

Zwei Einträge sind besonders wichtig und stehen unter Einstellungen → Allgemein: die WordPress-Adresse und die Website-Adresse. Beide müssen mit https beginnen. Sind sie nicht änderbar, weil sie in der wp-config.php festgelegt sind, gehört die Änderung dorthin.

Feste Pfade in Theme und Vorlagen.

In selbst angepassten Themes und in älteren Vorlagen finden sich oft fest eingetragene Adressen — etwa zu einem Logo oder zu einer Schriftdatei. Sie überstehen jedes Suchen-und-Ersetzen in der Datenbank, weil sie in Dateien stehen. Hier hilft nur, die Theme-Dateien zu durchsuchen. Am saubersten ist, feste Adressen ganz zu vermeiden und stattdessen die WordPress-Funktionen zu nutzen, die den Pfad zur Laufzeit erzeugen — dann stimmt er auch nach einem Umzug oder Domainwechsel noch.

Externe Einbindungen.

Karten, Videos, Schriften, Zähler, Chat-Fenster: Alles, was von fremden Servern kommt, muss ebenfalls über https geladen werden. Die meisten großen Anbieter liefern das längst automatisch. Problematisch sind ältere Einbindungen mit ausgeschriebener http-Adresse und kleine Dienste, die gar kein Zertifikat haben — dort bleibt nur, den Dienst zu ersetzen oder wegzulassen. Bei Schriften ist das ohnehin die bessere Wahl: Lokal eingebunden sind sie schneller und datenschutzfreundlicher (Google Fonts lokal einbinden). Bei Karten und Videos lohnt der Blick auf YouTube und Karten einbinden.

Die richtige Reihenfolge.

1. Backup von Dateien und Datenbank.
2. Zertifikat prüfen: gültig, für alle Varianten der Domain ausgestellt, nicht abgelaufen.
3. Adressen in den Einstellungen auf https umstellen.
4. Datenbank ersetzen mit einem Werkzeug, das serialisierte Daten beherrscht.
5. Theme-Dateien nach festen http-Adressen durchsuchen.
6. Externe Einbindungen prüfen und umstellen.
7. Weiterleitung von http auf https einrichten, damit alte Links ankommen (Weiterleitungen).
8. Caches leeren — Plugin, Server, Browser (Cache leeren).
9. Nachkontrolle auf mehreren Seiten.

Warum Plugins nur überdecken.

Es gibt Erweiterungen, die beim Ausliefern jede http-Adresse in https umschreiben. Das bringt das Schloss zurück, ändert aber nichts an den Daten: In der Datenbank stehen weiterhin die alten Adressen, und jede Seite muss bei jedem Aufruf zusätzlich umgeschrieben werden. Schaltest du das Plugin ab oder ziehst um, ist das Problem zurück. Als Übergang für ein paar Tage in Ordnung, als Dauerlösung nicht. Repariere die Daten und nimm das Plugin danach wieder heraus.

Prüfliste.

• Startseite, Leistungsseite, alter Beitrag, Kontaktseite ohne Warnung?
• Bei einem Shop: Produktseite, Warenkorb, Kasse (Checkout prüfen)?
• Konsole auf jeder geprüften Seite ohne Mixed-Content-Meldung?
• Aufruf mit http landet per Weiterleitung auf https?
• Aufruf mit und ohne www funktioniert?
• Sitemap und Rechtstexte ebenfalls über https erreichbar?

Wenn du nicht weiterkommst.

Wenn nach der Umstellung einzelne Seiten weiterhin warnen und du die Quelle nicht findest, übernehme ich die Suche inklusive Datenbankersetzung. Ich finde die Ursache, behebe sie und erkläre dir, was passiert ist: WordPress-Hilfe, bei einem Totalausfall der Notfall-Support. Damit es gar nicht erst so weit kommt: WordPress-Wartung.

Orientierungswerte, keine Fixpreise — nach einem kurzen Gespräch bekommst du ein Festpreisangebot.

Wer hilft.

Ich bin Manuel Killert, WordPress-Entwickler aus Quakenbrück. Seit 2020 baue und betreue ich WordPress-Websites — für Handwerksbetriebe, Industrie, Gastronomie, Start-ups und Vereine —, entwickle eigene Plugins und unterrichte WordPress als Dozent an der KW Design Akademie. Das heißt: Ich kenne die typischen Fehler nicht nur aus Foren, sondern aus eigenen Projekten, und ich kann sie so erklären, dass du sie beim nächsten Mal selbst erkennst. Du erreichst mich direkt, ohne Ticketsystem.