Mixed Content Fehler beheben: Ursachen, Diagnose und Lösung

Was ist ein Mixed Content Fehler?

Ein Mixed Content Fehler tritt auf, wenn eine Seite über HTTPS lädt, aber mindestens eine Ressource wie ein Bild, ein Skript oder ein Stylesheet von einer unsicheren HTTP Adresse anfordert. Der Browser blockiert diese Ressource oder entfernt das Schlosssymbol. Folglich wirkt die Seite kaputt, und Besucher verlieren Vertrauen.

Der Name kommt also von der Mischung aus sicheren und unsicheren Verbindungen auf einer einzigen Seite. Die Seite selbst kommt verschlüsselt an, ein einzelnes Teil reist aber im Klartext. Wer diesen Datenverkehr mitlesen oder verändern kann, beeinflusst daher Aussehen und Verhalten der Seite.

In der Browser Konsole beginnt die Meldung dann meist mit den Worten "Mixed Content". Sie sagt, dass die Seite über HTTPS geladen wurde, aber eine unsichere Ressource angefordert hat. Zum Beispiel löst ein alter Beitrag mit einem Bild von einer http:// Adresse genau diese Meldung aus.

Dieser Ratgeber erklärt daher nicht von Grund auf, was ein SSL Zertifikat ist. Das haben wir in unserem Beitrag zu SSL Zertifikat und HTTPS Sicherheit behandelt. Hier geht es stattdessen darum, warum der Fehler trotz funktionierendem Zertifikat erscheint und wie Sie ihn beseitigen.

Wer ist für einen Mixed Content Fehler verantwortlich: Besucher, Website Betreiber oder Serveradmin?

Als Besucher haben Sie nichts falsch gemacht, denn der Fehler stammt von HTTP Adressen im Quelltext der Seite. Somit korrigiert der Website Betreiber oder die technische Person hinter der Seite den Inhalt. Der Serveradmin ist für Weiterleitungen und Sicherheits Header zuständig. Klären Sie zunächst Ihre Rolle, denn am falschen Ort zu suchen kostet nur Zeit.

Nutzen Sie ein Hosting Paket, liegt ein Teil der Servereinstellungen beim Anbieter. Deshalb ist ein Support Ticket der richtige Weg für jede Einstellung, die Sie im Panel nicht erreichen. Ebenso gehört die Korrektur der Adressen im Quellcode zu der Agentur oder Entwicklerin, die die Seite gebaut hat.

Was ist der Unterschied zwischen passivem und aktivem Mixed Content?

Passiver Mixed Content umfasst Bilder, Videos und Audio, die nicht mit der Seite interagieren. Aktiver Mixed Content umfasst dagegen Skripte, Stylesheets und iFrames, die das Verhalten der Seite ändern können. Laut web.dev kann ein Angreifer über aktive Inhalte die ganze Seite übernehmen. Deshalb blockieren moderne Browser aktive Inhalte standardmäßig.

Diese Einteilung folgt der MDN Dokumentation. Ein sauber aussehendes Bild beweist daher nicht, dass die Seite sauber ist. Denn der Browser kann es still aufgerüstet haben. Ein Skript auf derselben Seite bleibt dagegen HTTP und fällt der Blockade zum Opfer, sodass Funktionen ausfallen.

Welche Ursachen hat ein Mixed Content Fehler?

Die Ursache ist fast immer eine http:// Adresse aus der Vergangenheit. Ging die Seite auf HTTP online, tragen damals geschriebene Inhalte die alten Adressen. Später installieren Sie ein Zertifikat, und die Seite läuft auf HTTPS, während der Inhalt gleich bleibt. Deshalb haben ältere Websites das Problem häufiger als neue.

• Adressen von Beiträgen, Bildern und Einbettungen aus der HTTP Zeit.
• Fest eingetragene http:// Adressen im Theme oder in eigenem CSS.
• Von einer fremden Website kopierte und eingefügte Inhalte.
• Alte Domains oder Ressourcen Adressen in den Plugin Einstellungen.
• HTTP Adressen für ein CDN oder eine Subdomain.
• Unsichere Links aus Kommentaren, Formularen oder Nutzerinhalten.

Die Ursache zu kennen zeigt Ihnen also, wo die Korrektur ansetzt. Adressen in Beiträgen brauchen zum Beispiel einen Austausch in der Datenbank. Adressen im Theme erfordern dann eine Dateiänderung. Ein Proxy Problem verlangt dagegen eine Servereinstellung.

Warum blockieren Browser gemischte Inhalte?

Die Sperre soll daher verhindern, dass ein schwaches Glied den Schutz von HTTPS zunichtemacht. Denn eine Datei, die über HTTP ankommt, lässt sich unterwegs lesen oder verändern. MDN beschreibt das als Abhören und Man in the Middle Angriffe. Tauscht ein Angreifer ein Skript aus, ist somit die ganze Seite offen.

Bei passiven Inhalten ist das Risiko geringer, aber nicht null. Ein ausgetauschtes Bild kann zum Beispiel irreführende Informationen zeigen. Zudem kann schon die Anfrage verraten, auf welcher Seite sich der Besucher befindet. Deshalb versuchen Browser zuerst die Aufrüstung und warnen oder blockieren erst, wenn sie scheitert.

Als Betreiber sollten Sie daraus eines mitnehmen: Verlagern Sie die Ressource auf HTTPS, statt die Warnung zu verstecken. Eine versteckte Browser Warnung bringt nämlich keinerlei zusätzliche Sicherheit.

Wie finden Sie einen Mixed Content Fehler in der Browser Konsole?

Öffnen Sie die Seite in Chrome über HTTPS, drücken Sie F12 und sehen Sie sich die Tabs Console und Issues an. Laut web.dev listet der Tab Issues jede unsichere Ressource auf und zeigt, ob sie blockiert wurde. Firefox und Safari schreiben dagegen Meldungen in die Konsole. Gehen Sie dann so vor.

1. Öffnen Sie die Seite in einem privaten Fenster, denn Erweiterungen können die Konsole füllen.
2. Öffnen Sie die Entwicklertools und laden Sie die Seite hart neu.
3. Suchen Sie im Tab Console nach dem Begriff "Mixed Content".
4. Notieren Sie im Tab Issues Adresse und Typ jeder unsicheren Ressource.
5. Öffnen Sie den Seitenquelltext (Ctrl+U) und suchen Sie nach "http://".

Kennen Sie die Adresse, klären Sie als Nächstes die Herkunft. Steht sie im Inhalt, bearbeiten Sie dann den Beitrag. Kommt sie aus dem Theme, prüfen Sie stattdessen die Theme Dateien. Fügt ein Plugin sie ein, schauen Sie in die Plugin Einstellungen. Wiederholt sich eine Adresse auf vielen Seiten, brauchen Sie eine Sammelkorrektur, die wir weiter unten zeigen.

Eine Konsolenmeldung enthält drei Angaben: die aktuelle Seite, die angeforderte Ressource und den Ressourcentyp. Der Typ verrät, ob der Inhalt passiv oder aktiv ist. Bei aktiven Typen müssen Sie daher mit Funktionsausfall rechnen. Viele Zeilen von derselben Domain deuten außerdem auf eine einzige Einstellung als Quelle hin.

Bei welchen Seiten mit Mixed Content Fehler sollten Sie zuerst ansetzen?

Bei Tausenden Seiten ist es unrealistisch, alles auf einmal zu bereinigen. Legen Sie die Reihenfolge deshalb nach dem Schaden für Besucher und Umsatz fest. Seiten, auf denen Geld oder persönliche Daten fließen, stehen an erster Stelle. Danach folgen die Seiten mit dem meisten Traffic. Schließlich kommen die Archivinhalte.

Der Sammelaustausch erledigt die vierte Gruppe oft nebenbei. Prüfen Sie daher die ersten beiden Gruppen von Hand und starten Sie erst danach den Sammelauftrag. Diese Reihenfolge sichert somit die riskantesten Seiten vom ersten Tag an.

Wie suchen Sie eine ganze Website nach Mixed Content Fehlern ab?

Eine einzelne Seite zu finden ist leicht, hunderte Seiten von Hand durchzugehen dagegen mühsam. Kombinieren Sie deshalb Crawler Werkzeuge mit einer Datenbanksuche. MDN nennt zum Beispiel für diese Prüfung Werkzeuge wie LinkChecker und mcdetect. Außerdem deckt die Suche nach "http://" in der Datenbank die meisten Quellen schnell auf.

• Crawlen Sie Ihre Seiten mit einem Werkzeug und listen Sie die HTTP Ressourcen auf.
• Zählen Sie in der Datenbank die Inhalts und Meta Einträge mit "http://".
• Durchsuchen Sie Theme und Plugin Dateien nach fest eingetragenen Adressen.
• Bestätigen Sie, dass Sitemap und Canonical Adressen HTTPS nutzen.

Wenn Sie zusätzlich tote Links bereinigen möchten, hilft unser Broken Link Checker bei dieser Aufgabe. Er ersetzt die Konsolenprüfung nicht, ergänzt sie aber vor allem sinnvoll.

Funktionieren Zertifikat und HTTPS Weiterleitung, bevor Sie starten?

Bevor Sie Mixed Content bereinigen, prüfen Sie, ob das Zertifikat gültig ist. Ein abgelaufenes oder auf die falsche Domain ausgestelltes Zertifikat erzeugt eine andere Warnung. Diese Warnung ist ein ganzseitiger Browser Fehler und keine Zeile in der Konsole, denn sie betrifft das Zertifikat. Verwechseln Sie beide Probleme, leidet die Diagnose.

Den Zertifikatsstatus können Sie zudem mit unserem SSL Check prüfen. Betreiben Sie dagegen viele Subdomains, erklärt unser Beitrag zum Wildcard Zertifikat, welchen Zertifikatstyp Sie brauchen. Eine Subdomain, die das Zertifikat nicht abdeckt, kann für sich allein eine Mixed Content Quelle sein.

Testen Sie danach, ob die HTTP Adresse auf HTTPS weiterleitet. Ohne Weiterleitung lebt derselbe Inhalt unter zwei Adressen, und manche Besucher öffnen die unsichere. Die Einrichtung behandeln wir daher im Serverabschnitt. Zur SEO Seite von Weiterleitungen lesen Sie unseren Beitrag zur Weiterleitungskette.

In welcher Reihenfolge beheben Sie einen Mixed Content Fehler?

Die Reihenfolge ist wichtig, denn eine Korrektur in falscher Abfolge erzeugt doppelte Arbeit. Zunächst prüfen Sie das Zertifikat, dann beheben Sie die Quelle, und zuletzt ergänzen Sie das Sicherheitsnetz. Kontrollieren Sie also nach jedem Schritt die Konsole erneut. So sehen Sie konkret, welcher Schritt tatsächlich gewirkt hat.

1. Prüfen Sie, ob das Zertifikat gültig ist und HTTP auf HTTPS weiterleitet.
2. Listen Sie die unsicheren Ressourcen in der Konsole auf und gruppieren Sie sie nach Typ.
3. Erstellen Sie ein Backup und tauschen Sie die Adressen im Inhalt gesammelt aus.
4. Korrigieren Sie Adressen in Theme, Plugins und eigenem Code von Hand.
5. Nutzen Sie bei externen Ressourcen die HTTPS Version oder entfernen Sie die Ressource.
6. Ergänzen Sie den CSP Header upgrade-insecure-requests als Sicherheitsnetz.
7. Leeren Sie alle Caches und testen Sie die Seiten erneut.

Die folgenden Abschnitte gehen diese Schritte daher der Reihe nach durch. Bei großen mehrsprachigen Seiten planen Sie für jeden Schritt eigene Zeit ein.

Wie beheben Sie einen Mixed Content Fehler in WordPress?

In WordPress prüfen Sie zuerst, ob die Felder "WordPress Adresse (URL)" und "Website Adresse (URL)" unter Einstellungen, Allgemein mit https:// beginnen. Diese beiden Felder bilden nämlich die Basis für die Adressen, die Theme und Plugins erzeugen. Stehen dort noch http:// Adressen, erscheinen viele Ressourcen unsicher. Nach der Änderung müssen Sie sich zudem eventuell neu anmelden.

Danach prüfen Sie Theme und Plugins. Fest eingetragene http:// Adressen können in den Theme Einstellungen, im Customizer oder in Page Builder Plugins stehen bleiben. Sehen Sie sich zum Beispiel Logo, Hintergrundbilder und eigenes CSS einzeln an. Manche dieser Adressen liegen allerdings an Stellen, die ein Datenbank Austausch nicht erreicht.

• Bestätigen Sie, dass beide Adressen in den allgemeinen Einstellungen mit https:// beginnen.
• Prüfen Sie Logo und Hintergrund Adressen im Theme Customizer.
• Durchsuchen Sie eigenes CSS und Widget Bereiche nach http:// Adressen.
• Aktualisieren Sie alte Adressen in den Plugin Einstellungen.
• Leeren Sie das Cache Plugin und den CDN Cache.

Entscheiden Sie gerade über die Gesamtarchitektur, bietet unser Vergleich WordPress oder individuelle Website einen Rahmen. Erstellen Sie außerdem vor jeder Änderung ein Backup. Für den Plan dazu lesen Sie unsere Website Backup Strategie.

Wie tauschen Sie http:// Adressen in der Datenbank gesammelt aus?

Alte Adressen im Inhalt liegen in der Datenbank, deshalb braucht eine Sammelkorrektur ein Suchen und Ersetzen. Für WordPress ist der sicherste Weg der Befehl wp search-replace von WP CLI. Laut der WP CLI Dokumentation behandelt der Befehl serialisierte PHP Daten intelligent und ändert keine Primärschlüssel. Ein einfaches SQL REPLACE kann serialisierte Daten beschädigen, deshalb empfehlen wir es nicht.

Erstellen Sie zuerst ein Datenbank Backup und simulieren Sie die Änderung danach. Im Beispiel unten ersetzen Sie also example.com durch Ihre eigene Domain. Die Befehle führen Sie per SSH im WordPress Ordner aus.

wp db export vor-der-aenderung.sql
wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid --dry-run
wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid

Der erste Befehl schreibt das Backup in eine Datei. Der zweite zeigt dann mit --dry-run einen Bericht, speichert aber nichts in der Datenbank. Zeigt der Bericht die erwartete Zahl an Änderungen, führen Sie dann den dritten Befehl aus. Die Option --skip-columns=guid schützt die dauerhaften Kennungs Adressen Ihrer Beiträge. Das Beispiel folgt der Befehlsstruktur der WP CLI Dokumentation.

Eventuell müssen Sie außerdem die Versionen mit und ohne www getrennt ersetzen. Außerdem erweitert die Option --all-tables den Umfang, wenn Ihr Tabellenpräfix abweicht. Sie berührt alle Tabellen, nutzen Sie sie daher nur mit Backup.

Ist es sicher, Mixed Content mit einem Plugin zu beheben?

Kurz gesagt: Ein Plugin ist ein schneller Notbehelf und keine dauerhafte Lösung. Manche Plugins schreiben bei jeder Anfrage http:// Adressen in der Seitenausgabe auf https:// um. Das versteckt das Problem, behebt aber die Quelle nicht, also bleibt der Fehler. Entfernen Sie das Plugin, kehrt der Fehler zurück, und jede Seite zahlt einen kleinen Rechenaufwand.

Plugins für Suchen und Ersetzen in der Datenbank erledigen im Dashboard, was WP CLI auf der Kommandozeile tut. Wählen Sie daher eines, das serialisierte Daten unterstützt, und erstellen Sie vorher ein Backup. Ein bestimmtes Produkt empfehlen wir nicht, denn die Wahl hängt von Ihrem Aufbau ab.

Kurz gesagt ist diese Reihenfolge am gesündesten: Beheben Sie zuerst die Quelle und ergänzen Sie danach den CSP Header als Sicherheitsnetz. Ein Plugin nutzen Sie nur in der Übergangszeit.

Wie behebt die CSP Direktive upgrade-insecure-requests einen Mixed Content Fehler?

Die Direktive upgrade-insecure-requests ist eine Content Security Policy Einstellung, die den Browser anweist, jede http:// Adresse wie eine https:// Adresse zu behandeln. Laut MDN ist sie für Websites mit vielen unsicheren Altadressen gedacht. Sie rüstet zudem Unterressourcen der eigenen Domain und von Dritten auf. Daher müssen Sie nicht jede Adresse im Code einzeln korrigieren.

Content-Security-Policy: upgrade-insecure-requests;

Den Header ergänzen Sie in der Serverkonfiguration. Ein Meta Tag im HTML geht auch, der Header ist aber der stabilere Weg. Bei Apache genügt zum Beispiel eine Zeile, wenn mod_headers aktiv ist. Bei Nginx schreiben Sie ebenfalls eine einzige Zeile. Das Beispiel zeigt nur den Wert der Direktive, passen Sie es an Ihre Konfiguration an.

# Apache (braucht mod_headers)
Header always set Content-Security-Policy "upgrade-insecure-requests"

# Nginx (im server Block)
add_header Content-Security-Policy "upgrade-insecure-requests" always;

Beachten Sie die Grenze: Existiert die Ressource nicht über HTTPS, scheitert die Anfrage, und der Browser fällt nicht auf HTTP zurück. Die Direktive ersetzt außerdem HSTS nicht. MDN rät, den Header Strict-Transport-Security separat zu setzen, um SSL Stripping bei der Navigation auf oberster Ebene zu stoppen. Zum Testen können Sie dann den Header Content-Security-Policy-Report-Only parallel einsetzen.

Behebt eine .htaccess oder Server Weiterleitung den Mixed Content Fehler?

Nein, nicht allein, denn das Problem liegt im Seiteninhalt. Eine Weiterleitung von HTTP auf HTTPS sorgt dafür, dass der Besucher die Seite über HTTPS betritt. Die http:// Ressourcen Adressen innerhalb der Seite beurteilt allerdings der Browser selbst. Eine blockierbare Ressource blockiert er also, ohne den Server zu fragen. Eine Weiterleitung ist also nötig, reicht aber nicht aus.

Die Apache Dokumentation empfiehlt ein Redirect in einem eigenen HTTP Virtual Host als sauberste Lösung. Haben Sie keinen Zugriff auf die Serverkonfiguration, gibt es für die .htaccess eine Alternative mit mod_rewrite. Bei Nginx nutzen Sie return 301.

# Apache Virtual Host (bevorzugt)
<VirtualHost *:80>
    ServerName www.example.com
    Redirect permanent "/" "https://www.example.com/"
</VirtualHost>

# Apache .htaccess Alternative
RewriteEngine On
RewriteCond "%{HTTPS}" !=on
RewriteRule "^(.*)" "https://%{SERVER_NAME}$1" [R=301,L]

# Nginx
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

Die Apache Beispiele stammen aus dem Rezept "Forcing HTTPS" der offiziellen Dokumentation. Der Code 301 teilt Suchmaschinen mit, dass die HTTPS Version die dauerhafte Adresse ist. web.dev gibt denselben Rat. Geraten Sie in eine Redirect Schleife, sitzt meist ein CDN oder Proxy vor einem Server, der HTTPS nicht erkennt.

Wie hängen Mixed Content und HSTS zusammen?

HSTS (HTTP Strict Transport Security) ist ein Antwort Header, der Browser anweist, sich immer per HTTPS mit Ihrer Website zu verbinden. Laut web.dev bleibt HTTPS damit auch dann aktiv, wenn ein Besucher einem http:// Link folgt, und SSL Stripping Angriffe laufen ins Leere. Zudem sinkt die Verzögerung durch Weiterleitungen.

HSTS löst Mixed Content nicht allein, weil es die Ressourcen Adressen innerhalb der Seite nicht korrigiert. Es sichert allerdings den Seiteneinstieg. CSP deckt die Unterressourcen ab, HSTS den Einstieg. Beide ergänzen sich also.

Seien Sie jedoch vorsichtig: HSTS einzuschalten lässt sich schwer rückgängig machen. Der Browser merkt sich die Regel nämlich für den eingestellten Zeitraum. Wenden Sie die Regel auch auf Subdomains an und eine davon liefert kein HTTPS, erreichen Besucher sie nicht mehr. Testen Sie daher zunächst mit kurzem Zeitraum und stellen Sie sicher, dass jede Subdomain über HTTPS läuft. Sind Sie unsicher, fragen Sie Ihren Anbieter nach dieser Einstellung.

Wie entsteht Mixed Content hinter CDN, Reverse Proxy oder Load Balancer?

Beendet ein CDN oder Load Balancer HTTPS und spricht danach per HTTP mit Ihrem Server, hält sich die Anwendung womöglich für unverschlüsselt. Dann erzeugen Anwendungen wie WordPress Seitenadressen mit http://. Der Besucher kommt über HTTPS an, die Adressen im Inneren sind dennoch unsicher. So entsteht Mixed Content.

Die WordPress Dokumentation nennt für diesen Fall ein Konfigurationsbeispiel, das den Proxy Header liest. Sieht der Server https im Header X-Forwarded-Proto, teilt er der Anwendung mit, dass sie auf HTTPS läuft. Das Beispiel in der Datei wp-config.php passen Sie an Ihre eigene Infrastruktur an.

define( 'FORCE_SSL_ADMIN', true );
if( strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false )
    $_SERVER['HTTPS'] = 'on';

Setzen Sie diesen Code an die falsche Stelle, sperren Sie sich womöglich aus dem Admin Bereich aus. Kopieren Sie daher zuerst die Datei. Das Panel Ihres CDN bietet eventuell Optionen für HTTPS Weiterleitung und automatisches Umschreiben. Die Namen unterscheiden sich je nach Anbieter, schauen Sie also in dessen Dokumentation.

Wie beheben Sie einen Mixed Content Fehler bei externen Ressourcen?

Externe Ressourcen liegen nicht in Ihrer Hand, deshalb brauchen sie eine eigene Strategie. Zum Beispiel gehören Schriften, Werbecode, Widgets, eingebettete Videos und alte Partner Links dazu. Probieren Sie zunächst die Adresse mit https://, um zu sehen, ob es eine HTTPS Version gibt. Die meisten Anbieter liefern heute HTTPS, dann genügt der Adresswechsel.

• Gibt es eine HTTPS Version, aktualisieren Sie die Adresse auf https://.
• Erneuern Sie eingebettete iFrame Adressen über den aktuellen Einbettungscode des Anbieters.
• Entfernen Sie eine Ressource ohne HTTPS Unterstützung oder ersetzen Sie sie durch eine gleichwertige.
• Erlaubt die Lizenz es, hosten Sie die Datei selbst.

Gibt es keine HTTPS Version, hilft auch die CSP Aufrüstung nicht, denn die Anfrage scheitert. Eine solche Ressource auf der Seite zu behalten, ist daher für Sicherheit und Funktion riskant. Für das größere Sicherheitsbild lesen Sie unseren Beitrag zu den OWASP Top 10.

Warum tritt ein Mixed Content Fehler in Onlineshops häufiger auf?

In einem Onlineshop stammen Inhalte nicht von einem Ort, daher überleben alte Adressen leichter. Produktbilder kommen aus einer Lieferanten XML Datei, Beschreibungen aus einem Sammelimport und Banner aus Kampagnen Werkzeugen. Jeder Kanal bringt zudem sein eigenes Adressformat mit. Ein importiertes Produktbild kann zum Beispiel mit http:// gespeichert sein.

Auf Warenkorb und Kassenseiten kostet der Fehler mehr, denn ein Besucher mit Warnung bricht die Zahlung womöglich ab. Wird das eingebettete Formular des Zahlungsanbieters per HTTP aufgerufen, lädt es unter Umständen gar nicht. Testen Sie Warenkorb, Kasse und Kundenkonto daher getrennt.

Zur Geschwindigkeit und Conversion lesen Sie unseren Beitrag, ob die Ladezeit im Onlineshop den Umsatz beeinflusst. Möchten Sie die technische und die kaufmännische Seite Ihres Shops gemeinsam angehen, deckt unsere E-Commerce Beratung diese Themen ab.

Wie bestätigen Sie, dass der Mixed Content Fehler verschwunden ist?

Die Prüfung bedeutet also nicht, nur die Startseite anzusehen. Testen Sie verschiedene Seitentypen und verschiedene Geräte. Ein Cache kann weiter die alte Version zeigen, leeren Sie ihn also vor jeder Kontrolle. Arbeiten Sie dann die Liste der Reihe nach ab.

1. Leeren Sie Website Cache und CDN Cache.
2. Öffnen Sie in einem privaten Fenster Startseite, einen Beitrag, ein Produkt und den Warenkorb.
3. Bestätigen Sie, dass die Tabs Console und Issues auf jeder Seite sauber sind.
4. Prüfen Sie, dass das Schlosssymbol vollständig erscheint.
5. Testen Sie mindestens eine Seite erneut auf einem Mobilgerät.
6. Prüfen Sie die HTTPS Property und die Sitemap in der Google Search Console.

Für die Suchseite zeigt Ihnen unsere Anleitung zur Google Search Console, wie Sie die Berichte lesen. Canonical Tags, interne Links und Sitemap Adressen sollten ebenfalls HTTPS nutzen. Sonst crawlen Suchmaschinen weiter die alte Version.

Wann sollten Sie einen Mixed Content Fehler nicht selbst beheben?

Ehrlich gesagt ist es manchmal klüger, das Problem Ihrem Hosting Anbieter oder einer erfahrenen Entwicklerin zu überlassen. Wir sind ein Team für digitales Marketing und Web, kein Hosting Unternehmen. Die Befehle in diesem Ratgeber folgen zwar der offiziellen Dokumentation. Trotzdem kann ein falscher Befehl auf einer Live Seite echten Schaden anrichten.

• Ohne Datenbank Backup führen Sie kein Suchen und Ersetzen aus.
• Fehlen SSH Zugang oder Erfahrung mit der Kommandozeile, bitten Sie Ihren Anbieter um Hilfe.
• Können Sie den Server Header im Shared Hosting nicht setzen, öffnen Sie ein Ticket.
• Bricht die Kassenseite, testen Sie die Änderung zuerst auf einer Staging Kopie.
• Sind Sie unsicher, was sich in der wp-config.php oder einer Serverdatei ändert, hören Sie auf.

Ihre Hosting Wahl macht diese Arbeit also leichter oder schwerer. Details finden Sie in unserem Beitrag, wie Sie Webhosting auswählen. Bei Sperren durch eine Firewall hilft außerdem unser Beitrag zu ModSecurity und 403 Fehlern.

Mit welchen Gewohnheiten beugen Sie einem Mixed Content Fehler vor?

Die billigste Lösung ist also, das Problem gar nicht erst zu erzeugen. Schreiben Sie bei neuen Inhalten jede Adresse mit https://. Für Ressourcen auf derselben Domain können Sie außerdem relative Adressen nutzen. Machen Sie außerdem die Konsolenprüfung nach großen Arbeiten wie Umzug oder Theme Wechsel zur Routine.

• Prüfen Sie vor der Veröffentlichung neuer Inhalte die Konsole in der Vorschau.
• Wählen Sie bei jedem fremden Einbettungscode die HTTPS Version.
• Behalten Sie den CSP Header upgrade-insecure-requests als Sicherheitsnetz.
• Erwägen Sie, Verstöße im Report Only Modus zu sammeln.
• Kontrollieren Sie die Adressen, bevor Sie eine Staging Änderung live schalten.

Möchten Sie technische Bereinigung, SEO und Designentscheidungen gemeinsam steuern, arbeiten unsere SEO Beratung und unser Webdesign in diesem Rahmen. Erfordert ein Thema Fachwissen, unterstützt unser Team dann den Prozess. Als Quellen eignen sich die MDN Dokumentation zu Mixed Content und der web.dev Mixed Content Ratgeber. Dieser Ratgeber ersetzt keine Rechts oder Unternehmenssicherheitsberatung.