Der Kunde meldet sich genervt: Über sein Kontaktformular trudeln seit Tagen dutzende Nachrichten ein, alle auf Englisch, alle mit dubiosen Links, „SEO-Angeboten" und Kryptowährungs-Werbung. Sein Postfach ist zugemüllt, echte Anfragen gehen unter. Deine erste Reaktion ist die naheliegende: „Wir bauen dir ein reCAPTCHA ein." Und genau hier lohnt sich ein Moment des Innehaltens – denn diese schnelle Lösung tauscht ein Problem gegen ein neues und schiebt dem Kunden womöglich ein Datenschutzrisiko unter, das teurer werden kann als der Spam.
Formular-Spam ist 2026 kein Randphänomen mehr, sondern industrialisiert. Der Cloudflare Threat Report 2026 beziffert den Anteil automatisierter Bot-Aktivität auf rund 30 Prozent des gesamten beobachteten Web-Traffics; bei Login-Versuchen stammen sogar 94 Prozent von Bots. Formulare sind für diese Bots ein dankbares Ziel, weil sie offen im Netz stehen und billig massenhaft angesteuert werden können. Die gute Nachricht: Man kann sie wirksam abwehren, ohne die Daten der eigenen Besucher an Dritte zu verschenken. Dieser Beitrag zeigt, wie – und warum der Reflex zu reCAPTCHA oft der falsche ist.
Formular-Spam ohne reCAPTCHA abwehren: warum das der bessere Weg ist
Googles reCAPTCHA ist verbreitet, weil es bequem ist und funktioniert. Der Preis dafür wird aber selten mitgedacht. Um Menschen von Bots zu unterscheiden, sammelt der Dienst umfangreiche Daten: die IP-Adresse, Eigenschaften des Browsers, das Verhalten auf der Seite und ein Cookie mit einer eindeutigen Nutzer-ID. Diese Daten fließen an Google und damit in die USA. Datenschutzrechtlich ist das heikel: Das österreichische Bundesverwaltungsgericht entschied 2024, dass der Einsatz von reCAPTCHA ohne vorherige Einwilligung gegen die DSGVO verstößt, und die französische Datenschutzbehörde CNIL verhängte bereits 2023 entsprechende Bußgelder.
Für dich als Agentur hat das eine unbequeme Konsequenz: Bindest du reCAPTCHA ohne Einwilligung ein, lädst du dem Kunden ein Abmahn- und Bußgeldrisiko auf. Bindest du es rechtskonform ein, brauchst du eine vorgeschaltete Einwilligung – also einen Cookie-Banner-Klick, bevor das Formular überhaupt nutzbar ist. Damit verlagerst du das Problem nur: Aus der Datenschutzfrage wird ein Nutzererlebnis, bei dem ein Teil der echten Interessenten abspringt, bevor er das Formular ausfüllt. Dieselbe Logik, die schon beim DSGVO-konformen Einbinden externer Dienste wie Google Fonts oder Maps gilt, greift hier: Was du auf dem eigenen Server lösen kannst, solltest du nicht an einen US-Konzern auslagern.
Die Honeypot-Methode: unsichtbar für Menschen, verräterisch für Bots
Der wirksamste und zugleich unauffälligste Spam-Schutz ist der sogenannte Honeypot – ein „Honigtopf", der Bots in die Falle lockt. Die Idee ist so simpel wie elegant: Du fügst deinem Formular ein zusätzliches Eingabefeld hinzu, das per CSS für menschliche Besucher unsichtbar gemacht wird. Ein echter Nutzer sieht das Feld nicht und lässt es logischerweise leer. Ein Bot dagegen liest den Quelltext des Formulars aus und füllt stumpf alle Felder aus, die er findet – auch das versteckte. Kommt beim Absenden ein ausgefülltes Honeypot-Feld auf dem Server an, ist der Fall klar: Die Einsendung stammt von einem Bot und wird verworfen.
Das Schöne an dieser Methode ist, dass sie den ehrlichen Besucher komplett in Ruhe lässt. Kein Rätsel, keine verzerrten Buchstaben, kein Klick auf Ampeln und Zebrastreifen – der Mensch merkt schlicht nichts. Und datenschutzrechtlich ist der Honeypot unbedenklich, weil er ohne Cookies auskommt, keine Daten an Dritte sendet und deshalb keine Einwilligung braucht. Ein praktischer Hinweis für die Umsetzung: Nenne das versteckte Feld unauffällig-plausibel, etwa „Website" oder „Adresse2", statt es offensichtlich „honeypot" zu taufen – manche Bots meiden Felder mit verräterischen Namen. Und verstecke es per CSS wirklich vollständig, sonst füllen es auch Nutzer aus, die mit der Tastatur navigieren. Ein einzelner Honeypot ist zwar kein Bollwerk gegen einen gezielten Angreifer, der dein Formular manuell analysiert. Gegen die große Masse an automatisiertem Standard-Spam, um die es im Agenturalltag fast immer geht, ist er aber erstaunlich effektiv.
Zeitfalle und Rechenaufgabe: den Schutz stärker machen
Wer den Honeypot ergänzen will, kombiniert ihn mit einer Zeitprüfung. Der Gedanke dahinter: Ein Mensch braucht ein paar Sekunden, um ein Formular zu lesen und auszufüllen; ein Bot feuert es in Millisekunden ab. Der Server merkt sich deshalb, wann das Formular geladen wurde, und verwirft Einsendungen, die verdächtig schnell zurückkommen. Damit ein Bot diesen Zeitstempel nicht einfach fälscht, wird er kryptografisch signiert – etwa per HMAC –, sodass nur der Server ihn ausstellen und prüfen kann. Diese „Zeitfalle" fängt genau die schnellen, automatisierten Massensendungen ab, die den Löwenanteil des Spams ausmachen.
Eine dritte Stufe für hartnäckige Fälle ist ein Proof-of-Work: Der Browser des Besuchers löst im Hintergrund eine kleine Rechenaufgabe, bevor das Formular abgesendet wird. Für einen einzelnen Menschen ist das in Sekundenbruchteilen erledigt und völlig unmerklich; für einen Bot, der tausende Formulare pro Minute abschicken will, summiert sich der Rechenaufwand zu einer unwirtschaftlichen Bremse. Wichtig ist dabei, an Besucher ohne aktiviertes JavaScript zu denken – für sie braucht es einen barrierefreien Ausweg, etwa eine einfache, im Klartext gestellte Rechenfrage. Genau an diesem Punkt zeigt sich ein weiterer Vorteil gegenüber klassischen CAPTCHAs: Verzerrte Bilderrätsel sind für Menschen mit Sehbehinderung und für Screenreader notorisch schwer zu lösen und geraten damit in Konflikt mit den Anforderungen an barrierefreie Websites, die seit 2025 für viele Angebote Pflicht sind. Serverseitige Methoden mit einem klartextlichen Fallback umgehen dieses Problem.
Serverseitige Prüfung: die letzte Verteidigungslinie
So elegant die bisherigen Methoden sind, sie greifen alle im Browser oder direkt beim Absenden. Die robusteste Ebene liegt dahinter: die Prüfung der Inhalte auf dem Server, bevor eine Nachricht überhaupt in einem Postfach landet. Hier lassen sich einfache, aber wirkungsvolle Regeln umsetzen – etwa das Blockieren von Einsendungen mit auffällig vielen Links, das Herausfiltern bekannter Spam-Muster oder das Ablehnen von Nachrichten, deren angebliche Absenderadresse offensichtlich ungültig ist. Auch eine Begrenzung, wie oft dasselbe Formular von derselben Quelle in kurzer Zeit abgeschickt werden darf, ein sogenanntes Rate Limiting, nimmt automatisierten Fluten die Wucht.
Diese serverseitige Kontrolle folgt demselben Grundgedanken, der auch bei der Absicherung von KI-Systemen zählt: Man vertraut keiner Eingabe blind, sondern prüft sie, bevor man auf ihr aufbaut. Wer schon einmal einen Kundenbot gegen manipulierte Eingaben gehärtet hat, kennt das Prinzip aus dem Beitrag zur Chatbot-Sicherheit. Bei Ragnova ist genau dieser Gedanke zum Kernprinzip geworden: Der Chatbot antwortet nur mit dem, was er in den freigegebenen Inhalten belegen kann, statt jeder Eingabe zu folgen – belegbasiert statt gutgläubig. Für dein Kontaktformular heißt das übersetzt: Eine mehrstufige Verteidigung, die im Zweifel lieber ablehnt, ist wertvoller als ein einzelner cleverer Trick.
Die richtige Kombination für den Kundenalltag
In der Praxis brauchst du selten alle Stufen auf einmal. Für die typische Handwerker- oder Kanzleiseite mit überschaubarem Traffic reicht die Kombination aus Honeypot und Zeitfalle in aller Regel aus, um den automatisierten Standard-Spam nahezu vollständig auszusperren – ohne Cookie-Banner, ohne Einwilligung, ohne dass ein echter Interessent je etwas davon bemerkt. Kommt ein Formular mit hohem Aufkommen oder gezielten Angriffen unter Druck, ergänzt du Proof-of-Work und serverseitige Regeln bis hin zum Rate Limiting.
Viele moderne Formular-Werkzeuge für WordPress und andere Systeme bringen diese Bausteine bereits mit; die Kunst besteht darin, sie bewusst zu aktivieren, statt reflexhaft zum externen Dienst zu greifen. Der Hinweis vorab, dass dies eine technische und journalistische Einordnung ist und keine Rechtsberatung, gehört dazu – die datenschutzrechtliche Bewertung einer konkreten Einbindung sollte im Zweifel jemand mit juristischer Expertise absegnen. Aber die Richtung ist eindeutig: Spam-Schutz, der auf dem eigenen Server läuft, ist datensparsamer, barriereärmer und rechtlich ruhiger als der Griff nach reCAPTCHA. Aus dem genervten Kundenanruf wird so nicht nur ein sauberes Postfach, sondern ein weiteres kleines Argument dafür, warum es sich lohnt, die Website von Profis betreuen zu lassen.
- Formular-Spam ist industrialisiert: Laut Cloudflare Threat Report 2026 stammen rund 30 Prozent des Web-Traffics von Bots – Kontaktformulare sind ein bevorzugtes Ziel.
- Google reCAPTCHA sammelt IP, Browser- und Verhaltensdaten und sendet sie in die USA; ein Einsatz ohne Einwilligung verstößt laut österreichischem Bundesverwaltungsgericht (2024) gegen die DSGVO.
- Die Honeypot-Methode – ein per CSS unsichtbares Feld, das nur Bots ausfüllen – wehrt Standard-Spam ab, ganz ohne Cookies, Einwilligung oder Nutzer-Hürde.
- Ergänzend fangen eine signierte Zeitfalle und ein Proof-of-Work automatisierte Massensendungen ab; ein klartextlicher Fallback hält den Schutz barrierefrei.
- Die robusteste Ebene ist die serverseitige Prüfung mit Rate Limiting und Inhaltsregeln – für die meisten Kundenseiten genügt schon Honeypot plus Zeitfalle.