Wie diese Prüfung funktioniert
Scanaris liest das HTML deiner über HTTPS ausgelieferten Seite und sucht nach Verweisen auf Ressourcen, die mit http:// beginnen: Skripte, Stylesheets, Iframes, Bilder, Videos, Audio und Schriften. Er teilt sie in zwei Gruppen. Aktiver Mixed Content (Skripte, Styles, Iframes) öffnet einen Befund mit mittlerem Schweregrad, weil diese Ressourcen Code ausführen oder die Seite verändern können. Passiver Mixed Content (Bilder, Video, Audio) öffnet einen Befund mit niedrigem Schweregrad: Er führt nichts aus, reist aber im Klartext und bricht das Schloss. Geprüft werden nur die Verweise im anfänglichen HTML; Ressourcen, die später per JavaScript hinzukommen, werden auf diesem Weg nicht gesehen.
Warum das wichtig ist
Ein per HTTP geladenes Skript in einer HTTPS-Seite ist der schlimmste Fall: Wer das Netz kontrolliert, kann es durch ein anderes ersetzen und in deiner Seite ausführen, was er will, mit der Sitzung des Nutzers. Deshalb blockieren moderne Browser es schlicht, und deine Seite geht an dieser Stelle still kaputt. Bei Bildern lädt der Browser sie, nimmt aber das Schloss weg oder zeigt eine „Nicht sicher"-Warnung, die der Nutzer sieht. In beiden Fällen ist die Botschaft dieselbe: Die Seite gibt vor, sicher zu sein, und ist es nicht ganz.
Woher das kommt
Fast immer aus altem Code: URLs, die vor Jahren aus einem Tutorial oder Template kopiert wurden, eine Bibliothek von einem CDN, das damals kein HTTPS hatte, Bilder aus einem migrierten Blog oder ein Datenbankfeld mit der vollständigen URL eines Bildes, das hochgeladen wurde, als die Seite noch auf HTTP lief. Bei WordPress ist das typisch nach einem Wechsel von HTTP auf HTTPS ohne Aktualisierung der gespeicherten URLs.
So behebst du es
- Ändere die Verweise auf https:// oder auf relative Pfade (
/images/foto.jpg), die das Protokoll der Seite erben. Das ist die richtige und endgültige Lösung. - Wenn eine externe Ressource kein HTTPS hat, lade sie herunter und liefere sie von deiner Domain aus, oder such eine andere Quelle. 2026 läuft fast nichts Legitimes mehr nur über HTTP.
- Bei WordPress aktualisierst du die in der Datenbank gespeicherten URLs mit einem Suchen-und-Ersetzen-Tool, das die Serialisierung respektiert, und prüfst die Site-URLs in den allgemeinen Einstellungen.
- Als Sicherheitsnetz sagt die CSP-Direktive
upgrade-insecure-requestsdem Browser,http://-Anfragen deiner Seite automatisch inhttps://umzuwandeln. Das hilft, während du den Code aufräumst, ersetzt das Aufräumen aber nicht: Die Ressource muss über HTTPS existieren, damit es funktioniert.
Content-Security-Policy: upgrade-insecure-requestsPrüf, ob es behoben ist
curl -s https://deinedomain.de | grep -oE '(src|href)="http://[^"]+"' | sort -uEs darf nichts herauskommen. Öffne dann die Seite mit der Browser-Konsole: Jede per JavaScript geladene gemischte Ressource erscheint dort als Warnung oder Blockierung.
Häufige Fragen
Meine Seite lädt einwandfrei und hat das Schloss. Warum wird das gemeldet?
Weil der Browser die Ressource vielleicht still blockiert oder sie von sich aus auf HTTPS hebt. Der Verweis in deinem HTML bleibt auf http://, und andere Clients (Bots, alte Browser, E-Mails) machen diese Korrektur nicht.
Sind URLs, die mit // beginnen, Mixed Content?
Nein. Protokollrelative URLs erben das Protokoll der Seite und laden auf HTTPS über HTTPS. Trotzdem wird heute empfohlen, direkt https:// zu schreiben.
Zählt ein Link <a href="http://…">?
Nein. Ein Link lädt nichts in deine Seite; er bringt den Nutzer nur woandershin. Mixed Content ist das, was die Seite einbettet.