Formalisierung der Robots Exclusion Protocol Spezifikation

Montag, 1. Juli 2019

Seit 25 Jahren ist das Robots Exclusion Protocol (REP) eine der grundlegendsten und kritischsten Komponenten des Webs. Es ermöglicht Website-Besitzern, automatisierte Clients, zum Beispiel
Webcrawler, vom
Zugriff auf ihre Websites auszuschließen – entweder teilweise oder vollständig.

Im Jahr 1994 Martijn Koster
(selbst Webmaster) schuf den ersten Standard, nachdem Crawler seine Website überlastet hatten. Mit weiterem Input von anderen Webmastern wurde das REP geboren, und es wurde von Suchmaschinen übernommen, um Website-Besitzern die Verwaltung ihrer Serverressourcen zu erleichtern.

Das REP wurde jedoch nie zu einem offiziellen
Internetstandard, was bedeutet,
dass Entwickler das Protokoll im Laufe der Jahre etwas unterschiedlich interpretiert haben. Und seit seiner
Entstehung wurde das REP nicht aktualisiert, um heutige Sonderfälle abzudecken. Dies ist ein
schwieriges Problem für Website-Besitzer, da der mehrdeutige De-facto-Standard es schwierig machte,
die Regeln korrekt zu schreiben.

Wir wollten Website-Besitzern und Entwicklern helfen, fantastische Erlebnisse im Internet zu schaffen, anstatt sich darüber Gedanken machen zu müssen, wie man Crawler steuert. Zusammen mit dem ursprünglichen Autor des Protokolls, Webmastern und anderen Suchmaschinen haben wir dokumentiert, wie das REP im modernen Web verwendet wird, und es beim IETF eingereicht.

Der vorgeschlagene REP-Entwurf spiegelt über 20 Jahre realer Erfahrung wider, bei der man sich auf robots.txt-Regeln verlässt, die sowohl vom Googlebot als auch von anderen großen Crawlern sowie von etwa einer halben Milliarde Websites verwendet werden, die auf das REP vertrauen. Diese feingranularen Kontrollen geben dem Publisher die Macht zu entscheiden, was auf seiner Website gecrawlt und potenziell interessanten Nutzern angezeigt werden soll. Es ändert nicht die 1994 aufgestellten Regeln, sondern definiert im Wesentlichen alle undefinierten Szenarien für das Parsen und Matching von robots.txt und erweitert es für das moderne Web. Nennenswert:

1. Jedes
   URI-basierte Übertragungsprotokoll
   kann robots.txt verwenden. Es ist zum Beispiel nicht mehr auf HTTP beschränkt und kann auch für FTP oder
   CoAP
   verwendet werden.
2. Entwickler müssen mindestens die ersten 500
   Kibibyte einer robots.txt parsen.
   Die Definition einer maximalen Dateigröße stellt sicher, dass Verbindungen nicht zu lange offen bleiben, was unnötige Belastungen für Server verringert.
3. Eine neue maximale Caching-Zeit von 24 Stunden oder ein Cache-Direktiven-Wert, falls verfügbar, gibt Website-Besitzern die Flexibilität, ihre robots.txt zu aktualisieren, wann immer sie wollen, und Crawler überlasten Websites nicht mit robots.txt-Anfragen. Im Falle von HTTP könnten beispielsweise Cache-Control-Header verwendet werden, um die Caching-Zeit zu bestimmen.
4. Die Spezifikation sieht nun vor, dass, wenn eine zuvor zugängliche robots.txt-Datei aufgrund von Serverausfällen unzugänglich wird, bekannte nicht zugelassene Seiten für einenreasonably langen Zeitraum nicht gecrawlt werden.

Zusätzlich haben wir die
augmentierte Backus-Naur-Form
im Internet-Entwurf aktualisiert, um die Syntax von robots.txt besser zu definieren, was für Entwickler entscheidend ist, um die Zeilen zu parsen.

RFC steht für Request for Comments, und wir meinen es ernst: Wir haben den Entwurf beim IETF hochgeladen, um Feedback von Entwicklern zu erhalten, denen die grundlegenden Bausteine des Internets am Herzen liegen. Während wir daran arbeiten, Web-Creators die Kontrollen zu geben, die sie benötigen, um uns mitzuteilen, wie viele Informationen sie dem Googlebot zur Verfügung stellen möchten und damit in den Suchergebnissen erscheinen können, müssen wir sicherstellen, dass wir das richtig machen.

Wenn Sie uns einen Kommentar hinterlassen, uns Fragen stellen oder einfach hallo sagen möchten, finden Sie uns auf
Twitter und in unserer
Webmaster Community, sowohl offline

als auch online. Veröffentlicht von,
Henner ZellerLizzi Sassman
, und