Einen automatisierten Client identifizierbar machen: User-Agent, Kontaktadresse, Robots-Regeln und Ratenbegrenzungs-Etikette

Ziel

Ein automatisierter Client sein, den eine Site-Betreiberin oder ein Site-Betreiber in einer Logzeile erkennen, bei Problemen kontaktieren und über die bereits vorhandenen Mechanismen steuern kann, statt einer, der sich nicht von Missbrauch unterscheiden lässt und pauschal gesperrt wird.

Voraussetzungen

Kontrolle über die HTTP-Header, die der eigene Client sendet, und über seine Anfragerate. Eine Seite, die beschreibt, was der Client tut und wie seine Betreiberin oder sein Betreiber zu erreichen ist.

Schritte

1. Bei jeder Anfrage einen User-Agent mit Produkt-Token, Version und einem Link zur Beschreibungsseite senden, zum Beispiel Mozilla/5.0 (compatible; ExampleBot/0.1; https://www.example.com/bot.html). RFC 9309 verwendet genau diese Form und besagt, dass die Identifikationszeichenkette den Zweck des Crawlers beschreiben sollte; RFC 9110 definiert den Header als eine Folge von Produktkennungen mit der wichtigsten zuerst und rät von unnötig feinkörnigen Details ab.
2. Das Produkt-Token so wählen, dass es in einer robots.txt-Zeile user-agent erscheinen kann: RFC 9309 beschränkt es auf Buchstaben, Unterstriche und Bindestriche und besagt, dass es eine Teilzeichenkette des User-Agent-Headers sein sollte, sodass ExampleBot im Header einer Betreiberin oder einem Betreiber erlaubt, user-agent: ExampleBot zu schreiben und allein den eigenen Client anzusprechen.
3. Vor dem Abruf von Seiten einer Site /robots.txt lesen und die Gruppe anwenden, deren Token ohne Gross-/Kleinschreibung mit dem eigenen übereinstimmt; passt keines, die Gruppe * anwenden; gibt es keine, ist der Zugriff unbeschränkt. Pfade ab dem ersten Oktett abgleichen und die spezifischste Regel verwenden, wie es die RFC von Crawlern verlangt.
4. Den Client nicht als Browser tarnen, um eine Regel zu umgehen; sperrt eine Site das eigene Token, besteht die Antwort darin, die Betreiberin oder den Betreiber über die veröffentlichte Adresse zu kontaktieren, nicht in einem anderen Header.
5. 429 Too Many Requests (RFC 6585) als Anweisung behandeln: anhalten, mindestens den Wert von Retry-After abwarten, sofern angegeben (RFC 9110 erlaubt Sekunden oder ein HTTP-Datum), dann mit niedrigerer Rate fortsetzen. Dasselbe bei 503 mit Retry-After anwenden.
6. Ein Budget pro Host einhalten: eine kleine Anzahl gleichzeitiger Verbindungen und eine Pause zwischen Anfragen an denselben Host, niedriger bei kleinen Sites. Abgerufenes cachen und bedingte Anfragen verwenden, damit wiederholte Lesevorgänge der Betreiberin oder dem Betreiber nichts kosten.
7. Einen Accept-Header senden, der dem entspricht, was verarbeitet werden kann, und maschinenlesbare Formate der Site (Feeds, Sitemaps, eine API, llms.txt) dem Crawlen von HTML vorziehen.

Erwartetes Ergebnis

Die eigenen Anfragen erscheinen in Zugriffsprotokollen unter einem erkennbaren Namen mit einer funktionierenden Kontaktadresse; eine Betreiberin oder ein Betreiber, die oder der langsamer oder ganz ausschliessen möchte, kann dies mit einer Zeile in robots.txt oder mit 429-Antworten tun und muss nie einen Adressbereich sperren, der auch anderen Personen dient.

Grenzen und Prüfbasis

Dies ist eine Zusammenfassung von Etikette und Standards, keine rechtliche Analyse; Nutzungsbedingungen der Site und lokales Recht sind eigene Fragen. RFC 9309 regelt Crawler, die öffentliche Seiten lesen; eine API, die mit einem Schlüssel aufgerufen wird, hat ihre eigenen dokumentierten Grenzen, die Vorrang haben.

Crawling oder nutzerausgelöster Abruf

RFC 9309 ist auf Crawler beschränkt. Im Client zwei Fälle unterscheiden: ein Crawl (Links verfolgen, einen Index aufbauen, Trainingsmaterial sammeln) befolgt robots.txt ausnahmslos und identifiziert sich mit einem Crawler-Token; ein nutzerausgelöster Abruf (eine einzelne Seite, weil eine Person gerade darum gebeten hat) identifiziert sich mit einem Token, das dies angibt, ruft nur diese Seite ab, folgt keinen Links, behält den Inhalt nicht über die Sitzung hinaus und verwendet ihn nicht zum Training. Mehrere grosse Betreiber veröffentlichen für die beiden Fälle getrennte Tokens; eine Betreiberin oder ein Betreiber, die oder der Crawler ausgeschlossen hat, hat üblicherweise über Crawling entschieden, nicht über eine einzelne lesende Person, die im Auftrag einer Person handelt. Sperrt eine Site auch das Token für nutzerausgelöste Abrufe, wird auch diese Entscheidung respektiert.