Inhalt
Wer auf Headless WordPress umstellt, entkoppelt das Frontend vom WordPress-Backend — und genau dort, wo bisher ein Plugin-Shortcode das Kontaktformular gerendert hat, ist plötzlich nichts mehr. Contact Form 7, Gravity Forms und Elementor-Formulare erzeugen ihr HTML über das klassische Theme. Ohne dieses Theme rendert der Shortcode leer. Die Frage ist also nicht, ob Ihre Leads noch ankommen, sondern über welchen Weg Sie sie künftig erfassen.
Die kurze Antwort: Es gibt drei saubere Muster — eine eigene Next.js-API-Route mit E-Mail-Versand, einen externen Formulardienst oder die Rück-Submission zurück nach WordPress. Keines davon ist automatisch das richtige; die Wahl hängt von Datenhoheit, Team-Skills und Wartungsbudget ab. Dieser Beitrag stellt alle drei nebeneinander und benennt die Trade-offs ehrlich. Wenn Sie zuerst verstehen wollen, wie Headless WordPress als Architektur funktioniert, lesen Sie dort weiter; hier geht es konkret um den Submission-Pfad.
Quer durch alle drei Muster gilt derselbe Pflichtteil: serverseitige Validierung, Spam-Schutz und eine revDSG-konforme Speicherung. Das sind die Themen, die in den meisten Anleitungen fehlen — und genau die behandeln wir hier ausführlich.
Warum Ihr Formular-Plugin im Headless-Setup plötzlich leer ist
Plugins wie Contact Form 7, Gravity Forms oder Elementor rendern ihr Formular-HTML serverseitig über Shortcodes im klassischen WordPress-Theme. Im Headless-Setup existiert dieses Theme nicht mehr — das entkoppelte Frontend ruft nur noch Daten ab. Damit wird das Rendering vollständig zu Ihrer Verantwortung, und der Shortcode bleibt leer.
Das betrifft nicht nur die Optik. Auch der AJAX-Submit der Plugins hängt am Theme: Das Skript, das die Eingaben absendet und die Erfolgsmeldung anzeigt, wird über das Theme eingebunden — und greift im entkoppelten Frontend ebenfalls nicht mehr. Wie es ein CSS-Tricks-Beitrag zur Headless-Formularverarbeitung formuliert: "The front-end part becomes our responsibility entirely, and we can't rely anymore on form plugins to do the heavy lifting in that area."
Das ist die klassische Migrations-Überraschung: Die Funktionalität existiert weiterhin im Backend, aber niemand rendert sie. Wer sie früh einplant, vermeidet böses Erwachen kurz vor dem Go-live — es ist eine der typischen Stolperfallen einer Headless-Migration. Die Konsequenz ist immer dieselbe: Formular-UI neu im Frontend bauen, und den Submission-Pfad bewusst wählen.
Die drei Muster der Lead-Erfassung — welches passt zu welchem Projekt?
Es gibt drei saubere Wege, und sie unterscheiden sich grundlegend. Muster 1 ist eine eigene Next.js-API-Route bzw. Server Action mit direktem E-Mail-Versand. Muster 2 ist ein externer Formulardienst wie Formspree, Resend oder HubSpot. Muster 3 ist die Rück-Submission in WordPress über WP-REST oder WPGraphQL. Jedes hat ehrliche Trade-offs bei Kontrolle, Aufwand, Datenhoheit und Wartung.
Vereinfacht: Muster 1 gibt Ihnen maximale Kontrolle, kostet aber eigenen Code samt Validierungs- und Spam-Layer. Muster 2 ist der schnellste Start, verlagert aber Daten und teils den E-Mail-Versand zu Drittanbietern. Muster 3 bringt die Leads zurück ins vertraute WP-Backend — um den Preis von zwei gekoppelten Systemen. Die Entscheidung fällt entlang von vier Kriterien: Datenhoheit (revDSG), vorhandene Team-Skills, gewünschte CRM-Anbindung und das laufende Wartungsbudget.
| Muster | Aufwand / Setup | Kontrolle & Datenhoheit | revDSG-Eignung | Wartung | Ideal für |
|---|---|---|---|---|---|
| 1 · Next.js-API-Route + Resend | Hoch, eigener Code | Voll bei Ihnen | Sehr gut, Datenhoheit bleibt | Mittel | Custom-/Agentur-Projekte |
| 2 · Externer Formulardienst | Niedrig | Gering, Daten beim Anbieter | AVV + Datenstandort nötig | Niedrig | MVP, Landingpage, CRM-Anbindung |
| 3 · Rück-Submission WP-REST/GraphQL | Mittel | Mittel, im WP-Backend | Gut, wenn WP DSG-konform gehostet | Hoch, zwei Systeme | Teams mit etablierten WP-Workflows |
Kein Muster ist universell richtig — die ehrliche Antwort hängt davon ab, wem die Leaddaten gehören sollen und wer den Code am Ende wartet.
Muster 1: Eigene Next.js-API-Route mit E-Mail-Versand
Beim ersten Muster postet das Frontend an einen Route Handler oder eine Server Action. Dort validieren Sie serverseitig, prüfen den Honeypot, rate-limiten pro IP und verschicken die E-Mail über einen Transaktions-Dienst. Das bedeutet maximale Kontrolle über Datenfluss und Speicherung — dafür schreiben und warten Sie den Code selbst. Genau dieses Muster nutzen wir in den meisten unserer Projekte, weil es die Datenhoheit nicht aus der Hand gibt.
Für die Validierung empfiehlt die Next.js-Dokumentation ausdrücklich eine serverseitige Prüfung: "For server-side validation, you can use a library like zod", typischerweise via schema.safeParse im Action- oder Route-Handler. Ein zweiter, oft übersehener Hinweis aus denselben Docs: "Always verify authentication and authorization inside each Server Action, even if the form is only rendered on an authenticated page." Sicherheitsprüfungen gehören also in jede Action — nicht nur ans Frontend.
Den Versand übernimmt ein API-Dienst wie Resend. Dessen Free-Tier deckt 3'000 E-Mails pro Monat ab (maximal 100 pro Tag), der bezahlte Pro-Tarif liegt bei 20 $/Monat für 50'000 E-Mails (Resend-Preise). Für ein typisches KMU-Kontaktformular reicht der Gratis-Tarif in aller Regel deutlich aus — ein einzelnes Kontaktformular erzeugt selten mehr als ein paar Dutzend Mails pro Tag.
Der Reiz dieses Musters liegt darin, dass jeder Schritt sichtbar und prüfbar bleibt: Das Schema definiert exakt, welche Felder erlaubt sind und gibt strukturierte Fehler zurück; der Honeypot und der Origin-Check laufen vor dem Versand; und die Speicherung — ob in einer Datenbank oder nur als E-Mail — entscheiden Sie bewusst. Dafür tragen Sie die Verantwortung für jede dieser Stellen selbst. Es ist kein Muster für Teams ohne Frontend-Kapazität; in unseren Projekten ist es dennoch der Standard, weil es Datenhoheit und Attribution ohne Drittanbieter zusammenführt. Es bleibt aber eine gut begründete Option unter dreien, nicht die einzig richtige Antwort.
Muster 2: Externer Formulardienst (Formspree, Resend, HubSpot)
Beim zweiten Muster postet das Formular direkt an einen Drittanbieter, der Zustellung, Spam-Filter und oft ein eigenes Dashboard übernimmt. Das ist der schnellste Weg zum funktionierenden Formular und kommt ganz ohne eigenen Backend-Code aus. Der Preis dafür: Leaddaten und Versand liegen beim Anbieter — Auftragsverarbeitung und Serverstandort müssen revDSG-konform geklärt sein.
Ideal ist dieses Muster für MVPs, einzelne Landingpages und kleine Teams ohne Backend-Ressourcen. HubSpot punktet, wenn die Leads direkt ins CRM fliessen sollen; Formspree und Resend sind die schlanke Wahl, wenn es nur um zuverlässige Zustellung geht. Der Tausch, den Sie eingehen: weniger Kontrolle über Datenfeld-Mapping, Aufbewahrung und Löschfristen.
Datenschutzrechtlich ist hier am meisten zu beachten. Viele dieser Dienste hosten in den USA, weshalb ein Auftragsverarbeitungsvertrag (AVV) und Klarheit über den Datenstandort Pflicht sind. Wie Submission-Daten unter dem revDSG zu behandeln sind, behandeln wir an anderer Stelle im Detail — für die Muster-Entscheidung gilt: Je weniger Sie selbst kontrollieren, desto sorgfältiger muss der Vertrag mit dem Anbieter sein.
Muster 3: Rück-Submission nach WordPress via REST oder GraphQL
Muster 3 schickt die Leads zurück ins WP-Backend, wo die Redaktion sie gewohnt ist: Das Frontend postet an die Plugin-REST-Endpoints oder per Mutation über WPGraphQL, und die Einträge erscheinen wie bisher in Contact Form 7 oder Gravity Forms. Sie behalten Backend-Workflows und Entry-Verwaltung — handeln sich aber zwei gekoppelte Systeme und deren Wartung ein.
Für Contact Form 7 lautet der Endpoint /wp-json/contact-form-7/v1/contact-forms/<FORM_ID>/feedback, für Gravity Forms /wp-json/gf/v2/forms/<FORM_ID>/submissions (CSS-Tricks: Headless Form Submission). Wer lieber bei GraphQL bleibt, nutzt das Plugin WPGraphQL for Gravity Forms, das Querying, das Absenden von Formularen via Mutation sowie das Aktualisieren und Löschen von Entries unterstützt — explizit für decoupled WordPress gebaut. Welche Schnittstelle besser passt, klärt unser Beitrag WPGraphQL vs. REST API im Vergleich.
Der Vorteil: Entries, Benachrichtigungen und Add-ons wie CRM- oder PDF-Integrationen bleiben im vertrauten Backend. Der Nachteil wiegt schwer: Plugin-Updates, die Erreichbarkeit der WordPress-Instanz und das Mapping der Antworten werden zur laufenden Verpflichtung. Sie betreiben effektiv zwei Systeme, die zusammenpassen müssen.
Wann lohnt sich welches Muster?
Die Wahl folgt vier Kriterien, nicht der Technik: Datenhoheit, Team-Skills, gewünschte CRM-Anbindung und Wartungsbudget. Muster 1 passt, wenn die Leaddaten im eigenen Haus bleiben sollen und ein Frontend-Team den Code dauerhaft pflegt — das ist der Normalfall für Custom- und Agentur-Projekte mit echten Datenschutz-Anforderungen. Muster 2 ist die richtige Antwort für eine schnelle Landingpage, einen MVP oder ein Team ganz ohne Backend-Ressourcen, das den Auftragsverarbeitungsvertrag mit dem Anbieter sauber führt.
Muster 3 ist dann sinnvoll, wenn eine Redaktion ihre Einträge zwingend im gewohnten WordPress-Backend braucht oder bestehende Plugin-Workflows samt Add-ons erhalten bleiben müssen. Wir empfehlen es selten als Erstwahl, weil die dauerhafte Kopplung zweier Systeme den grössten Wartungsaufwand der drei Muster verursacht. Ehrlich bleibt: Es gibt Setups, in denen genau diese Vertrautheit den Ausschlag gibt — dann ist Muster 3 die richtige Wahl, auch wenn es nicht unser Standardansatz ist.
Spam-Schutz und serverseitige Validierung — der nicht verhandelbare Teil
Jedes der drei Muster braucht denselben Schutz-Layer. Ein Honeypot-Feld — ein versteckter Input, den Bots ausfüllen, Menschen aber nicht — filtert den Grossteil des Spams ohne nervige Captchas. Dazu gehören serverseitige Validierung, ein Rate-Limit pro IP und eine Origin-/CSRF-Prüfung. Client-Validierung allein ist wertlos, weil sie sich trivial umgehen lässt.
Der Honeypot ist ein leeres Pflichtfeld, das per CSS verborgen wird: Ist es beim Submit befüllt, war ein Bot am Werk und der Request wird verworfen. Die serverseitige Validierung läuft über safeParse und gibt Fehler strukturiert zurück. Rate-Limiting pro IP und ein Origin-Check fangen Massen-Submits und CSRF ab.
Ein oft unterschätzter Vorteil des Honeypots: Er ist datensparsamer als reCAPTCHA. Es fliesst kein Request an einen Drittanbieter, kein Tracking-Cookie, keine IP an Google — was die datenschutzrechtliche Bewertung des gesamten Formulars deutlich vereinfacht. Wer reCAPTCHA einbindet, holt sich einen externen Dienst genau dort ins Formular, wo Personendaten erhoben werden.
revDSG-konforme Speicherung und UTM-/Attribution-Pass-through
Wer Leads erfasst, bearbeitet Personendaten — und damit greift das revidierte Schweizer Datenschutzgesetz, in Kraft seit dem 1. September 2023. Pflicht sind eine klare Informationspflicht bei der Erhebung, angemessene Datensicherheit und definierte Löschfristen. Das gilt unabhängig vom gewählten Muster — entscheidend ist nur, wer die Daten am Ende kontrolliert. Dies ist eine fachliche Einordnung, keine Rechtsberatung.
Konkret muss die Information beim Erheben "knapp, transparent, verständlich und einfach zugänglich" sein und mindestens Identität und Kontaktdaten des Verantwortlichen, den Bearbeitungszweck sowie die Empfänger nennen. Das ist kein Beiwerk: Vorsätzliche Verstösse können nach EDÖB mit Bussen bis CHF 250'000 geahndet werden — und sie treffen primär die verantwortliche natürliche Person, das Unternehmen nur subsidiär bis CHF 50'000. Genau deshalb entscheidet die Datenhoheit-Frage mit über das Muster: Eigener Code bedeutet volle Kontrolle über Speicherort und Löschung.
Bleibt die Attribution. UTM-Parameter und Referrer schicken Sie als versteckte Formularfelder mit dem Submit mit — beim Seitenaufruf aus der URL gelesen, beim Absenden mitgegeben. So landet die Kampagnenzuordnung direkt beim Lead, sauber getrennt vom consent-pflichtigen Web-Tracking. Wie sich DSG-konformes Tracking mit Plausible oder Google Analytics davon abgrenzt, lesen Sie im verlinkten Beitrag; der Punkt hier ist die Trennung: Attribution gehört zum Lead, Web-Analytics zum Consent-Layer — beides darf nicht vermischt werden.
Nächster Schritt
Welches der drei Muster zu Ihnen passt, lässt sich in wenigen Minuten klären — meist entscheidet die Frage nach Datenhoheit und vorhandenen Team-Ressourcen den Ausschlag. In einem unverbindlichen Erstgespräch zur Lead-Architektur gehen wir Ihren konkreten Fall durch: bestehende Formulare, CRM-Anbindung, revDSG-Anforderungen. Wer zuerst den Status quo prüfen will, findet im Website-Check eine schnelle technische Standortbestimmung.