Deine Website hat ein SSL-Zertifikat, läuft über HTTPS — und trotzdem zeigt der Browser kein sauberes Schloss, sondern eine Warnung: Mixed Content. Das heißt: Die Seite selbst kommt verschlüsselt, aber einzelne Ressourcen (Bilder, Skripte, Stylesheets) werden noch über unverschlüsseltes http:// geladen. Browser reagieren zunehmend streng: Skripte werden blockiert, Formulare angemeckert, Besucher verunsichert.
Die zwei Arten von Mixed Content
- Passiver Mixed Content (Bilder, Videos): Der Browser lädt sie meist noch, zeigt aber kein sicheres Schloss.
- Aktiver Mixed Content (JavaScript, CSS, iFrames): Wird von modernen Browsern komplett blockiert — Funktionen fallen kommentarlos aus. Wenn nach der HTTPS-Umstellung „irgendwas nicht mehr geht“, ist es fast immer das.
Quellen finden
- Browser-Konsole (F12): Der Tab „Konsole“ listet jede unsichere Ressource mit vollständiger URL auf:
Mixed Content: The page … was loaded over HTTPS, but requested an insecure resource 'http://…'. Damit weißt du exakt, was von wo geladen wird. - Seitenquelltext durchsuchen: Strg+U, dann nach
http://suchen — jeder Treffer in src- oder href-Attributen ist ein Kandidat. - Ganze Website scannen: Kostenlose Dienste wie „Why No Padlock“ oder ein Crawl mit Screaming Frog decken auch Unterseiten auf, die du nicht einzeln prüfst.
Ursachen beheben — von der Wurzel her
- WordPress-Adresse auf https stellen: Unter Einstellungen → Allgemein müssen beide URLs mit
https://beginnen. Das ist die Basis — solange hier http steht, erzeugt WordPress selbst unsichere Links. - Alt-URLs in der Datenbank ersetzen: In Jahren gewachsene Inhalte stecken voller absoluter http-Links auf die eigenen Bilder. Ein serialisierungssicheres Suchen-und-Ersetzen räumt auf:
wp search-replace 'http://deine-domain.de' 'https://deine-domain.de'. (Gleicher Handgriff wie beim Umzug.) - Hartkodierte URLs in Theme und Plugins: Ein http-Google-Font in der functions.php, ein altes Tracking-Skript im Header — der Konsolen-Eintrag zeigt die Quelle. In Theme-Dateien ersetzen (im Child Theme, damit Updates es nicht überschreiben).
- Externe Ressourcen ohne HTTPS: Bindet ein Dienst nur http an (uralte Widgets, exotische Skripte), gibt es zwei ehrliche Optionen: den Dienst ersetzen — oder auf ihn verzichten. Ein unsicheres Skript in eine sichere Seite zu holen ist keine Option.
- Serverseitige Weiterleitung erzwingen: Damit http-Aufrufe gar nicht erst ausgeliefert werden, gehört eine 301-Weiterleitung in die .htaccess:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Von Plugins wie Really Simple SSL — und ihren Grenzen
SSL-Plugins schreiben unsichere URLs zur Laufzeit um und lösen das Problem optisch sofort. Das ist als Übergang legitim — aber es bleibt ein Filter über kaputten Daten: Die http-URLs stehen weiter in der Datenbank, und fällt das Plugin aus, ist die Warnung zurück. Sauber ist die Reihenfolge: Datenbank bereinigen, Theme fixen, Weiterleitung setzen — dann braucht es kein Laufzeit-Pflaster mehr.
Nach der Umstellung
- Alle Caches leeren (Page Cache, CDN, Browser) — sonst spukt alter Mixed Content nach.
- Google Search Console: die https-Property prüfen, Sitemap neu einreichen.
- Konsole auf den wichtigsten Seitentypen erneut prüfen: Startseite, Artikel, Shop-Seiten.
Im Lex-Modul von Ammera Care prüfen wir SSL und die sichere Auslieferung deiner Website laufend mit — als Teil des DSGVO-Checks, denn unverschlüsselte Übertragung ist auch ein Datenschutzthema. Die Module ansehen.
