{"id":1998,"date":"2026-04-13T10:05:33","date_gmt":"2026-04-13T07:05:33","guid":{"rendered":"https:\/\/allinonewpsettings.com\/blog\/?p=1998"},"modified":"2026-08-02T12:09:02","modified_gmt":"2026-08-02T12:09:02","slug":"wordpress-formulare-und-ajax-durch-mixed-content-blockiert","status":"publish","type":"post","link":"https:\/\/allinonewpsettings.com\/blog\/de\/wordpress-formulare-und-ajax-durch-mixed-content-blockiert\/","title":{"rendered":"WordPress-Formulare und AJAX durch Mixed Content blockiert"},"content":{"rendered":"

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\u00fcr admin-ajax.php<\/code>, die REST API oder einen externen Dienst aufruft. Die Anfrage erreicht WordPress dann oft gar nicht.<\/p>\n

Dieser Beitrag zeigt, wie Sie den unsicheren Endpunkt finden, die zust\u00e4ndige Konfiguration korrigieren und anschlie\u00dfend den vollst\u00e4ndigen Formularablauf testen.<\/p>\n

\nInhaltsverzeichnis<\/strong><\/p>\n
    \n
  1. Was das Thema bedeutet<\/a><\/li>\n
  2. Ein realistisches WordPress-Beispiel<\/a><\/li>\n
  3. Warum es wichtig ist und wann es eingesetzt wird<\/a><\/li>\n
  4. Der einfache Weg f\u00fcr Einsteiger<\/a><\/li>\n
  5. Der technische Weg<\/a><\/li>\n
  6. Risiken, h\u00e4ufige Fehler, Backup und Rollback<\/a><\/li>\n
  7. Wie AIOWS unterst\u00fctzt: AIOWS SSL Manager<\/a><\/li>\n
  8. Passende AIOWS-Artikel<\/a><\/li>\n
  9. Fazit und empfohlener Weg<\/a><\/li>\n
  10. Offizielle Quellen<\/a><\/li>\n<\/ol>\n<\/div>\n

    Was Mixed Content bei Formularen und AJAX bedeutet<\/h2>\n

    Mixed Content entsteht, wenn eine per HTTPS geladene Seite eine Ressource oder Anfrage \u00fcber HTTP startet. Bei Formularen betrifft das h\u00e4ufig die Formular-Action, Fetch- oder XHR-Aufrufe, die WordPress REST API, admin-ajax.php<\/code>, Captcha-Dienste oder Zahlungsintegrationen. Moderne Browser blockieren solche aktiven Inhalte aus Sicherheitsgr\u00fcnden.<\/p>\n

    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.<\/p>\n

    Realistisches WordPress-Beispiel<\/h2>\n

    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<\/code>. In einer alten Plugin-Option ist noch die HTTP-Adresse gespeichert; im gecachten JavaScript wird sie weiterhin an den Browser ausgegeben.<\/p>\n

    Nach der Korrektur der Option werden Seiten- und CDN-Cache geleert. Ein neuer Test im privaten Browserfenster sendet die Anfrage \u00fcber HTTPS, WordPress validiert Nonce und Felder, und die vorgesehene Best\u00e4tigung wird genau einmal ausgel\u00f6st.<\/p>\n

    Warum eine genaue Abgrenzung wichtig ist<\/h2>\n

    Eine blockierte HTTP-Anfrage hinterl\u00e4sst m\u00f6glicherweise keinen Eintrag im WordPress- oder Serverprotokoll. Wer nur dort sucht, h\u00e4lt das Problem leicht f\u00fcr einen Plugin- oder Mailfehler. Browserkonsole und Netzwerk-Tab zeigen dagegen, ob die Anfrage den Client \u00fcberhaupt verlassen hat und welches Skript sie gestartet hat.<\/p>\n

    Eine HTTPS-Anfrage kann anschlie\u00dfend noch an CORS, einer ung\u00fcltigen 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\u00e4ftsablauf muss danach gesondert best\u00e4tigt werden.<\/p>\n

    Der einfache Weg f\u00fcr Einsteiger<\/h2>\n

    \u00d6ffnen 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\u00dfend in Formular- und Plugin-Einstellungen nach genau dieser HTTP-Adresse.<\/p>\n

    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\u00fcfen Sie neben der erfolgreichen Antwort auch Best\u00e4tigung, E-Mail oder Zahlungseffekt, damit der Vorgang weder ausf\u00e4llt noch doppelt ausgef\u00fchrt wird.<\/p>\n

    Technische Diagnose<\/h2>\n

    Erfassen Sie im Netzwerk-Tab Request-URL, Methode, Payload, Status, Initiator und Antwort. Suchen Sie im HTML und in geladenen Skripten nach http:\/\/<\/code>, der alten Domain, admin-ajax.php<\/code> und wp-json<\/code>. Pr\u00fcfen Sie lokalisierte JavaScript-Daten, fest codierte URLs, Service Worker sowie Seiten-, Objekt- und CDN-Caches.<\/p>\n

    Hinter Reverse Proxy oder Load Balancer muss WordPress HTTPS anhand der vom Anbieter vorgesehenen vertrauensw\u00fcrdigen Header erkennen. Andernfalls erzeugt die Anwendung trotz sicherer Au\u00dfenverbindung 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.<\/p>\n

    Risiken, h\u00e4ufige Fehler, Backup und Rollback<\/h2>\n

    Ein globales Ersetzen von HTTP-Adressen kann serialisierte Daten, externe Links oder nicht betroffene Integrationen besch\u00e4digen. Sichern Sie die relevante Konfiguration und \u00e4ndern Sie nur den nachgewiesenen URL-Erzeuger. Auf Checkout- und Kontoseiten kann aggressives Caching zus\u00e4tzlich veraltete Nonces oder Skriptdaten ausliefern.<\/p>\n

    Verwenden Sie f\u00fcr Tests keine echten Kundendaten und vermeiden Sie wiederholte Live-\u00dcbermittlungen, die Bestellungen, Nachrichten oder Zahlungen duplizieren k\u00f6nnten. Tritt nach der \u00c4nderung ein neuer Fehler auf, stellen Sie die gesicherte Option oder Datei wieder her und pr\u00fcfen Sie den bisherigen Kontrollweg erneut.<\/p>\n

    \n

    Wie AIOWS unterst\u00fctzt:<\/p>\n

    AIOWS SSL Manager<\/h2>\n

    Der AIOWS SSL Manager unterst\u00fctzt die Kontrolle der HTTPS-Konfiguration innerhalb von WordPress. Er hilft dabei, relevante WordPress-Einstellungen und ihren wirksamen Zustand an einer zentralen Stelle zu pr\u00fcfen. Das erleichtert die Einordnung, wenn die Anwendung selbst unsichere URLs erzeugt.<\/p>\n

    Das Modul ersetzt nicht die Browserdiagnose. Welches Skript eine Anfrage startet, ob der Browser sie blockiert und wie CORS oder CSP reagieren, l\u00e4sst sich nur im konkreten Request nachvollziehen. Auch Proxy-, CDN- und Serverkonfigurationen bleiben au\u00dferhalb der WordPress-Ebene und m\u00fcssen dort gepr\u00fcft werden.<\/p>\n

    Nutzen Sie den SSL Manager, nachdem Sie die blockierte Anfrage eindeutig identifiziert haben. Pr\u00fcfen Sie damit die unterst\u00fctzten WordPress-Einstellungen, nehmen Sie eine gezielte \u00c4nderung vor und best\u00e4tigen Sie anschlie\u00dfend den Ablauf im privaten Browserfenster. So erg\u00e4nzt das Modul die technische Fehlersuche, ohne die Ursache auf der falschen Ebene zu vermuten.<\/p>\n

    AIOWS SSL Manager ansehen<\/a>AIOWS-Tarife vergleichen<\/a><\/p>\n<\/section>\n

    Passende AIOWS-Artikel<\/h2>\n