Robots.txt Specificaties

Samenvatting

Dit document beschrijft hoe Google omgaat met het robots.txt-bestand waarmee u kunt bepalen hoe de websitecrawlers van Google crawlen en openbaar indexeren toegankelijke websites.

Wat is er veranderd

Op 1 juli 2019 kondigde Google aan dat het robots.txt-protocol eraan werkt om een internetstandaard te worden. Die wijzigingen worden in dit document weergegeven.

Lijst met wijzigingen

Dit is wat er is veranderd:

  • De sectie “Taal van vereisten” in dit document is verwijderd omdat de taal specifiek voor het internetconcept is.
  • Robots.txt accepteert nu alle op URI gebaseerde protocollen.
  • Google volgt ten minste vijf omleidingshops. Omdat er nog geen regels zijn opgehaald, worden de omleidingen gedurende ten minste vijf hops gevolgd en als er geen robots.txt wordt gevonden, behandelt Google het als een 404 voor de robots.txt. Het verwerken van logische omleidingen voor het robots.txt-bestand op basis van HTML-inhoud die 2xx retourneert (frames, JavaScript of omleidingen van het meta-vernieuwingstype) wordt afgeraden en de inhoud van de eerste pagina wordt gebruikt om toepasselijke regels te vinden.
  • Voor 5xx: als het robots.txt-bestand langer dan 30 dagen onbereikbaar is, wordt de laatste kopie in de cache van het robots.txt-bestand gebruikt, of als dit niet beschikbaar is, gaat Google ervan uit dat er geen crawlbeperkingen zijn.
  • Google behandelt mislukte verzoeken of onvolledige gegevens als een serverfout.
  • “Records” worden nu “regels” of “regels” genoemd, al naargelang het geval.
  • Google ondersteunt de verwerking van <field> elementen met eenvoudige fouten of typefouten (bijvoorbeeld “useragent” in plaats van “user-agent”).
  • Google dwingt momenteel een maximale grootte van 500 kibibytes (KiB) af en negeert inhoud na die limiet.
  • Bijgewerkte formele syntaxis zodat deze geldig is Augmented Backus-Naur Form (ABNF) volgens RFC5234 en om UTF-8-tekens in het robots.txt-bestand te dekken.
  • De definitie van ‘groepen’ bijgewerkt “om het korter en duidelijker te maken. Een voorbeeld toegevoegd voor een lege groep.
  • Verwijzingen naar het verouderde Ajax Crawling Scheme verwijderd.

Basisdefinities

Definities
Crawler Een crawler is een service of agent die websites crawlt. Over het algemeen is een crawler automatisch en benadert recursief bekende URL’s van een host die inhoud blootlegt die toegankelijk is met standaard webbrowsers. Als er nieuwe URL’s worden gevonden (op verschillende manieren, zoals via links op bestaande, gecrawlde pagina’s of vanuit sitemapbestanden), worden deze ook op dezelfde manier gecrawld.
Gebruiker- agent Een manier om een specifieke crawler of set crawlers te identificeren.
Directives De lijst met toepasselijke richtlijnen voor een crawler of een groep crawlers uiteengezet in het robots.txt-bestand.
URL Uniform Resource Locators zoals gedefinieerd in RFC 1738.
Google-specifiek Deze elementen zijn specifiek voor de implementatie door Google van robots.txt en zijn mogelijk niet relevant voor andere partijen.

Toepasbaarheid

De richtlijnen in dit document worden gevolgd door alle geautomatiseerde crawlers bij Google. een agent opent URL’s namens een gebruiker (bijvoorbeeld voor vertaling, handmatig ingeschreven feeds, malware-analyse), deze richtlijnen hoeven niet van toepassing te zijn.

Fi bestandslocatie en geldigheidsbereik

Het robots.txt-bestand moet in de hoofddirectory van de host staan, toegankelijk via het juiste protocol en poortnummer. Algemeen aanvaarde protocollen voor robots.txt zijn allemaal gebaseerd op URI’s, en specifiek voor Google Zoeken (bijvoorbeeld het crawlen van websites) zijn “http” en “https”. Op http en https wordt het robots.txt-bestand opgehaald met een niet-voorwaardelijk HTTP-GET-verzoek.

Google-specifiek: Google accepteert en volgt robots.txt-bestanden voor FTP-sites. FTP-gebaseerde robots.txt-bestanden zijn toegankelijk via het FTP-protocol, met behulp van een anonieme login.

De richtlijnen in het robots.txt-bestand zijn alleen van toepassing op de host, het protocol en het poortnummer waar het bestand wordt gehost. .

Voorbeelden van geldige robots.txt-URL’s

Omgaan met HTTP-resultaatcodes

Er zijn over het algemeen drie verschillende resultaten wanneer robots.txt-bestanden worden opgehaald:

  • volledig toegestaan: alle inhoud mag worden gecrawld.
  • volledig niet toestaan: er mag geen inhoud worden gecrawld.
  • voorwaardelijk toestaan: de richtlijnen in het robots.txt-bestand bepalen de mogelijkheid om bepaalde inhoud te crawlen.
Omgaan met HTTP-resultaatcodes
2xx (succesvol) HTTP-resultaatcodes die succes aangeven, resulteren in een “voorwaardelijk toestaan” van kruipen.
3xx (omleiding) Google volgt ten minste vijf omleidingshops zoals gedefinieerd door RFC 1945 voor HTTP / 1.0 en stopt vervolgens en behandelt het als een 404 Het omgaan met robots.txt-omleidingen naar niet-toegestane URL’s wordt afgeraden; aangezien er nog geen regels zijn opgehaald, worden de omleidingen gedurende ten minste vijf hops gevolgd en als er geen robots.txt wordt gevonden, behandelt Google het als een 404 voor de robots.txt. Het verwerken van logische omleidingen voor het robots.txt-bestand op basis van HTML-inhoud die 2xx retourneert (frames, JavaScript of omleidingen van het meta-vernieuwingstype) wordt afgeraden en de inhoud van de eerste pagina wordt gebruikt om toepasselijke regels te vinden.
4xx (clientfouten) Alle 4xx-fouten worden op dezelfde manier behandeld en er wordt aangenomen dat er geen geldig robots.txt-bestand bestaat. aangenomen dat er geen beperkingen zijn. Dit is een “volledige toestemming” voor crawlen.
5xx (serverfout)

Serverfouten worden gezien als tijdelijke fouten die resulteren in een ‘volledig niet toestaan’ van crawlen. Het verzoek wordt opnieuw geprobeerd totdat een niet-serverfout HTTP-resultaatcode wordt verkregen. Een 503-fout (Service niet beschikbaar) resulteert in vrij vaak opnieuw proberen. Als de robots.txt is niet bereikbaar gedurende meer dan 30 dagen, wordt de laatste kopie van het robots.txt-bestand in de cache gebruikt. Indien deze niet beschikbaar is, gaat Google ervan uit dat er geen crawlbeperkingen zijn. Om het crawlen tijdelijk op te schorten, wordt aanbevolen een 503 HTTP-resultaatcode weer te geven.

Google-specifiek: als we kunnen vaststellen dat een site onjuist is geconfigureerd om 5xx te retourneren in plaats van een 404 voor ontbrekende pagina’s, behandelen we een 5xx-fout van die site als een 404.

Mislukt verzoeken of onvolledige gegevens Het verwerken van een robots.txt-bestand dat niet kan worden opgehaald vanwege DNS- of netwerkproblemen, zoals time-outs, ongeldige reacties, opnieuw instellen of verbroken verbindingen en HTTP-chunking-fouten, wordt behandeld als een serverfout.
Caching robots.txt-inhoud wordt over het algemeen maximaal 24 uur in de cache opgeslagen, maar kan langer in de cache worden bewaard in situaties waarin het cachegeheugen wordt vernieuwd versie is niet mogelijk (bijvoorbeeld vanwege time-outs of 5xx-fouten). De reactie in de cache kan worden gedeeld door verschillende crawlers. Google kan de levensduur van de cache verlengen of verkorten op basis van max-age Cache-Control HTTP-headers.

Bestandsformaat

Het verwachte bestandsformaat is platte tekst gecodeerd in UTF-8. Het bestand bestaat uit regels gescheiden door CR, CR / LF of LF.

Alleen geldige regels worden in aanmerking genomen; alle andere inhoud wordt genegeerd. Als het resulterende document bijvoorbeeld een HTML-pagina is, wordt alleen rekening gehouden met geldige tekstregels, de rest wordt zonder waarschuwing of fout weggegooid.

Als een tekencodering wordt gebruikt die ertoe leidt dat tekens worden gebruikt die geen subset van UTF-8 zijn, kan dit ertoe leiden dat de inhoud van het bestand onjuist wordt geparseerd.

Een optionele Unicode BOM (bytevolgorde-markering) aan het begin van het robots.txt-bestand wordt genegeerd.

Elke geldige regel bestaat uit een veld, een dubbele punt en een waarde. Spaties zijn optioneel (maar aanbevolen om de leesbaarheid te verbeteren). Opmerkingen kunnen op elke locatie in het bestand worden opgenomen met het teken “#”; alle inhoud na het begin van een opmerking tot het einde van de regel wordt als opmerking behandeld en genegeerd. Het algemene formaat is <field>:<value><#optional-comment>. Witruimte aan het begin en aan het einde van de regel wordt genegeerd.

Het element <field> is niet hoofdlettergevoelig. Het < waarde > -element kan hoofdlettergevoelig zijn, afhankelijk van het < veld > element.

Afhandeling van <field> elementen met eenvoudige fouten of typefouten (bijvoorbeeld “useragent” in plaats van ” user-agent “) wordt niet ondersteund.

Een maximale bestandsgrootte kan per crawler worden afgedwongen. Inhoud die na de maximale bestandsgrootte komt, wordt genegeerd. Google hanteert momenteel een maximale grootte van 500 kibibytes (KiB). Om de grootte van het robots.txt-bestand te verkleinen, consolideert u richtlijnen die zouden leiden tot een te groot robots.txt-bestand. Plaats bijvoorbeeld uitgesloten materiaal in een aparte directory.

Formele syntaxis / definitie

Hier is een Augmented Backus-Naur Form (ABNF) beschrijving, zoals beschreven in RFC 5234

Groepering van regels en regels

Een of meer user-agent regels die worden gevolgd door een of meer regels. De groep wordt beëindigd door een regel user-agent of het einde van het bestand. De laatste groep heeft mogelijk geen regels, wat betekent dat alles impliciet is toegestaan.

Voorbeeldgroepen:

user-agent: adisallow: /cuser-agent: bdisallow: /duser-agent: euser-agent: fdisallow: /guser-agent: h

Er zijn vier verschillende groepen gespecificeerd :

  • Eén groep voor “a”
  • Eén groep voor “b”
  • Eén groep voor zowel “e” als “f”
  • Eén groep voor “h”

Behalve de laatste groep (groep “h”), heeft elke groep zijn eigen groepslidlijn. De laatste groep (groep “h”) is leeg.Let op het optionele gebruik van witruimte en lege regels om de leesbaarheid te verbeteren.

Rangorde voor user agents

Slechts één groep is geldig voor een bepaalde crawler. De crawler moet de juiste groep regels bepalen door de groep te zoeken met de meest specifieke user-agent die nog steeds overeenkomt. Alle andere groepen worden door de crawler genegeerd. De user-agent is hoofdlettergevoelig. Alle niet-overeenkomende tekst wordt genegeerd (bijvoorbeeld, zowel googlebot/1.2 als googlebot* zijn gelijk aan googlebot). De volgorde van de groepen in het robots.txt-bestand is niet relevant.

Als er meer dan één groep is gedeclareerd voor een specifieke user-agent, worden alle regels van de groepen die van toepassing zijn op de specifieke user-agent gecombineerd in een enkele groep.

Voorbeelden

Voorbeeld 1

Ervan uitgaande dat het volgende robots.txt-bestand:

 user-agent: googlebot-news (group 1) user-agent: * (group 2) user-agent: googlebot (group 3) 

Dit is hoe de crawlers de relevante groep:

Groep gevolgd per crawler
Googlebot News De gevolgde groep is groep 1. Alleen de meest specifieke groep wordt gevolgd, alle andere worden genegeerd.
Googlebot (web) De gevolgde groep is groep 3.
Googlebot Afbeeldingen De groep die wordt gevolgd is groep 3. Er is geen specifieke googlebot-images groep, dus de meer algemene groep wordt gevolgd .
Googlebot Nieuws (bij het crawlen van afbeeldingen) > De gevolgde groep is groep 1. Deze afbeeldingen worden gecrawld voor en door Googlebot News, daarom wordt alleen de Googlebot News-groep gevolgd.
Otherbot (web) De gevolgde groep is groep 2.
Otherbot (nieuws) De gevolgde groep is groep 2. Zelfs als er een vermelding is voor een gerelateerde crawler, is deze alleen geldig als deze specifiek overeenkomt.

Voorbeeld 2

Ervan uitgaande dat het volgende robots.txt-bestand:

 user-agent: googlebot-news disallow: /fish user-agent: * disallow: /carrots user-agent: googlebot-news disallow: /shrimp 

Dit is hoe de crawlers groepen zouden samenvoegen die relevant zijn voor een specifieke user-agent:

 user-agent: googlebot-news disallow: /fish disallow: /shrimp user-agent: * disallow: /carrots 

Zie ook de crawlers en user-agent strings van Google.

Regels voor groepslid

Alleen standaard regels voor groepslid worden in deze sectie behandeld. Deze regels worden voor de crawlers ook wel “richtlijnen” genoemd. Deze richtlijnen worden gespecificeerd in de vorm van directive: waarbij optioneel is. Standaard zijn er geen beperkingen voor crawlen voor de aangewezen crawlers. Richtlijnen zonder een worden genegeerd.

De -waarde, indien opgegeven, moet worden gezien als relatief ten opzichte van de root van de website waarvoor het robots.txt-bestand is opgehaald (met hetzelfde protocol, poortnummer, host- en domeinnamen). De padwaarde moet beginnen met “/” om de root aan te duiden. Het pad is hoofdlettergevoelig. Meer informatie is te vinden in de sectie “URL-overeenkomsten op basis van padwaarden” hieronder.

disallow

De disallow instructie specificeert paden die mag niet worden geopend door de aangewezen crawlers. Als er geen pad is opgegeven, wordt de instructie genegeerd.

Gebruik:

disallow: 

allow

De allow richtlijn specificeert paden die toegankelijk zijn voor de aangewezen crawlers. Als er geen pad is opgegeven, wordt de instructie genegeerd.

Gebruik:

allow: 

URL-overeenkomst op basis van padwaarden

De padwaarde wordt gebruikt als basis om te bepalen of een regel al dan niet van toepassing is op een specifieke URL op een site. Met uitzondering van jokertekens, wordt het pad gebruikt om overeen te komen met het begin van een URL (en eventuele geldige URL’s die met hetzelfde pad beginnen). Niet-7-bits ASCII-tekens in een pad kunnen worden opgenomen als UTF-8-tekens of als UTF-8-gecodeerde tekens met procent-escapecodes volgens RFC 3986.

Google, Bing en andere grote zoekmachines ondersteunen een beperkte vorm van “jokertekens” voor padwaarden. Dit zijn:

  • * duidt 0 of meer instanties van een geldig teken aan.
  • $ geeft het einde van de URL aan.

Door Google ondersteunde regels voor niet-groepslid

Google, Bing en andere grote zoekmachines ondersteunen sitemap, zoals gedefinieerd door sitemaps.org.

Gebruik:

sitemap: 

verwijst naar een sitemap, sitemapindexbestand of gelijkwaardige URL. De URL hoeft niet op dezelfde host te staan als het robots.txt-bestand. Er kunnen meerdere sitemap -items bestaan. Als niet-groepslidlijnen zijn deze niet aan een specifieke user-agent gebonden en kunnen ze door alle crawlers worden gevolgd, op voorwaarde dat dit niet is toegestaan.

Prioriteitsvolgorde voor groepslidregels

Op groepslidniveau, in het bijzonder voor allow en disallow richtlijnen, de meest specifieke regel gebaseerd op de lengte van het item overtreft de minder specifieke (kortere) regel. In het geval van conflicterende regels, inclusief regels met jokertekens, wordt de minst beperkende regel gebruikt.

Testen van robots.txt-markeringen

Google biedt twee opties voor het testen van robots.txt-markeringen:

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *