Seit Jahren richten wir Websites auf zwei Publikumsgruppen aus: auf Menschen und auf Suchmaschinen. Inzwischen kommt eine dritte hinzu – Software, die im Auftrag eines Menschen nicht nur liest, sondern handelt: Formulare ausfüllt, Termine sucht, Angebote anfragt. Dieser Beitrag zeigt, woran solche Agenten auf einer typischen WordPress-Website scheitern, was sich seit 2026 technisch geändert hat und welche Wege Sie öffnen sollten – und welche ausdrücklich nicht.

1. Der Unterschied zwischen Lesen und Handeln

Über KI und Websites wird seit zwei Jahren fast ausschließlich in einer Frage gedacht: Wird mein Inhalt in Antworten zitiert? Das ist die Perspektive des Crawlers. Er liest eine Webseite, nimmt den Text mit und ist wieder weg. Wenn dabei etwas nicht funktioniert, merkt es niemand – der Inhalt fehlt einfach in der Antwort.

Ein Agent arbeitet anders. Er hat einen Auftrag: „Finde in Hamburg eine WordPress-Agentur mit ISO-9001-Zertifizierung und frag ein Angebot an.“ Er sucht, öffnet Ihre Website, liest Ihre Leistungen, springt zum Kontaktformular – und muss dort etwas eintragen und absenden. Scheitert er, fehlt nicht nur ein Zitat. Es fehlt eine Anfrage.

Ein Crawler, der scheitert, kostet Sichtbarkeit. Ein Agent, der scheitert, kostet einen Kontakt.

2. Wie viel davon gibt es wirklich?

Nüchtern betrachtet ist die Größenordnung noch überschaubar – die Richtung aber eindeutig. Cloudflare wertet die Anfragen in seinem Netz jährlich aus: 2025 stellten Suchmaschinen-Crawler rund 40 Prozent des Verkehrs ausgewiesener Bots, KI-Crawler etwa 20 Prozent. Der Crawler, der ChatGPT-Nutzern beim Beantworten einer konkreten Frage Seiten nachlädt, erreichte in der Spitze ein bis zu 16-fach höheres Anfragevolumen als zu Jahresbeginn. Anfang Juni 2026 machte Cloudflare-Chef Matthew Prince öffentlich, dass Maschinen im Cloudflare-Netz erstmals die Mehrheit der Anfragen an Webseiten stellen: 57,5 Prozent gegenüber 42,5 Prozent von Menschen.

Der Anteil, der tatsächlich handelt statt nur liest, ist an diesen Zahlen nicht ablesbar und aktuell klein. Panik ist also unangebracht. Eine Entscheidung ist trotzdem fällig, denn wer nichts entscheidet, hat faktisch schon entschieden – meist über eine Voreinstellung im Hosting oder in einem Plugin.

3. Seit 2026 können sich Agenten ausweisen

Das eigentliche Problem war bisher technisch: Eine Website konnte einen nützlichen Agenten nicht von einem Angreifer unterscheiden. Zur Verfügung standen nur die Selbstauskunft im User-Agent und die IP-Adresse. Beides lässt sich fälschen. Wer sich schützen wollte, blockierte deshalb pauschal – und traf damit auch die Anfragen echter Interessenten.

Genau hier setzt Web Bot Auth an. Der Agent signiert jede HTTP-Anfrage kryptografisch mit einem privaten Schlüssel und schickt die Signatur in einem eigenen Header mit, dazu die Angabe, welche Bestandteile der Anfrage signiert wurden. In der Umsetzung von Cloudflare kommt ein dritter Header hinzu, der auf das Verzeichnis mit dem passenden öffentlichen Schlüssel verweist. Die Website prüft die Signatur und weiß danach zuverlässig, wer anfragt.

Cloudflare hat das im August 2025 als „Signed Agents“ gestartet, unter anderem mit dem ChatGPT Agent von OpenAI, Goose von Block, Browserbase und Anchor Browser. Seit dem 1. Juli 2026 gelten signierte Agenten dort als geprüfte Bots; unterschieden wird nur noch, ob ein Zugriff direkt erfolgt oder im Auftrag eines Nutzers. Akamai, DataDome und F5 unterstützen das Verfahren ebenfalls, Google dokumentiert es inzwischen für die eigenen Crawler. Auf Anbieterseite haben es unter anderem Amazon Bedrock AgentCore, Vercel und Shopify umgesetzt.

Einordnung mit Augenmaß: Bei der IETF gibt es für Web Bot Auth inzwischen eine eigene Arbeitsgruppe, aber noch keinen verabschiedeten Standard – nur Entwürfe. Details können sich also noch ändern. Für Sie heißt das: nicht darauf bauen, aber wissen, dass die Unterscheidung zwischen „irgendein Bot“ und „ein ausgewiesener Agent im Auftrag eines Menschen“ technisch inzwischen möglich ist. Das verschiebt die Frage von „blocken oder nicht“ zu „wen wofür“.

4. Woran Agenten auf WordPress-Websites scheitern

Die Stolpersteine sind unspektakulär und in fast jedem Projekt dieselben:

• Die Cookie-Abfrage. Sie legt sich über den Inhalt und wartet auf einen Klick, den ein Agent nicht sinnvoll setzen kann.
• Das Captcha. Es ist genau dafür gebaut, Automatisierung zu stoppen – und stoppt zuverlässig auch die gewollte.
• Formularfelder ohne erkennbare Bedeutung. Ein Feld, das im Quelltext „field_7“ heißt und dessen Beschriftung nur optisch daneben steht, ist für Software eine Blackbox.
• Inhalte hinter Interaktion. Was erst nach einem Klick auf Reiter, Akkordeon oder Slider erscheint, existiert für viele Agenten nicht.
• Fakten nur im Bild. Preise, Öffnungszeiten und Ansprechpartner in einer Grafik sind nicht lesbar – dasselbe Problem, das auch zitierfähige Inhalte verhindert.

Keiner dieser Punkte ist ein Fehler im engeren Sinn. Es sind Entscheidungen, die für menschliche Besucher getroffen wurden und für maschinelle Besucher niemand überprüft hat.

5. Die Vorarbeit haben Sie vermutlich schon geleistet

Hier kommt die gute Nachricht, und sie ist der eigentliche Grund, warum wir diesen Beitrag schreiben: Wer seine Website in den letzten zwei Jahren barrierefrei gemacht hat, hat die Hälfte der Arbeit erledigt.

Das Barrierefreiheitsstärkungsgesetz verlangt seit dem 28. Juni 2025 unter anderem genau das, was auch Agenten brauchen: Formularfelder mit richtig verknüpften Beschriftungen, eine sinnvolle Reihenfolge im Quelltext, aussagekräftige Alt-Texte, Bedienbarkeit ohne Maus. Ein Screenreader und ein Agent sind nicht dasselbe, aber sie stellen dieselbe Grundanforderung: Der Zweck eines Elements muss aus dem Code hervorgehen, nicht aus dem Layout.

Eine Website, die ein Screenreader zuverlässig vorlesen kann, kann ein Agent auch bedienen.

Wer Barrierefreiheit bisher als Pflichtübung abgehakt hat, bekommt jetzt den zweiten Nutzen dafür. Wer sie aufgeschoben hat, hat ab heute ein zweites Argument.

6. Was Sie bewusst nicht öffnen sollten

„Für Agenten optimieren“ heißt nicht, alle Türen aufzumachen. Drei Grenzen halten wir für richtig.

Training ist kein Zugriff, dem Sie stillschweigend zustimmen müssen. Seit September 2025 gibt es dafür eine saubere Ausdrucksform in der robots.txt: die Content Signals Policy mit den drei Signalen search, ai-input und ai-train. Sie können damit erlauben, in Suchergebnissen und KI-Antworten vorzukommen, und gleichzeitig dem Training widersprechen. Der Text der Policy nimmt ausdrücklich Bezug auf Artikel 4 der EU-Richtlinie 2019/790 und ist damit mehr als eine Bitte – auch wenn die Durchsetzung offen bleibt.

Nicht jeder Bereich ist öffentlich. Kundenbereiche, Preislisten hinter Login, interne Dokumente: Was für Menschen zugangsbeschränkt ist, bleibt es auch für Agenten. Ein Agent im Auftrag eines Kunden darf sich anmelden. Ein Agent ohne Auftrag hat dort nichts zu suchen.

Spam-Schutz bleibt. Die Antwort auf agentischen Verkehr ist nicht, das Captcha zu entfernen – die Formularspam-Lage hat sich nicht verbessert. Sinnvoll ist, zu differenzieren: ausgewiesene Agenten durchlassen, anonyme Automatisierung weiter prüfen. Wenn Ihr Spam-Schutz das nicht kann, ist das ein Grund, ihn zu wechseln, nicht ihn abzuschalten. Wir setzen dafür überwiegend Friendly Captcha ein, das ohne Rätselbilder arbeitet.

7. Shops: real, aber noch nicht hier

Für Onlineshops geht die Entwicklung einen Schritt weiter. OpenAI und Stripe haben im Herbst 2025 das Agentic Commerce Protocol veröffentlicht, ein offenes Protokoll für Käufe direkt im Chat. Der Kauf läuft über den Händler, das Protokoll standardisiert nur die Verständigung dazwischen. Gestartet ist das im September 2025 mit US-Verkäufern von Etsy, Shopify-Händler waren angekündigt – der Kreis bleibt zunächst auf die USA begrenzt.

Für einen WooCommerce-Shop in Deutschland bedeutet das heute keinen Handlungsdruck. Was sich trotzdem lohnt, ist ohnehin überfällig: Produktdaten strukturiert pflegen, Preis und Verfügbarkeit maschinenlesbar auszeichnen, Versandkosten und Rückgaberecht als Text hinterlegen. Wir sortieren das unter „gutes Schema Markup“ ein, nicht unter „agentischer Handel“.

8. Was wir konkret empfehlen

In dieser Reihenfolge, vom Aufwand her aufsteigend:

1. Prüfen, was Ihr Hosting, Ihre Firewall oder Ihr Sicherheits-Plugin gerade pauschal blockiert. In der Praxis ist das der häufigste unbeabsichtigte Türschließer.
2. robots.txt und Content Signals bewusst setzen, statt eine Standarddatei stehen zu lassen.
3. Formulare technisch aufräumen: verknüpfte Beschriftungen, sprechende Feldnamen, korrekte Autovervollständigung. Zahlt für Barrierefreiheit, Nutzerfreundlichkeit und Agenten gleichzeitig.
4. Spam-Schutz differenzieren statt entfernen.
5. Zentrale Fakten aus Bildern in Text überführen.

Nichts davon ist ein Relaunch. Das ist Wartungsarbeit an einer Website, die ohnehin gepflegt werden muss.

9. Fazit

Die Website bekommt gerade ein drittes Publikum, und dieses Publikum liest nicht nur, es will etwas erledigen. Das ist kein Grund, alles umzubauen, und keiner, alles zuzumachen. Es ist ein Grund, drei Fragen einmal bewusst zu beantworten: Wer darf lesen, wer darf handeln, wer darf trainieren?

Wer diese drei Fragen sauber getrennt beantwortet, muss sich nicht jedes halbe Jahr neu positionieren, wenn ein Anbieter ein neues Protokoll ankündigt. Und wer seine Website barrierefrei und technisch ordentlich gebaut hat, wird feststellen, dass er den größten Teil der Antwort schon gegeben hat.