Die Kontaktseite wird per HTTPS geladen, doch beim Absenden passiert nichts. In der Browserkonsole steht eine Mixed-Content-Warnung, weil das Formular eine HTTP-Adresse für admin-ajax.php, die REST API oder einen externen Dienst aufruft. Die Anfrage erreicht WordPress dann oft gar nicht.
Dieser Beitrag zeigt, wie Sie den unsicheren Endpunkt finden, die zuständige Konfiguration korrigieren und anschließend den vollständigen Formularablauf testen.
- 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 Formularen und AJAX bedeutet
Mixed Content entsteht, wenn eine per HTTPS geladene Seite eine Ressource oder Anfrage über HTTP startet. Bei Formularen betrifft das häufig die Formular-Action, Fetch- oder XHR-Aufrufe, die WordPress REST API, admin-ajax.php, Captcha-Dienste oder Zahlungsintegrationen. Moderne Browser blockieren solche aktiven Inhalte aus Sicherheitsgründen.
Das Problem liegt daher nicht zwingend im Formular selbst. Entscheidend ist, welche Komponente die HTTP-Adresse erzeugt: eine WordPress-Option, ein Plugin, das Theme, lokalisiertes JavaScript, ein Cache oder eine fehlerhafte HTTPS-Erkennung hinter einem Proxy.
Realistisches WordPress-Beispiel
Auf einer HTTPS-Kontaktseite erscheint das Formular korrekt. Beim Absenden zeigt der Netzwerk-Tab jedoch einen blockierten Aufruf von http://example.com/wp-admin/admin-ajax.php. In einer alten Plugin-Option ist noch die HTTP-Adresse gespeichert; im gecachten JavaScript wird sie weiterhin an den Browser ausgegeben.
Nach der Korrektur der Option werden Seiten- und CDN-Cache geleert. Ein neuer Test im privaten Browserfenster sendet die Anfrage über HTTPS, WordPress validiert Nonce und Felder, und die vorgesehene Bestätigung wird genau einmal ausgelöst.
Warum eine genaue Abgrenzung wichtig ist
Eine blockierte HTTP-Anfrage hinterlässt möglicherweise keinen Eintrag im WordPress- oder Serverprotokoll. Wer nur dort sucht, hält das Problem leicht für einen Plugin- oder Mailfehler. Browserkonsole und Netzwerk-Tab zeigen dagegen, ob die Anfrage den Client überhaupt verlassen hat und welches Skript sie gestartet hat.
Eine HTTPS-Anfrage kann anschließend noch an CORS, einer ungültigen Nonce, fehlenden Feldern oder einer Serverantwort scheitern. Diese Fehler erfordern eine andere Diagnose. Die Mixed-Content-Warnung ist erst behoben, wenn der Browser den vorgesehenen sicheren Endpunkt aufruft; der erfolgreiche Geschäftsablauf muss danach gesondert bestätigt werden.
Der einfache Weg für Einsteiger
Öffnen Sie die Seite in einem privaten Browserfenster und aktivieren Sie in den Entwicklertools die Bereiche Konsole und Netzwerk. Senden Sie das Formular mit harmlosen Testdaten ab. Notieren Sie bei der blockierten Anfrage URL, Initiator und Methode. Suchen Sie anschließend in Formular- und Plugin-Einstellungen nach genau dieser HTTP-Adresse.
Kontrollieren Sie in WordPress auch die WordPress- und Website-Adresse. Korrigieren Sie nur die eindeutig gefundene Quelle, leeren Sie danach die betroffenen Caches und wiederholen Sie den Test abgemeldet. Prüfen Sie neben der erfolgreichen Antwort auch Bestätigung, E-Mail oder Zahlungseffekt, damit der Vorgang weder ausfällt noch doppelt ausgeführt wird.
Technische Diagnose
Erfassen Sie im Netzwerk-Tab Request-URL, Methode, Payload, Status, Initiator und Antwort. Suchen Sie im HTML und in geladenen Skripten nach http://, der alten Domain, admin-ajax.phpund wp-json. Prüfen Sie lokalisierte JavaScript-Daten, fest codierte URLs, Service Worker sowie Seiten-, Objekt- und CDN-Caches.
Hinter Reverse Proxy oder Load Balancer muss WordPress HTTPS anhand der vom Anbieter vorgesehenen vertrauenswürdigen Header erkennen. Andernfalls erzeugt die Anwendung trotz sicherer Außenverbindung HTTP-URLs oder ungeeignete Cookies. Erreicht die HTTPS-Anfrage den Server, untersuchen Sie CORS, CSP, Nonce, Validierung und Antwortformat als getrennte Fehlerquellen. Deaktivieren Sie diese Schutzmechanismen nicht zur vermeintlichen Fehlerbehebung.
Risiken, häufige Fehler, Backup und Rollback
Ein globales Ersetzen von HTTP-Adressen kann serialisierte Daten, externe Links oder nicht betroffene Integrationen beschädigen. Sichern Sie die relevante Konfiguration und ändern Sie nur den nachgewiesenen URL-Erzeuger. Auf Checkout- und Kontoseiten kann aggressives Caching zusätzlich veraltete Nonces oder Skriptdaten ausliefern.
Verwenden Sie für Tests keine echten Kundendaten und vermeiden Sie wiederholte Live-Übermittlungen, die Bestellungen, Nachrichten oder Zahlungen duplizieren könnten. Tritt nach der Änderung ein neuer Fehler auf, stellen Sie die gesicherte Option oder Datei wieder her und prüfen Sie den bisherigen Kontrollweg erneut.
Wie AIOWS unterstützt:
AIOWS SSL Manager
Der AIOWS SSL Manager unterstützt die Kontrolle der HTTPS-Konfiguration innerhalb von WordPress. Er hilft dabei, relevante WordPress-Einstellungen und ihren wirksamen Zustand an einer zentralen Stelle zu prüfen. Das erleichtert die Einordnung, wenn die Anwendung selbst unsichere URLs erzeugt.
Das Modul ersetzt nicht die Browserdiagnose. Welches Skript eine Anfrage startet, ob der Browser sie blockiert und wie CORS oder CSP reagieren, lässt sich nur im konkreten Request nachvollziehen. Auch Proxy-, CDN- und Serverkonfigurationen bleiben außerhalb der WordPress-Ebene und müssen dort geprüft werden.
Nutzen Sie den SSL Manager, nachdem Sie die blockierte Anfrage eindeutig identifiziert haben. Prüfen Sie damit die unterstützten WordPress-Einstellungen, nehmen Sie eine gezielte Änderung vor und bestätigen Sie anschließend den Ablauf im privaten Browserfenster. So ergänzt das Modul die technische Fehlersuche, ohne die Ursache auf der falschen Ebene zu vermuten.
Passende AIOWS-Artikel
- WordPress trotz SSL nicht sicher: Vollständige Fehlerbehebung
- Mixed-Content-Bilder in WordPress beheben
- Mixed-Content bei CSS und JavaScript in WordPress beheben
Fazit
Bei blockierten Formularen und AJAX-Aufrufen führt die Browser-Netzwerkspur am schnellsten zur Ursache. Korrigieren Sie den konkreten HTTP-Endpunkt an seiner Quelle, lassen Sie Sicherheitsprüfungen aktiv und testen Sie anschließend den vollständigen Vorgang über HTTPS. Erst eine erfolgreiche, einmalige Übermittlung bestätigt die Lösung.
