Kontaktformular funktioniert nicht? So finden Sie wirklich heraus, warum

„Mein Kontaktformular funktioniert nicht“ bedeutet meist eine von etwa sechs Sachen, und zu raten, welche, kostet mehr Zeit als sie zu prüfen. Der richtige Weg ist, die Ursachen nach Wahrscheinlichkeit durchzugehen - beginnend mit dem, was in kürzester Zeit am meisten verrät: was mit der Anfrage tatsächlich passiert ist, sobald sie den Browser verlassen hat.

1. Prüfen Sie, was die Anfrage tatsächlich getan hat

Öffnen Sie die Seite, öffnen Sie die Devtools, wechseln Sie zum Network-Tab und senden Sie das Formular selbst ab. Zwei Dinge gehen hier ständig schief:

• Die action-URL ist falsch - ein vertippter API-Schlüssel, eine von einem alten Formular kopierte und nie aktualisierte URL, oder (peinlich häufig) noch immer auf localhost aus der lokalen Entwicklung zeigend und nie auf Produktion umgestellt.
• Die Anfrage geht raus, kommt aber mit einem Fehlerstatus zurück. Sie müssen nicht die genaue Bedeutung jedes Codes kennen - eine 4xx- oder 5xx-Antwort genügt, um zu wissen, dass das Problem auf der Empfängerseite liegt, nicht in Ihrem HTML.

Wenn die Anfrage gar nicht erst abgeht oder an eine Domain geht, die eindeutig nicht Ihr Formular-Backend ist, ist das der Bug - gefunden in unter einer Minute, bevor Sie überhaupt woanders suchen.

2. Bestätigen Sie, dass wirklich per POST gesendet wird

Ein <form> ohne explizites method="POST" verwendet standardmäßig GET, wodurch Ihre Felder als Query-String an die URL angehängt werden, statt einen Body zu senden - ein Formular-Backend-Endpoint akzeptiert das in der Regel nicht als echte Einsendung. Prüfen Sie zuerst das Tag selbst.

Wird das Formular über JavaScript statt eines nativen Browser-POST gesendet, ist der häufigere Fehler ein Handler, der e.preventDefault() aufruft, um die Standardnavigation zu stoppen, und dann tatsächlich nie etwas sendet - ein defekter fetch-Aufruf, ein Tippfehler im Endpoint innerhalb des Handlers, oder ein stiller vorzeitiger Return. preventDefault() ohne eine funktionierende Anfrage dahinter ist für die besuchende Person nicht von einem toten Formular zu unterscheiden: Die Seite tut einfach... nichts.

3. Schließen Sie die Konsole aus, nicht nur das Netzwerk

Bei jeder auf fetch basierenden Einsendung öffnen Sie zusätzlich zu Network den Console-Tab. Ein CORS-Fehler, eine blockierte Mixed-Content-Anfrage (Senden an http:// von einer https://-Seite aus) oder eine unabgefangene Exception im Submit-Handler stoppen die Anfrage jeweils vollständig - und keines davon erzeugt einen sichtbaren Fehler für die besuchende Person. Es sieht einfach nach Stille aus, genau das, wonach ein kaputtes Formular von außen aussieht.

4. Prüfen Sie, wo die Benachrichtigung tatsächlich gelandet ist

Kam die Anfrage aus Schritt 1 mit einem Erfolgsstatus zurück, hat die Einsendung das Backend erreicht - die verbleibende Frage ist nur, wohin der Alarm ging. Prüfen Sie zuerst Spam- und Werbe-Ordner; das ist mit Abstand der häufigste Grund, warum eine „fehlende“ Benachrichtigung gar nicht wirklich fehlt. Senden Sie von einer eigenen verifizierten Domain statt vom Standard-Absender, führt ein falsch konfigurierter SPF- oder DKIM-Eintrag dazu, dass E-Mails vom empfangenden Mailserver stillschweigend gefiltert oder abgewiesen werden - was auf Ihrer Seite identisch aussieht wie „es wurde nichts gesendet“.

5. Denken Sie an eine stille Ablehnung - Rate-Limits und ein defekter Honeypot

Legitime Einsendungen werden gelegentlich als verdächtig eingestuft. Wiederholtes, schnelles Testen von derselben IP beim Debuggen entspricht genau dem Muster, das Rate-Limiting erkennen soll, und kann ohne jede feindselige Absicht auslösen. Warten Sie ein paar Minuten und versuchen Sie es erneut, bevor Sie annehmen, dass etwas kaputt ist.

Ein subtilerer und wirklich häufiger Bug: das Honeypot-Feld. Die meisten Spam-Schutzmaßnahmen enthalten ein verstecktes Feld, das echte Besucher nie sehen oder ausfüllen - füllt ein Bot es aus, wird die Einsendung stillschweigend verworfen. Eine CSS-Regression (eine umbenannte Klasse, ein nicht ladendes Stylesheet, eine Layout-Änderung, die das falsche Element „enthüllt“) kann dieses Feld für echte Nutzer sichtbar machen, die dann entweder durch ein zusätzliches Feld verwirrt werden oder - schlimmer - es von einem Passwort-Manager automatisch ausgefüllt bekommen, was denselben für Bots gedachten Filter auslöst. Fingen Einsendungen direkt nach einem Redesign oder einer CSS-Änderung an zu scheitern, ist das der erste Punkt, den Sie prüfen sollten.

Prüfen Sie das Dashboard, nicht nur Ihren Posteingang

Die übergreifende Lehre aus alldem: „Habe ich eine E-Mail bekommen“ ist nicht dieselbe Frage wie „ist die Einsendung angekommen“, und beides zu vermischen ist der Grund, warum solche Bugs Tage statt Minuten zur Klärung brauchen. Bei Formhook erscheint jede Einsendung, die das Backend tatsächlich erreicht, im Dashboard - unabhängig davon, ob die Benachrichtigungs-E-Mail zugestellt wurde. Die erste sinnvolle Prüfung, noch vor allen obigen Schritten, ist also einfach: einloggen und nachsehen. Steht sie dort, liegt das Problem auf der Benachrichtigungsseite (Schritte 4-5). Steht sie nicht dort, liegt das Problem vorgelagert, noch bevor die Anfrage überhaupt das Backend erreicht hat (Schritte 1-3).

Lohnt sich regelmäßig, nicht nur wenn etwas kaputtgeht: Die Checkliste für Tests vor dem Launch deckt den fünfzehnminütigen Durchgang ab, der die meisten dieser Probleme abfängt, bevor ein echter Besucher darauf trifft. Und wenn Sie ein Formular-Backend evaluieren und sehen möchten, wie eines von Anfang bis Ende funktioniert, behandeln die Dokumentation und die Preise-Seite Einrichtung und die kostenlose Stufe.