Eine Website kann bereits vollständig über HTTPS erreichbar sein und trotzdem noch unsichere Inhalte laden. Dieses Problem wird als Mixed Content bezeichnet. Es entsteht, wenn eine per HTTPS geschützte Seite Ressourcen wie Bilder, Stylesheets, JavaScript-Dateien, Schriftarten oder Videos über eine unverschlüsselte HTTP-Adresse anfordert.
Mixed Content ist nicht nur eine technische Unsauberkeit. Je nach Art der betroffenen Ressource können Browser Inhalte blockieren, Warnungen anzeigen oder die Integrität einer Seite gefährden. In diesem Ratgeber erfahren Sie, wie Sie Mixed Content erkennen, die Ursache systematisch eingrenzen und dauerhaft beheben. Die Vorgehensweise eignet sich für WordPress-Websites ebenso wie für individuell entwickelte Seiten.
Was bedeutet Mixed Content?
Mixed Content liegt vor, wenn eine HTTPS-Seite gleichzeitig Ressourcen über HTTP einbindet. Das typische Beispiel ist eine Seite mit dieser Adresse:
https://www.beispiel.deIn ihrem Quelltext wird jedoch ein Bild so referenziert:
<img src="http://www.beispiel.de/uploads/bild.jpg" alt="Beispielbild">Die eigentliche Seite wird verschlüsselt übertragen, das Bild aber nicht. Dadurch entsteht ein gemischter Abruf. Auch externe Dienste können die Ursache sein, etwa ein eingebundenes Skript, eine Schriftdatei, ein Video-Player oder ein Analysewerkzeug.
Entscheidend ist die Unterscheidung zwischen passivem und aktivem Mixed Content:
- Passiver Mixed Content: Dazu zählen meist Bilder, Audio- oder Videodateien. Er kann Warnungen auslösen oder vom Browser ersetzt beziehungsweise blockiert werden.
- Aktiver Mixed Content: Dazu gehören JavaScript, Stylesheets, iFrames, Webfonts und bestimmte API-Anfragen. Diese Ressourcen können die Darstellung und Funktion der Seite beeinflussen und werden von modernen Browsern häufig blockiert.
Auch wenn die Seite im eigenen Browser scheinbar funktioniert, sollte die Ursache behoben werden. Besucher verwenden unterschiedliche Browser, Erweiterungen, Gerätekonfigurationen und Sicherheitsstufen.
Warum Mixed Content problematisch ist
Achten Sie im Bild auf die vollständige URL und den Status der Anfrage. Diese Informationen helfen dabei, die betroffene Datei eindeutig zuzuordnen, statt nur eine allgemeine Browserwarnung zu behandeln.
HTTPS schützt die Verbindung zwischen Browser und Server vor dem Mitlesen und erschwert Manipulationen auf dem Übertragungsweg. Wird eine Ressource dagegen über HTTP geladen, fehlt dieser Schutz für genau diesen Abruf. Bei aktiven Ressourcen kann ein Angreifer unter bestimmten Bedingungen Inhalte verändern, bevor sie den Browser erreichen.
In der Praxis zeigen sich häufig diese Folgen:
- Ein Stylesheet wird blockiert und die Seite erscheint ohne korrekte Gestaltung.
- JavaScript wird nicht ausgeführt, sodass Menüs, Filter oder Formulare nicht funktionieren.
- Bilder, Schriftarten oder Videos werden nicht geladen.
- Die Entwicklerkonsole meldet unsichere Anfragen.
- Das Vorhängeschloss oder die Sicherheitsanzeige des Browsers fehlt beziehungsweise weist auf ein Problem hin.
- Interne Weiterleitungen, API-Aufrufe oder Vorschaufunktionen brechen ab.
Mixed Content ist außerdem ein Hinweis darauf, dass URLs, Migrationen oder externe Einbindungen nicht konsequent auf HTTPS umgestellt wurden. Eine saubere Behebung verbessert daher meist auch die Wartbarkeit der Website.
Mixed Content erkennen: Die wichtigsten Prüfmethoden
Bevor Sie Änderungen vornehmen, sollten Sie möglichst genau feststellen, welche Ressource über HTTP geladen wird. Arbeiten Sie dabei nicht nur mit der Startseite. Auch Unterseiten, Beiträge, Suchseiten, Produktseiten und Formulare können eigene Fehler enthalten.
Die Browser-Entwicklertools verwenden
Die Entwicklerwerkzeuge moderner Browser sind für die erste Diagnose besonders hilfreich:
- Öffnen Sie die betroffene Seite über ihre HTTPS-Adresse.
- Öffnen Sie die Entwicklertools, meist über die Taste F12 oder das Kontextmenü.
- Wechseln Sie zum Bereich Konsole.
- Laden Sie die Seite mit geöffneter Konsole neu.
- Suchen Sie nach Meldungen mit Begriffen wie „Mixed Content“, „blocked“, „insecure“ oder „HTTP“.
Die Meldung enthält oft die konkrete URL und beschreibt, ob eine Ressource blockiert oder nur als Warnung behandelt wurde. Kopieren Sie die URL, bevor Sie die Seite verändern. So lässt sich später kontrollieren, ob genau diese Anfrage verschwunden ist.
Im Netzwerk-Tab nach HTTP-Anfragen suchen
Der Bereich Netzwerk zeigt, welche Dateien beim Laden der Seite angefordert werden. Filtern Sie nach „http:“ oder prüfen Sie die vollständigen Adressen einzelner Einträge. Achten Sie besonders auf:
- CSS- und JavaScript-Dateien
- Bilder in Beiträgen, Widgets oder Slidern
- Schriftarten und Icon-Bibliotheken
- Video- und Audioquellen
- XHR- oder Fetch-Anfragen an APIs
- eingebettete Inhalte und iFrames
Ein Eintrag mit einem roten Status oder dem Hinweis „blocked:mixed-content“ ist ein deutlicher Anhaltspunkt. Beachten Sie jedoch, dass eine Umleitung von HTTP nach HTTPS nicht in jedem Fall eine saubere Lösung ist. Der Quellverweis sollte möglichst direkt HTTPS verwenden.
Quelltext und Datenbank durchsuchen
Bei einer WordPress-Website kann die alte HTTP-Adresse in Beiträgen, Widgets, Theme-Dateien, Plugin-Einstellungen oder gespeicherten Optionen stehen. Eine Suche nach http:// liefert häufig schnell erste Treffer. Prüfen Sie aber, ob es sich um eine tatsächlich geladene Ressource handelt oder nur um Text, Dokumentation oder eine externe Adresse, die nicht geändert werden darf.
Vor direkten Datenbankänderungen ist eine vollständige Sicherung wichtig. Besonders bei serialisierten WordPress-Daten können einfache Ersetzungen Strukturen beschädigen. Verwenden Sie für umfangreiche URL-Ersetzungen ein dafür geeignetes, seriell arbeitendes Werkzeug oder lassen Sie die Änderung von einer fachkundigen Person durchführen.
Externe Prüfwerkzeuge ergänzend einsetzen
Online-Crawler und Sicherheitsprüfungen können mehrere Seiten gleichzeitig untersuchen. Sie sind nützlich, um vergessene Unterseiten, alte Medienpfade und Ressourcen aus Templates zu finden. Solche Werkzeuge ersetzen jedoch nicht die Browserkonsole: Sie können Inhalte übersehen, die erst nach einer Benutzeraktion oder durch JavaScript geladen werden.
Mixed Content beheben: Eine systematische Vorgehensweise
Die beste Lösung hängt davon ab, wo die HTTP-Adresse gespeichert ist. Gehen Sie von der stabilen Grundlage zur individuellen Einbindung vor. Dadurch vermeiden Sie, dass eine automatische Korrektur die eigentliche Ursache verdeckt.
1. HTTPS-Grundlage des Webauftritts prüfen
Stellen Sie zunächst sicher, dass die Website grundsätzlich über ein gültiges TLS-Zertifikat erreichbar ist. Prüfen Sie die wichtigsten Varianten:
https://example.dehttps://www.example.de- gegebenenfalls weitere aktive Subdomains
Welche Variante die Hauptadresse ist, sollte eindeutig festgelegt sein. Die Website sollte nicht dauerhaft zwischen mehreren Varianten wechseln. Interne Links, die bevorzugte Domain und kanonische Angaben müssen zueinander passen. Zertifikats- oder Hostingprobleme sind allerdings ein eigenes Thema und sollten nicht mit Mixed Content vermischt werden.
2. Interne URLs auf HTTPS aktualisieren
Wenn eine eigene Ressource über HTTP eingebunden ist, ändern Sie die Adresse auf HTTPS. Das betrifft beispielsweise:
http://www.beispiel.de/wp-content/uploads/logo.svgzu:
https://www.beispiel.de/wp-content/uploads/logo.svgBei internen Links können auch relative URLs sinnvoll sein, etwa /wp-content/uploads/logo.svg. Absolute HTTPS-URLs sind dagegen oft klarer, wenn Inhalte über mehrere Domains, CDNs oder Umgebungen ausgeliefert werden. Wichtig ist, dass die Ressource selbst tatsächlich über HTTPS erreichbar ist und nicht nur eine fehlerhafte Weiterleitung zurückgibt.
3. WordPress-Adresse und Website-Adresse kontrollieren
In WordPress finden Sie unter den allgemeinen Einstellungen die WordPress-Adresse und die Website-Adresse. Beide sollten bei einer vollständig verschlüsselten Website mit https:// beginnen. Änderungen an dieser Stelle können die Erreichbarkeit beeinflussen. Legen Sie deshalb vorher eine Sicherung an und prüfen Sie, ob Sie über einen alternativen Administrationszugang verfügen.
Manchmal wird die Adresse zusätzlich in der Konfigurationsdatei, durch Hosting-Einstellungen oder durch eine Entwicklungsumgebung vorgegeben. Wenn die Einstellung nach dem Speichern wieder zurückspringt, liegt die Ursache wahrscheinlich außerhalb der normalen WordPress-Oberfläche.
4. Medien, Menüs und Widgets korrigieren
Alte Bild-URLs entstehen häufig nach einer nachträglichen HTTPS-Umstellung. Überprüfen Sie Bilder und Dateien in Beiträgen, Seiten, Headern, Fußzeilen, Widgets und visuellen Editoren. Auch Hintergrundbilder in den Theme-Einstellungen können betroffen sein, obwohl sie im normalen Editor nicht als klassischer Link sichtbar sind.
Bei einzelnen Dateien genügt eine manuelle Korrektur. Bei vielen betroffenen Einträgen ist eine kontrollierte URL-Ersetzung effizienter. Testen Sie eine solche Änderung zunächst in einer Staging-Umgebung und kontrollieren Sie anschließend Medien, interne Verweise und responsive Ansichten.
5. Theme- und Plugin-Dateien untersuchen
Hardcodierte HTTP-Adressen finden sich manchmal in Theme-Dateien, individuellen Codeblöcken oder Plugin-Konfigurationen. Aktualisieren Sie zunächst WordPress, Theme und Plugins aus vertrauenswürdigen Quellen. Eine veraltete Erweiterung kann unsichere Einbindungen enthalten oder URLs falsch erzeugen.
Ändern Sie Dateien eines gekauften Themes möglichst nicht direkt, weil Updates die Anpassungen überschreiben können. Nutzen Sie stattdessen ein Child-Theme, eine vorgesehene Einstellung oder eine dokumentierte Filter- beziehungsweise Hook-Lösung. Bei eigener Entwicklung sollten URLs über geeignete WordPress-Funktionen erzeugt werden, statt das Protokoll fest in den Code zu schreiben.
6. Externe Ressourcen richtig behandeln
Für externe Ressourcen gibt es drei sinnvolle Optionen:
- Verwenden Sie die HTTPS-Version des Anbieters, wenn sie zuverlässig verfügbar ist.
- Hosten Sie die Ressource selbst, sofern Lizenz, Aktualität und Wartung das erlauben.
- Entfernen Sie die Einbindung, wenn sie nicht erforderlich ist oder keinen klaren Nutzen bietet.
Verwenden Sie keine beliebige HTTPS-Variante, wenn der externe Dienst diese nicht offiziell unterstützt. Eine nicht funktionierende URL kann die Website stärker beeinträchtigen als die ursprüngliche Warnung. Prüfen Sie außerdem, ob Datenschutz, Nutzungsbedingungen und Abhängigkeiten des Dienstes zu Ihrer Website passen.
7. HTTP-Weiterleitungen nur als Ergänzung nutzen
Eine Weiterleitung von HTTP auf HTTPS ist für alte Bookmarks und externe Verweise sinnvoll. Sie ersetzt aber nicht die Aktualisierung interner Ressourcen. Der Browser muss die HTTP-Anfrage zunächst erkennen und anfordern, bevor die Weiterleitung greift. Direkte HTTPS-Verweise sind daher sauberer, schneller und weniger fehleranfällig.
Auf Serverebene kann eine Weiterleitung für die Hauptdomain eingerichtet werden. Die genaue Konfiguration hängt vom Webserver und vom Hosting ab. Nehmen Sie keine pauschalen Änderungen an Serverdateien vor, wenn Sie die bestehende Konfiguration nicht nachvollziehen können. Eine fehlerhafte Weiterleitung kann eine Endlosschleife oder einen kompletten Ausfall verursachen.
Besondere Fälle, die oft übersehen werden
CSS-Hintergrundbilder und Schriftarten
Ein Bild kann über CSS eingebunden sein und taucht deshalb nicht unbedingt im visuellen Editor auf. Suchen Sie in Stylesheets nach url(http://.... Webfonts sind besonders relevant, weil Browser unsichere Schriftdateien blockieren können. Prüfen Sie auch Icon-Schriften und Ressourcen, die von einem CDN geladen werden.
JavaScript und dynamisch erzeugte URLs
Manche HTTP-Adressen stehen nicht im initialen HTML, sondern werden erst durch JavaScript erzeugt. In diesem Fall hilft der Netzwerk-Tab während der konkreten Aktion, etwa beim Öffnen eines Menüs, Absenden eines Formulars oder Nachladen weiterer Inhalte. Prüfen Sie auch API-Endpunkte und Konfigurationsdateien, die an das Frontend übergeben werden.
iFrames, Videos und eingebettete Dienste
Ein eingebettetes Video oder ein Karten- beziehungsweise Terminmodul kann eine eigene HTTP-Adresse enthalten. Verwenden Sie die vom Anbieter dokumentierte HTTPS-Einbettung und testen Sie die Funktion in einem privaten Browserfenster. Falls ein Dienst keine sichere Einbindung anbietet, sollten Sie abwägen, ob ein Link, ein Vorschaubild oder ein anderer Anbieter die bessere Lösung ist.
Content Delivery Networks und Subdomains
Liegt eine Datei auf einer Subdomain oder einem CDN, benötigt auch diese Auslieferungsadresse eine gültige HTTPS-Konfiguration. Ein Zertifikat für die Hauptdomain deckt nicht automatisch jede Subdomain ab. Kontrollieren Sie außerdem, ob gemischte Inhalte nur in einer bestimmten Umgebung auftreten, etwa auf der Produktionsseite, in einer Vorschau oder nach einem Domainwechsel.
Nach der Korrektur: gründlich kontrollieren
Eine einzelne erfolgreiche Prüfung reicht nicht immer aus. Leeren Sie gegebenenfalls den Cache von Website, Plugin, CDN und Browser. Öffnen Sie danach die Seite in einem privaten Fenster und prüfen Sie sie in mindestens einem weiteren modernen Browser.
Kontrollieren Sie insbesondere:
- Startseite und wichtige Unterseiten
- Beiträge mit älteren Bildern oder eingebetteten Medien
- Kontakt-, Login- und Suchfunktionen
- Navigation, Menüs, Slider und Filter
- mobile Darstellung und responsive Breakpoints
- Checkout-, Buchungs- oder Mitgliederbereiche, falls vorhanden
- Browserkonsole und Netzwerk-Tab ohne neue Mixed-Content-Meldungen
Prüfen Sie nicht nur die sichtbare Oberfläche. Eine Seite kann äußerlich korrekt aussehen, während ein Hintergrund-API-Aufruf weiterhin über HTTP erfolgt. Wiederholen Sie deshalb die Aktionen, die vorher Fehler ausgelöst haben.
Häufige Fehler bei der Behebung
- Nur die Startseite wird geprüft: Alte Inhalte liegen oft auf Unterseiten oder in selten genutzten Templates.
- Nur das Vorhängeschloss wird betrachtet: Die Browserkonsole liefert deutlich genauere Hinweise.
- HTTP wird blind durch HTTPS ersetzt: Nicht jede externe Ressource unterstützt HTTPS korrekt.
- Der Cache wird vergessen: Alte Dateien können Warnungen scheinbar weiterhin verursachen.
- Direkte Datenbankänderungen erfolgen ohne Sicherung: Das kann Inhalte und Einstellungen beschädigen.
- Ein Plugin wird installiert und nicht kontrolliert: Automatische Korrekturen können Nebenwirkungen haben und ersetzen keine Ursachenanalyse.
- Die Weiterleitung gilt als vollständige Lösung: Sie sollte nur als ergänzende Maßnahme betrachtet werden.
Bei einer kleinen Website ist die manuelle Prüfung oft überschaubar. Bei einem umfangreichen Shop, einer mehrsprachigen Installation oder vielen dynamischen Funktionen kann professionelle Unterstützung sinnvoll sein. Entscheidend ist, dass Änderungen nachvollziehbar bleiben und zunächst in einer sicheren Umgebung getestet werden.
FAQ
Woran erkenne ich Mixed Content am schnellsten?
Öffnen Sie die HTTPS-Seite und prüfen Sie die Browserkonsole. Meldungen mit „Mixed Content“, „insecure“ oder „blocked“ nennen häufig die betroffene Ressource. Ergänzend zeigt der Netzwerk-Tab HTTP-Anfragen und deren Status.
Ist Mixed Content gefährlich?
Das Risiko hängt von der Ressource ab. Ein unsicheres Bild ist anders zu bewerten als ein über HTTP geladenes JavaScript. Aktive Inhalte können Funktionen verändern und werden deshalb oft blockiert. Jede unnötige HTTP-Einbindung sollte dennoch beseitigt werden.
Warum funktioniert die Website trotz Mixed Content?
Browser behandeln verschiedene Ressourcentypen unterschiedlich. Manche Inhalte werden weiterhin geladen, andere nur gewarnt oder vollständig blockiert. Außerdem kann ein Fehler nur bei einer bestimmten Aktion, in einem bestimmten Browser oder auf einer einzelnen Unterseite auftreten.
Reicht es, alle HTTP-URLs auf HTTPS umzuleiten?
Nein. Eine Weiterleitung hilft bei alten Aufrufen, aber der Browser startet zunächst eine HTTP-Anfrage. Besser ist es, interne und externe Einbindungen direkt mit HTTPS zu speichern. Die Weiterleitung bleibt als zusätzliche Absicherung sinnvoll.
Kann ein WordPress-Plugin Mixed Content automatisch beheben?
Ein geeignetes Plugin kann bei der Diagnose oder bei bestimmten Ersetzungen helfen. Vorher sollten Sie eine Sicherung anlegen, die Funktionsweise verstehen und die Ergebnisse kontrollieren. Automatische Korrekturen können hardcodierte URLs, externe Dienste oder dynamische Anfragen übersehen.
Was mache ich, wenn eine externe Ressource kein HTTPS anbietet?
Prüfen Sie, ob der Dienst eine aktuelle sichere Einbindung bereitstellt. Falls nicht, kommen je nach Lizenz und Wartbarkeit eine eigene Auslieferung, ein Ersatzdienst oder ein einfacher Link infrage. Eine unsichere aktive Einbindung sollte nicht dauerhaft auf einer HTTPS-Seite verbleiben.
Warum erscheint Mixed Content nach der Umstellung auf HTTPS wieder?
Häufig kommen neue Inhalte aus alten Vorlagen, Importen, Caches, Plugins oder externen Widgets hinzu. Auch eine Änderung der Domain oder eines CDNs kann alte Pfade reaktivieren. Führen Sie nach größeren Aktualisierungen eine erneute Stichprobe mit Browserkonsole und Netzwerk-Tab durch.
Fazit: Mixed Content dauerhaft beheben
Mixed Content lässt sich zuverlässig beheben, wenn Sie nicht nur Warnungen ausblenden, sondern die konkrete Quelle jeder HTTP-Anfrage finden. Beginnen Sie mit der Browserkonsole, prüfen Sie anschließend Netzwerk, Quelltext und gespeicherte WordPress-URLs. Aktualisieren Sie interne Ressourcen direkt auf HTTPS, behandeln Sie externe Dienste mit Sorgfalt und nutzen Sie Weiterleitungen nur ergänzend.
Nach der Änderung sind Cache-Leerung, Tests auf wichtigen Unterseiten und die Kontrolle dynamischer Funktionen entscheidend. Eine konsequent verschlüsselte Website ist nicht nur sicherer, sondern meist auch leichter zu warten. Dokumentieren Sie die vorgenommenen Änderungen, damit spätere Theme-, Plugin- oder Domainwechsel nicht erneut unbemerkte HTTP-Verweise erzeugen.