Robots.txt-parser

Een bestand is een reeks records. Een groep begint met een of meer User-agent-regels, gevolgd door Allow- en Disallow-regels die voor die crawlers gelden. Een nieuwe User-agent-regel na regels begint een nieuwe groep; meerdere User-agent-regels achter elkaar delen één groep (een crawler met twee namen heeft dit nodig). Losse records zoals Sitemap kunnen overal voorkomen. # start een commentaar overal in een regel. Veldnamen zijn hoofdletterongevoelig; paden niet.

1. Zoek de groep waarvan de User-agent-waarde een deelreeks is van de naam van de crawler; voeg alle overeenkomende groepen samen. Als er geen is, gebruik de *-groep; als ook die ontbreekt, is alles toegestaan. 2. Test het pad tegen elke regel: matching is op basis van voorvoegsels, hoofdlettergevoelig, en */$ werken als jokertekens. 3. De langste overeenkomende regel wint; bij gelijke lengte wint Allow van Disallow. Geen overeenkomende regel betekent toegestaan. En wat de regels ook zeggen, /robots.txt zelf is impliciet toegestaan — een crawler zou de regels anders niet kunnen lezen.

• Denken dat robots.txt toegang blokkeert. Het is een verzoek aan beleefde crawlers, geen muur: schurkachtige scrapers negeren het volledig, en het heeft geen effect op wat een browser kan openen. Voor echte bescherming gebruikt u authenticatie; om alleen zoekmachines te sturen, is robots.txt het juiste hulpmiddel.
• Verwachten dat Disallow: / een pagina uit de zoekresultaten haalt. Het stopt het crawlen, niet het indexeren: als andere pagina's naar de uwe linken, kan een zoekmachine de URL nog steeds tonen (zonder beschrijving). De noindex-metatag of responsheader is het verwijderinstrument.
• Vertrouwen op volgorde in plaats van lengte. De eerste overeenkomende regel wint niet — de meest specifieke (langste) regel wint. Regels herschikken om het gedrag te "repareren" heeft geen effect; maak de bedoelde regel langer.
• CSS en JS blokkeren. Het uitsluiten van /*.css$ en /*.js$ was vroeger een gebruikelijke "optimalisatie"; renderers hebben die bestanden nu nodig om de pagina te zien zoals bezoekers dat doen, en een half gerenderde pagina kan slechter scoren.
• Eén grote groep als documentatie behandelen. Commentaarregels binnen een groep zijn prima, maar een alinea proza vóór de eerste User-agent-regel zonder # is een parseerfout die toegiftige parsers in verwarring kan brengen.

Ondersteunen alle crawlers Allow, * en $? De grote wel, en RFC 9309 standaardiseert alle drie. Sommige kleinere of oudere crawlers begrijpen alleen Disallow en lezen * letterlijk — een reden om regels eenvoudig te houden wanneer dat kan.

Wat betekent een lege Disallow:? "Niets weigeren" — de groep staat uitdrukkelijk alles toe. Dit komt meestal voor wanneer iemand een sjabloon bewerkt en het pad verwijdert maar de richtlijn laat staan; de controle wijst er op.

Hoe groot mag het bestand zijn? RFC 9309 vereist dat parsers minstens 500 KiB aankunnen; daarboven kan een crawler stoppen met lezen en de rest als geweigerd beschouwen. Blijf er ruim onder, en als het enorm groeit, overweeg dan of crawlbeheer niet beter in paginaheaders hoort.

Waarom zegt de matcher dat /robots.txt is toegestaan, zelfs onder Disallow: /? Omdat de standaard dat letterlijk zo zegt: het robotsbestand zelf is impliciet toegestaan. De urllib.robotparser van Python en andere implementaties volgen dit speciale geval niet — een van de kleine verschillen tussen praktijkparsers die deze pagina in haar zelftest documenteert.

Is een Disallow-pad hoofdlettergevoelig? Ja. /Private/ en /private/ zijn verschillende paden. De veldnaam disallow mag in elke schrijfwijze, maar de waarde moet exact overeenkomen met de URL.