„Danke!“ – aber ist die Anfrage wirklich angekommen? Formular-Submits belastbar prüfen

Ein Kontaktformular ist kein Button mit anschließendem Häkchen. Es ist eine kleine Transaktionskette.

Der Nutzer klickt auf „Absenden“. Der Browser sendet Daten. Der Server nimmt sie entgegen. Vielleicht wird ein Datensatz gespeichert. Vielleicht wird nur eine E-Mail verschickt. Vielleicht soll zusätzlich ein CRM-Webhook laufen. Dann erscheint eine Dankeseite.

Und genau hier entsteht eine unangenehme Frage: Was bedeutet „Erfolgreich gesendet“ in deinem System eigentlich?

Wenn die Oberfläche schon Erfolg meldet, sobald der Server einen Request angenommen hat, die eigentliche Speicherung oder Weiterleitung aber danach scheitert, entsteht ein besonders teurer Fehler: Der Besucher glaubt, alles sei erledigt. Das Unternehmen erfährt nie, dass eine Anfrage existierte.

Der wichtigste Unterschied: angenommen, gespeichert und weitergeleitet sind nicht dasselbe

Für ein belastbares Formular lohnt sich ein gedankliches Modell mit mehreren Zuständen:

1. Der Browser hat den Request abgeschickt.
2. Der Server hat den Request erhalten und validiert.
3. Die Anfrage wurde dauerhaft gespeichert oder anderweitig zuverlässig angenommen.
4. Nachgelagerte Schritte wie E-Mail, CRM, Ticketing oder Webhooks wurden verarbeitet.
5. Fehler in diesen Schritten sind sichtbar und können erneut verarbeitet werden.

Ein HTTP-Status 200 allein beantwortet diese Fragen nicht.

Ein kleiner Unternehmensauftritt braucht dafür keine Enterprise-Event-Plattform. Aber er braucht einen klaren Punkt, ab dem eine Anfrage nicht mehr verloren gehen kann.

Eine robuste Minimalvariante ist häufig: erst speichern, dann Erfolg melden, Benachrichtigungen danach als separaten Schritt ausführen. Fällt der Maildienst oder das CRM kurz aus, bleibt die Anfrage trotzdem vorhanden und kann erneut zugestellt werden.

Clientseitige Validierung ist UX, nicht deine letzte Kontrollinstanz

HTML bietet mit required, Eingabetypen, Constraint Validation und Methoden wie reportValidity() nützliche Mechanismen, um Fehler früh sichtbar zu machen. Der aktuelle WHATWG-HTML-Standard definiert diese Browsermechanismen ausdrücklich für Formulare.

Sie ersetzen aber keine serverseitige Prüfung.

OWASP empfiehlt serverseitige Validierung, weil clientseitige JavaScript-Validierung umgangen werden kann. Praktisch heißt das: Der Browser darf dem Nutzer schnell helfen, aber der Server muss trotzdem prüfen, ob die Daten plausibel und im erwarteten Format sind.

Das gilt besonders für:

• erlaubte Auswahlwerte,
• Längen und Größenlimits,
• Datei-Uploads,
• E-Mail- und Telefonnummernformate,
• unerwartete Felder,
• manipulierte Requests,
• Spam- und Bot-Schutz.

Wenn ein Formular nur deshalb „sicher“ oder „korrekt“ ist, weil der Frontend-Code bestimmte Eingaben verhindert, ist die Prüfung unvollständig.

Der doppelte Lead ist oft ein Netzwerkproblem, kein ungeduldiger Nutzer

Ein klassischer Fehlerpfad sieht so aus:

• Nutzer klickt auf Absenden.
• Der Server speichert die Anfrage erfolgreich.
• Die Antwort an den Browser geht auf dem Weg verloren oder kommt erst nach einem Timeout.
• Die Oberfläche zeigt einen Fehler.
• Der Nutzer klickt erneut.
• Das System speichert dieselbe Anfrage ein zweites Mal.

HTTP definiert POST nicht als idempotente Methode. RFC 9110 weist deshalb auch darauf hin, dass nicht-idempotente Requests nicht einfach automatisch wiederholt werden sollten, wenn nicht bekannt ist, ob eine Wiederholung sicher ist.

Für Formulare bedeutet das: Duplikat-Schutz gehört auf den Server.

Je nach System kann das beispielsweise über eine Submission-ID, einen Idempotency-Key, einen einmaligen Token oder eine fachliche Duplikaterkennung erfolgen. Welche Variante sinnvoll ist, hängt davon ab, ob doppelte Anfragen grundsätzlich unmöglich sein sollen oder nur versehentliche Wiederholungen erkannt werden müssen.

Den Submit-Button nach dem ersten Klick zu deaktivieren ist trotzdem sinnvoll – aber nur als UX-Maßnahme. Zwei Tabs, Browser-Retries, ein Reload oder ein direkter API-Request umgehen diese Schranke.

Post/Redirect/Get hilft – löst aber nicht jedes Retry-Problem

Bei klassischen HTML-Formularen ist nach erfolgreichem POST häufig ein Redirect auf eine separate Erfolgsseite sinnvoll.

RFC 9110 beschreibt 303 See Other genau für diesen Fall: Nach einer POST-Aktion kann der Browser auf eine andere Ressource verwiesen werden und diese per GET abrufen. Dadurch hat die Dankeseite eine eigene URL und ein Reload dieser Seite sendet den ursprünglichen POST nicht erneut.

Das reduziert versehentliche Mehrfachübermittlungen durch „Seite neu laden“.

Aber: Post/Redirect/Get ersetzt keine serverseitige Idempotenz. Wenn der Browser die Antwort auf den ersten POST nie erhält, kann der Nutzer trotzdem erneut senden. Der Server muss also weiterhin wissen, wie mit Wiederholungen umzugehen ist.

Die E-Mail sollte nicht dein einziges Datensystem sein

Viele Kontaktformulare bestehen technisch nur aus:

Formular → Mailfunktion → Postfach

Das wirkt simpel, hat aber einen blinden Fleck. Wenn der Maildienst einen temporären Fehler liefert, DNS oder Authentifizierung falsch konfiguriert sind, ein Provider die Nachricht ablehnt oder die Anwendung den Fehler verschluckt, existiert die Anfrage möglicherweise nirgends mehr.

Für geschäftskritische Formulare ist deshalb die bessere Frage nicht: „Kommt die Testmail an?“

Sondern: „Was passiert mit der Anfrage, wenn die Mail nicht ankommt?“

Ein belastbarer Flow kann so aussehen:

Formular → serverseitige Validierung → persistente Submission → Bestätigung → E-Mail/CRM/Automation

Damit wird E-Mail zur Benachrichtigung – nicht zum einzigen Speicherort.

Für kleine Websites kann eine einfache Datenbanktabelle, ein sicher gespeicherter Form-Eintrag im CMS oder ein seriöser Form-Backend-Dienst ausreichen. Entscheidend ist, dass Fehler in nachgelagerten Diensten nicht den ursprünglichen Lead vernichten.

„Success“ sollte eine belastbare Bedeutung haben

Eine gute Erfolgsanzeige beantwortet intern mindestens eine Frage:

Kann das System diese Anfrage jetzt noch verlieren, ohne dass jemand etwas davon bemerkt?

Wenn ja, ist der Erfolg möglicherweise zu früh.

Bei asynchroner Verarbeitung muss der Nutzer nicht warten, bis jede CRM-Automation oder E-Mail abgeschlossen ist. Die Anfrage sollte aber bereits zuverlässig angenommen sein. Nachgelagerte Jobs brauchen dann einen nachvollziehbaren Status und, wo sinnvoll, Wiederholungsmechanismen.

Das ist besonders wichtig bei:

• CRM-Webhooks,
• Support-Tickets,
• Termin- oder Angebotsanfragen,
• Bewerbungsformularen,
• Newsletter- oder Event-Anmeldungen,
• Formularen mit Uploads,
• Checkout-nahen Kontaktstrecken.

Fehlerpfade sind Teil des Produkts

Viele Formulare werden nur im Happy Path getestet: gültige Daten, schnelles Netz, funktionierender Maildienst.

Ein sinnvoller Audit prüft zusätzlich:

• Was sieht der Nutzer bei 4xx- und 5xx-Antworten?
• Bleiben bereits eingegebene Daten erhalten?
• Wird der Submit-Button nach einem Fehler wieder aktiv?
• Was passiert bei Timeout oder Verbindungsabbruch?
• Kann ein Nutzer denselben Request versehentlich doppelt auslösen?
• Wird eine gespeicherte Anfrage trotz fehlgeschlagenem CRM-Webhook sichtbar?
• Gibt es für fehlgeschlagene Weiterleitungen einen Retry oder eine manuelle Queue?
• Kann Spam-Schutz echte Anfragen still verwerfen?
• Werden Uploads erst als erfolgreich bestätigt, wenn sie wirklich gespeichert wurden?

Ein Formular, das nur dann funktioniert, wenn alle abhängigen Systeme gleichzeitig gesund sind, ist operativ fragil.

Ohne Submission-ID wird Fehlersuche schnell zum Ratespiel

Wenn ein Kunde sagt: „Ich habe gestern um 14 Uhr das Formular abgeschickt“, sollte das nicht die einzige Spur sein.

Eine eindeutige Submission-ID oder Correlation-ID macht es deutlich leichter, den Weg einer Anfrage nachzuvollziehen. Sinnvolle technische Metadaten können sein:

• Zeitpunkt des Eingangs,
• Formular oder Kampagne,
• Verarbeitungsstatus,
• Zeitpunkt der Weiterleitung,
• Antwortstatus eines Webhooks,
• Retry-Anzahl,
• letzte Fehlerklasse.

Dabei sollten Logs nicht unnötig komplette Formularinhalte oder sensible Daten duplizieren. Für die Fehlersuche reicht oft technische Metadaten plus eine Referenz auf den sicher gespeicherten Datensatz.

Ein echter Formular-Test endet nicht an der Dankeseite

Bei Website-Pflichtencheck betrachten wir Formulare deshalb nicht nur visuell.

Je nach Prüfkontext untersuchen wir unter anderem:

• HTML- und Browservalidierung,
• serverseitige Fehlerreaktionen,
• Request- und Response-Verhalten,
• Success- und Redirect-Logik,
• doppelte Submits und Retry-Risiken,
• Spam-Schutz und mögliche False Positives,
• Abhängigkeiten von Mail-, CRM- oder Webhook-Diensten,
• erkennbare Monitoring- und Recovery-Lücken,
• mobile und barrierearme Fehlerzustände.

Bei Zugriff auf die technische Umsetzung lässt sich zusätzlich prüfen, ob „erfolgreich“ tatsächlich an eine belastbare Speicherung gekoppelt ist und wie fehlgeschlagene Weiterleitungen behandelt werden.

Die praktische Prüffrage

Öffne dein wichtigstes Kontakt- oder Lead-Formular und stelle dir nicht nur die Frage, ob es heute funktioniert.

Frage stattdessen:

Wenn der Nutzer nach dem Absenden einen Timeout sieht, der Server den Datensatz aber bereits gespeichert hat – was passiert beim zweiten Klick?

Und direkt danach:

Wenn das CRM zehn Minuten nicht erreichbar ist – wo liegt die Anfrage in dieser Zeit?

Wenn beide Antworten klar sind, ist dein Formular wahrscheinlich mehr als nur hübsch verdrahtet.

Wenn nicht, lohnt sich genau dort der nächste technische Check. Website-Pflichtencheck kann die Submission-Kette vom Browser bis zu den sichtbaren Fehler- und Übergabepunkten prüfen und die Risiken priorisieren, ohne aus einem Kontaktformular unnötig ein Großprojekt zu machen.