Mixed Content: Warum Ihre Website trotz SSL kein Schloss zeigt

Ein Szenario, das wir ständig sehen: Ein Website-Betreiber installiert ein SSL-Zertifikat, öffnet die Website und — statt des Schlosses erscheint die Warnung „Verbindung nicht vollständig sicher". Der erste Gedanke: Das Zertifikat taugt nichts. Doch in neun von zehn Fällen ist das Zertifikat völlig in Ordnung. Das Problem ist Mixed Content (gemischter Inhalt): Die Seite lädt über HTTPS, aber einige ihrer Bestandteile — Bilder, Skripte, Stylesheets — werden weiterhin über das alte, unverschlüsselte HTTP geladen.

Warum das ein Problem ist

HTTPS garantiert, dass niemand zwischen Besucher und Server den Datenverkehr lesen oder verändern kann. Lädt auf einer verschlüsselten Seite jedoch ein Skript über HTTP, kann ein Angreifer genau dieses Skript abfangen und ersetzen — und der gesamte Schutz bricht zusammen. Deshalb reagieren Browser: Passive Inhalte (Bilder, Videos) werden mit Warnung geladen und das Schloss verschwindet, aktive Inhalte (JavaScript, CSS, iframes) werden komplett blockiert. Das Ergebnis: eine optisch kaputte Website, Formulare, die nicht funktionieren, und Besucher, die die Warnung vertreibt — Studien zeigen durchweg, dass ein erheblicher Teil der Nutzer eine Website sofort verlässt, sobald eine Sicherheitswarnung erscheint.

Woher Mixed Content kommt

• Fest hinterlegte HTTP-Adressen in der Datenbank — WordPress speichert vollständige Bild-URLs im Beitragsinhalt, sodass nach der HTTPS-Umstellung Hunderte Bilder weiter auf http://-Versionen zeigen.
• Themes und Plugins, die Schriften, Skripte oder Styles von HTTP-Adressen laden.
• Externe Dienste — ein alter Banner-Code, Besucherzähler oder Karten-Embed, vor zehn Jahren eingefügt und nie wieder angefasst.
• CSS-Dateien mit Hintergrundbildern auf http://-Pfaden — am leichtesten zu übersehen, weil sie im HTML nicht auftauchen.

Die Übeltäter finden

Öffnen Sie die Website in Chrome, drücken Sie F12 und schauen Sie in die Konsole: Jeder Mixed-Content-Eintrag wird mit exakter Adresse aufgelistet. Für einen Scan der gesamten Website nutzen Sie ein kostenloses Tool wie Why No Padlock oder JitBit SSL Checker, das Seiten durchsucht und jede HTTP-Ressource ausgibt. Bei WordPress deckt eine Datenbanksuche nach „http://ihredomain" mit dem Plugin Better Search Replace alle fest hinterlegten Adressen auf.

Die Lösung Schritt für Schritt

• 1. Suchen & Ersetzen in der Datenbank: Ersetzen Sie „http://ihredomain.de" durch „https://ihredomain.de" (Better Search Replace bietet einen Testlauf zur Vorschau — und vorher unbedingt ein Backup).
• 2. WordPress-Adresse prüfen: Unter Einstellungen → Allgemein müssen beide URLs (WordPress- und Website-Adresse) mit https:// beginnen.
• 3. Externe Ressourcen auf ihre https://-Versionen umstellen (praktisch alle Dienste bieten sie heute) oder solche ohne HTTPS entfernen.
• 4. Eine 301-Weiterleitung von HTTP auf HTTPS auf Serverebene einrichten, damit niemand mehr auf der unverschlüsselten Version landet.
• 5. Für hartnäckige Reste: Der Header Content-Security-Policy: upgrade-insecure-requests weist den Browser an, HTTP-Anfragen selbstständig auf HTTPS anzuheben — ein elegantes Sicherheitsnetz, wobei das Bereinigen der Quelle immer besser ist als das Kaschieren.

Kontrolle und Vorbeugung

Gehen Sie nach der Bereinigung die wichtigsten Seiten mit geöffneter Konsole durch — das Schloss muss überall stabil sein. Für die Zukunft gilt: Prüfen Sie bei jedem eingebetteten Fremdcode, ob die URL mit https:// beginnt. Wenn Sie SSL gerade erst einrichten, beginnen Sie mit unserem SSL-Zertifikat-Leitfaden — und bei unseren Hosting-Tarifen ist SSL kostenlos und verlängert sich automatisch, sodass als einzige Aufgabe genau dies bleibt: das Aufräumen von Mixed Content.