Ja, das ist provokant. Aber irgendwer muss es mal so klar sagen.
Millionen Websites hängen seit Jahren an Google reCAPTCHA. Viele davon mit diesen absurden Bilderrätseln, die Menschen nerven, Barrieren schaffen und nebenbei Google mit wertvollen Nutzersignalen füttern. Und seit dem 2. April 2026 lese ich überall sinngemäß: Google ist bei reCAPTCHA ja „nur noch" Auftragsverarbeiter. Also alles halb so wild?
Nein.
Was sich am 2. April geändert hat – und was nicht
Was sich geändert hat: die juristische Verpackung. Google hat seine Rolle bei reCAPTCHA neu definiert – vom Verantwortlichen zum Auftragsverarbeiter. Das klingt nach einer bedeutenden Änderung und ist es datenschutzrechtlich durchaus.
Was sich nicht geändert hat: die technische Realität auf der Website. Ein nerviges Captcha bleibt ein nerviges Captcha. Ein datenintensiver Drittanbieterdienst wird nicht besser, weil die Vertragsrolle umetikettiert wurde.
In der Praxis heißt das für die meisten Websites weiterhin:
- Externe Requests zu Google-Servern bei jedem Seitenaufruf
- Zusätzliche Cookies, die gesetzt werden
- Abhängigkeit von einem US-amerikanischen Drittanbieter tief im Frontend
- Mehr Datenverkehr, mehr Rechenaufwand, mehr Ladezeit
- Und für viele Nutzer: Frust, der Conversions kostet
Das eigentliche Problem: die meisten brauchen reCAPTCHA gar nicht
Das ist die unbequeme Wahrheit, die in der Datenschutzdiskussion untergeht. Bot-Schutz für Formulare ist ein legitimes Anliegen. Google reCAPTCHA mit Bilderrätseln ist dafür in den meisten Fällen grob überdimensioniert.
Was heute für die überwiegende Mehrheit der Websites völlig ausreicht:
Honeypot-Felder. Ein unsichtbares Formularfeld, das nur Bots ausfüllen. Kein JavaScript, kein externer Request, kein Tracking. Ich nutze diese Lösung seit Jahren auf meinen eigenen Projekten – zuverlässig und datenschutzkonform.
Zeitmessung im Formular. Wer ein Formular in unter zwei Sekunden abschickt, ist mit hoher Wahrscheinlichkeit ein Bot. Eine serverseitige Prüfung der Zeit zwischen Seitenaufruf und Formularabsendung filtert den Großteil des automatisierten Spams.
Serverseitige Plausibilitätsprüfungen. Identische Formularabsendungen, unmögliche Zeichenkombinationen, verdächtige IP-Muster – lässt sich serverseitig ohne jeden Client-Overhead prüfen.
Rate Limiting. Mehr als fünf Formularabsendungen pro Minute von derselben IP sind in den meisten Szenarien kein menschliches Verhalten.
CSRF-Schutz. Verhindert Cross-Site-Request-Forgery-Angriffe, ohne dass Nutzer irgendetwas anklicken müssen.
Warum das auch ein Nachhaltigkeitsthema ist
Das reCAPTCHA-Script selbst ist nicht trivial. Es lädt externe Ressourcen, setzt Cookies, führt Fingerprinting durch und sendet Daten an Google-Server. Auf jeder Seite, bei jedem Aufruf – auch auf Seiten, auf denen gar kein Formular zu sehen ist, wenn das Script global eingebunden wurde.
Jeder dieser Requests kostet Bandbreite, Serverkapazität und Strom. Multipliziert über die Millionen Websites, die reCAPTCHA einsetzen, ist das ein messbarer Beitrag zum digitalen CO₂-Fußabdruck des Webs – für Schutzmechanismen, die in den meisten Fällen leichter zu ersetzen wären.
Das ist kein reines Datenschutzthema. Es ist auch ein UX-Thema, ein Performance-Thema und ein Nachhaltigkeitsthema – gleichzeitig.
Vier Fragen für Website-Betreiber
Wer reCAPTCHA einsetzt, sollte sich jetzt vier Fragen stellen:
- Brauche ich reCAPTCHA wirklich – oder reicht eine einfachere Lösung?
- Muss es auf jeder Seite laden, oder nur dort, wo tatsächlich Formulare sind?
- Gibt es für meinen Anwendungsfall eine leichtere Alternative ohne externe Abhängigkeit?
- Ist meine Datenschutzerklärung nach der Rollenänderung vom 2. April noch aktuell?
Wer diese Fragen jetzt ignoriert, spart keine Arbeit. Er verschiebt nur das Problem.
Zum LinkedIn-Post vom 9. April: linkedin.com