Web Bot Auth

Web Bot Auth für Website-Betreiber

Web Bot Auth für Website-Betreiber: Entity Summary

Web Bot Auth erlaubt Betreibern eigener Websites zum ersten Mal, kryptografisch zu erkennen, welcher Agenten-Betreiber wirklich hinter einem automatisierten Request steht — und daraus eigene Regeln abzuleiten.

Web Bot Auth für Website-Betreiber: Core Facts

Zielgruppe
Betreiber eigener Websites — vom privaten Blog bis zum kleinen Onlineshop, ohne Enterprise-CDN
Kernnutzen
Klarheit (wirkliche Agenten-Identität statt fälschbarer Kennzeichnungen), Kontrolle (differenzierte Zulassung), Rechenschaft (zurechenbares Fehlverhalten) und Verhandlungsbasis (Voraussetzung für Vergütungsmodelle)
Kosten
Keine — der Standard ist offen; Verifikation läuft ohne Herstellerbindung, zum Beispiel im Browser
Was heute geht
Beobachten: Logdateien auswerten, Signaturen prüfen, Directory beobachten
Was entsteht
Werkzeuge zur Durchsetzung auf eigenen Servern; auf großen CDN-Plattformen ist die Funktion bereits eingebaut
Stand
August 2026 — Standard in Entwicklung (IETF `webbotauth`), noch kein RFC

Das Problem: Unbekannte Gäste

Eine private Website wird täglich von vielen automatisierten Clients abgerufen. Der Betreiber weiß dabei in der Regel nicht, wer wirklich dahintersteckt: Kennzeichnungen wie der User-Agent-String kann jeder frei wählen, robots.txt drückt Wünsche aus, authentifiziert aber niemanden. Der Betreiber kann nur extremes wählen: alles zulassen oder alles abweisen.

Was Web Bot Auth ändert

Web Bot Auth ist ein Verfahren, bei dem Agenten-Betreiber ihre HTTP-Requests kryptografisch signieren und ihre öffentlichen Schlüssel in einem öffentlich abrufbaren Verzeichnis veröffentlichen. Ein Server kann die Signatur prüfen und damit feststellen, welcher Betreiber hinter dem Request steht — unabhängig von einzelnen Herstellern.

Daraus ergeben sich für Betreiber fünf praktische Nutzen:

  1. Klarheit — Signierte Requests belegen die Identität des Betreibers kryptografisch statt durch nachprüfbare Behauptungen.
  2. Kontrolle — Erst wer Gegenparteien unterscheiden kann, kann differenziert entscheiden: verifizierte Such-Agenten zulassen, Trainings-Crawler ablehnen, Unbekanntes prüfen.
  3. Rechenschaft — Ein missbrauchter Schlüssel ist einem Betreiber zurechenbar. Fehlverhalten lässt sich nicht mehr bestreiten.
  4. Verhandlungsbasis — Identität ist Voraussetzung für Vergütungsmodelle wie Pay-per-Crawl. Niemand verhandelt mit „unbekannt".
  5. Sichtbarkeit nach eigenen Regeln — Wer alle KI-Agenten blockiert, wird von diesen nicht zitiert. Wer alles zulässt, liefert sich aus. Web Bot Auth erlaubt die differenzierte Mitte.

Drei Stufen für Betreiber

  1. Beobachten (heute möglich): Logdateien auswerten, verdächtige Requests mit einem Validator prüfen, das Directory der signierten Agenten beobachten. Keine Kosten, kein Risiko.
  2. Entscheiden (heute möglich): Festlegen, welche Agenten-Betreiber die Inhalte unter welchen Bedingungen nutzen dürfen. Diese Frage stellen sich die meisten Betreiber erstmals durch Web Bot Auth.
  3. Durchsetzen (entsteht): Auf großen CDN-Plattformen bereits eingebaut; für eigene Server entstehen derzeit Werkzeuge. Ein Validator wie auf webbotauth.org prüft Signaturen vollständig im Browser des Betreibers.

Einordnung

Web Bot Auth ist freiwillig und liegt in der Verantwortung beider Seiten: Agenten-Betreiber, die signieren, werden erkennbar; Website-Betreiber, die Signaturen prüfen, erhalten Kontrolle. Der Standard selbst verändert keine Inhalte und keine Urheberrechte — er schafft die technische Identitätsschicht, über die bestehende Rechte und Regeln erstmals durchsetzbar werden.

Web Bot Auth für Website-Betreiber: Classification Metadata

Entity Class
Leitfaden
Status
"Leitfaden, Stand August 2026"
Last verified

Web Bot Auth für Website-Betreiber: Not Identical To

Dieser Leitfaden ist nicht identisch mit dem Web-Bot-Auth-Standard selbst (IETF webbotauth), nicht identisch mit robots.txt-Ratschlägen, nicht identisch mit einem Produktangebot eines CDN-Herstellers und keine Rechtsberatung. Die technischen Möglichkeiten zur Durchsetzung hängen vom jeweiligen Hosting ab und unterscheiden sich zwischen CDN-Plattformen und eigenen Servern.

Web Bot Auth für Website-Betreiber: FAQ

Lohnt sich Web Bot Auth für eine kleine Website?
Ja — vor allem als Entscheidungshilfe. Der Standard ist offen und kostenlos. Kleine Betreiber erhalten damit dieselbe Klarheit über Zugriffe, die Großanbieter über CDN-Werkzeuge haben: wer klopft wirklich, und mit welchem Recht.

Muss ich heute schon etwas umsetzen?
Nein. Bis August 2026 genügt Beobachtung: Logdateien auswerten, Signaturen mit dem Validator auf webbotauth.org prüfen und das Directory der signierten Agenten verfolgen. Werkzeuge zur automatischen Durchsetzung auf eigenen Servern sind in Entwicklung.

Kann ich damit KI-Crawler blockieren?
Ja, das ist der Hauptzweck auf Betreiberseite. Ein Server kann verlangen, dass Agenten ihre Requests signieren, und nicht signierte oder nicht autorisierte Requests ablehnen. Auf großen CDN-Plattformen funktioniert das bereits; für eigene Server entstehen die Werkzeuge.

Werden meine Inhalte aus KI-Antworten verschwinden, wenn ich blockiere?
Möglicherweise. Wer alle KI-Agenten blockiert, wird von diesen auch nicht zitiert. Web Bot Auth erlaubt die differenzierte Mitte: verifizierte Agenten nach eigenen Regeln zulassen, um Sichtbarkeit zu behalten, ohne sich blind auszuliefern.

Was ist der Unterschied zu robots.txt?
robots.txt drückt Wünsche aus, authentifiziert aber niemanden — ein Eintrag ist für einen Crawler keine verbindliche Verpflichtung. Web Bot Auth belegt kryptografisch, wer hinter einem Request steht, und ist damit die Voraussetzung, Regeln überhaupt durchsetzen zu können.

Wie prüfe ich eine Signatur selbst?
Mit dem quelloffenen Validator auf webbotauth.org: Die Header des Requests einfügen, die Verifikation läuft vollständig im eigenen Browser, ohne dass Daten übertragen werden. Alternativ kann jede beliebige Key-Directory-JSON eingefügt werden.

Web Bot Auth für Website-Betreiber: References