Eine WordPress-Seite lädt über HTTPS, doch ein responsives Bild wird auf Mobilgeräten weiterhin per HTTP angefordert. Am Desktop fällt der Fehler nicht auf, weil der Browser eine andere Variante aus srcsetauswählt oder die Anfrage automatisch hochstuft.
Mixed Content verschwindet dauerhaft nur, wenn die Quelle der unsicheren URL korrigiert wird. Dazu gehören Beitragsinhalt, Attachment-Metadaten, CSS, Builder-Felder, CDN-Umschreibungen und externe Bilddienste.
- Was das Thema bedeutet
- Ein realistisches WordPress-Beispiel
- Warum es wichtig ist und wann es eingesetzt wird
- Der einfache Weg für Einsteiger
- Der technische Weg
- Risiken, häufige Fehler, Backup und Rollback
- Wie AIOWS unterstützt: AIOWS SSL Manager
- Passende AIOWS-Artikel
- Fazit und empfohlener Weg
- Offizielle Quellen
Was Mixed Content bei Bildern ist
Mixed Content entsteht, wenn ein HTTPS-Dokument eine Bilddatei über http://anfordert. Browser können solche Anfragen blockieren oder automatisch auf HTTPS umstellen. Die zugrunde liegende Adresse bleibt dennoch falsch und kann in anderen Browsern, RSS-Feeds oder Social Cards weiterhin Probleme verursachen.
Die URL kann aus src, einem srcset-Kandidaten, einer CSS-Hintergrundgrafik, Theme-Option, einem Widget oder einer externen CDN-Regel stammen. Eine Seitenweiterleitung ändert diese Ressourcenadressen nicht automatisch.
Ein realistisches WordPress-Beispiel
Nach einem Domainwechsel wurde das sichtbare srceines Titelbilds korrigiert. In den gespeicherten Attachment-Daten steht jedoch noch eine alte URL, aus der WordPress einen mobilen srcset-Kandidaten erzeugt. Deshalb tritt die Warnung nur bei schmalem Viewport auf.
Der Administrator korrigiert die Basisdaten mit einem serialisierungssicheren Werkzeug, erzeugt die Bildgrößen neu und leert anschließend den relevanten Seiten- und CDN-Cache. Danach enthalten alle Varianten HTTPS-Adressen.
Warum die genaue Quelle zählt
Wiederholtes Cache-Leeren oder ein Redirect von HTTP auf HTTPS verdeckt die Ursache und erzeugt zusätzliche Anfragen. Eine globale Ersetzung aller http://-Vorkommen kann dagegen fremde URLs oder serialisierte Daten beschädigen.
Die genaue Zuordnung ist besonders nach Domainwechseln, HTTPS-Migrationen oder Änderungen an Bildoptimierung und CDN wichtig. Prüfen Sie immer die vom Browser tatsächlich ausgewählte Ressource.
Der einfache Weg für Einsteiger
- Öffnen Sie die betroffene Seite privat und lesen Sie die genaue URL in Konsole oder Netzwerkansicht.
- Prüfen Sie, ob die HTTPS-Version der Bilddatei direkt erreichbar ist.
- Wählen Sie bei einem einzelnen Bild die Datei im Editor erneut aus der Mediathek.
- Kontrollieren Sie
src,srcsetund CSS-Hintergründe. - Leeren Sie erst nach der Korrektur die betroffenen Caches.
- Testen Sie Desktop- und Mobilbreite sowie eine zweite Seite derselben Vorlage.
Der technische Weg
Ordnen Sie jede unsichere Anfrage ihrem Initiator zu. Vergleichen Sie Origin-HTML, Editorwert, Attachment-Datensatz, Theme- oder Builder-Option und die endgültige CDN-URL. Taucht die Adresse nur in einer Cache-Datei auf, muss zuerst die Origin-Ausgabe geprüft werden.
- Regenerieren Sie responsive Größen erst nach korrekter Upload- und Domainbasis.
- Ändern Sie keine minifizierte CSS-Datei, sondern ihre eigentliche Quelle.
- Übernehmen Sie externe Bilder in die Mediathek, wenn der Anbieter kein gültiges HTTPS bietet.
- Prüfen Sie zusätzlich Lazy Loading, WebP/AVIF, RSS und Social-Media-Metadaten.
Risiken, häufige Fehler, Backup und Rollback
Blinder Datenbankersatz kann serialisierte Werte beschädigen. Protocol-relative URLs verschleiern die Zuständigkeit, und das frühe Löschen alter Attachments kann historische Beiträge brechen.
- Sichern Sie Datenbank und betroffene Mediendaten vor einer Massenkorrektur.
- Begrenzen Sie Ersetzungen auf den bekannten alten Host.
- Bewahren Sie die Zuordnung der Attachment-IDs.
- Rollen Sie zurück, wenn Galerien oder responsive Varianten nach der Änderung fehlen.
Wie AIOWS unterstützt:
AIOWS SSL Manager
AIOWS SSL Manager unterstützt die WordPress-seitige Prüfung des HTTPS-Zustands und hilft damit, ein allgemeines SSL-Konfigurationsproblem von einer einzelnen unsicheren Bildadresse zu unterscheiden. Verwenden WordPress-Adresse und Website-Adresse bereits HTTPS, kann die Suche gezielt bei Inhalt, Metadaten oder CDN beginnen.
Erfassen Sie die konkrete HTTP-Bild-URL aus dem Browser und prüfen Sie die Origin-Ausgabe. Kontrollieren Sie anschließend mit SSL Manager die unterstützten WordPress-HTTPS-Einstellungen und testen Sie die Seite erneut ohne Admin-Cookies. Die eigentliche Bildreferenz muss weiterhin an ihrer Quelle korrigiert werden – etwa im Editor, in Attachment-Daten, im Theme oder beim externen Bildanbieter.
Das Modul ersetzt keine serialisierungssichere Datenmigration, regeneriert keine Bildgrößen und kann kein fehlendes Zertifikat eines Drittanbieters reparieren. Sichern Sie daher vor größeren Ersetzungen die Datenbank und halten Sie die alte Hostzuordnung fest. Wenn nach der Änderung Bilder fehlen oder falsche Varianten erscheinen, stellen Sie die betroffenen Daten wieder her und korrigieren die Quelle enger. AIOWS ist hier vor allem für die Abgrenzung und anschließende HTTPS-Prüfung relevant; ein sauberer Endzustand enthält ausschließlich direkt erreichbare sichere Bild-URLs.
Passende AIOWS-Artikel
- WordPress trotz SSL nicht sicher: Vollständige Fehlerbehebung
- Mixed-Content bei CSS und JavaScript in WordPress beheben
- WordPress-Formulare und AJAX durch Mixed Content blockiert
Fazit und empfohlener Weg
Reparieren Sie die Quelle jeder Bildadresse, nicht nur die sichtbare Anfrage. Prüfen Sie src, sämtliche srcset-Kandidaten, CSS und Metadaten über HTTPS und verwenden Sie Redirects höchstens vorübergehend.
