Robots.txt-spesifikasjoner

Abstrakt

Dette dokumentet beskriver hvordan Google håndterer robots.txt-filen som lar deg kontrollere hvordan Googles nettsteds crawlere gjennomsøker og indekserer offentlig. tilgjengelige nettsteder.

Hva endret seg

1. juli 2019 kunngjorde Google at robots.txt-protokollen jobber for å bli en Internett-standard. Disse endringene gjenspeiles i dette dokumentet.

Endringsliste

Her er hva som har endret seg:

  • Fjernet delen «Kravsspråk» i dette dokumentet fordi språket er spesifikt for internettutkast.
  • Robots.txt godtar nå alle URI-baserte protokoller.
  • Google følger minst fem omdirigeringshumler. Siden det ikke ble hentet noen regler ennå, blir omdirigeringene fulgt i minst fem humle, og hvis ingen robots.txt blir funnet, behandler Google det som en 404 for robots.txt. Håndtering av logiske viderekoblinger for robots.txt-filen basert på HTML-innhold som returnerer 2xx (rammer, JavaScript eller meta-viderekoblinger av typen) frarådes og innholdet på den første siden brukes til å finne gjeldende regler.
  • Hvis robots.txt ikke er tilgjengelig i mer enn 30 dager, brukes den siste hurtigbufrede kopien av robots.txt, eller hvis den ikke er tilgjengelig, antar Google at det ikke er noen gjennomsøkingsbegrensninger.
  • Google behandler mislykkede forespørsler eller ufullstendige data som en serverfeil.
  • «Records» kalles nå «linjer» eller «regler», etter behov.
  • Google støtter ikke håndteringen av <field> elementer med enkle feil eller skrivefeil (for eksempel «useragent» i stedet for «user-agent»).
  • Google håndhever for tiden en størrelsesbegrensning på 500 kB (KiB), og ignorerer innhold etter denne grensen.
  • Oppdatert formell syntaks for å være gyldig Augmented Backus-Naur Form (ABNF) per RFC5234 og for å dekke for UTF-8 tegn i robots.txt.
  • Oppdaterte definisjonen av «grupper «for å gjøre det kortere og mer til poenget. Lagt til et eksempel for en tom gruppe.
  • Fjernet referanser til den avviklede Ajax-gjennomsøkingsordningen.

Grunnleggende definisjoner

Definisjoner
Crawler En crawler er en tjeneste eller agent som gjennomsøker nettsteder. Generelt sett er en crawler automatisk og får rekursivt tilgang til kjente URL-er til en vert som eksponerer innhold som er tilgjengelig med standard nettlesere. Etter hvert som nye nettadresser blir funnet (på forskjellige måter, for eksempel fra lenker på eksisterende, gjennomsøkte sider eller fra områdekartfiler), blir disse også gjennomsøkt på samme måte.
Bruker- agent Et middel til å identifisere en bestemt crawler eller et sett med crawlers.
Direktiver Listen over gjeldende retningslinjer for en crawler eller en gruppe crawlere som er angitt i robots.txt-filen.
URL Uniform Resource Locators som definert i RFC 1738.
Google-spesifikk Disse elementene er spesifikke for Googles implementering av robots.txt og er kanskje ikke relevante for andre parter.

Brukbarhet

Retningslinjene i dette dokumentet følges av alle automatiserte søkerobotter hos Google. Når en agent får tilgang til nettadresser på vegne av en bruker (for eksempel for oversettelse, manuelt abonnerte feeder, malware-analyse), trenger ikke disse retningslinjene å gjelde.

Fi le location and range of validity

Robots.txt-filen må være i vertsens toppkatalog, tilgjengelig via riktig protokoll og portnummer. Generelt aksepterte protokoller for robots.txt er alle URI-baserte, og for Google-søk spesifikt (for eksempel gjennomgang av nettsteder) er «http» og «https». På http og https blir robots.txt-filen hentet ved hjelp av en HTTP ikke-betinget GET-forespørsel.

Google-spesifikk: Google godtar og følger også robots.txt-filer for FTP-nettsteder. FTP-baserte robots.txt-filer er tilgjengelige via FTP-protokollen ved hjelp av en anonym pålogging.

Direktivene som er oppført i robots.txt-filen gjelder bare verten, protokollen og portnummeret der filen er vert .

Eksempler på gyldige robots.txt-URLer

Håndtering av HTTP-resultatkoder

Det er vanligvis tre forskjellige utfall når robots.txt-filer hentes:

  • full tillatelse: Alt innhold kan bli gjennomsøkt.
  • full tillatelse: Ingen innhold kan gjennomsøkes.
  • betinget tillatelse: Direktivene i robots.txt bestemmer muligheten til å gjennomsøke bestemt innhold.
Håndtering av HTTP-resultatkoder
2xx (vellykket) HTTP-resultatkoder som signaliserer suksess resulterer i en «betinget tillatelse» av å krype.
3xx (omdirigering) Google følger minst fem omdirigeringshopp som definert av RFC 1945 for HTTP / 1.0 og stopper og behandler det som en 404 Håndtering av robots.txt-viderekoblinger til ikke tillatte nettadresser frarådes. siden det ikke ble hentet noen regler ennå, blir omdirigeringene fulgt i minst fem humle, og hvis ingen robots.txt blir funnet, behandler Google det som en 404 for robots.txt. Håndtering av logiske viderekoblinger for robots.txt-filen basert på HTML-innhold som returnerer 2xx (rammer, JavaScript eller meta-viderekoblinger av typen type) frarådes og innholdet på den første siden brukes til å finne gjeldende regler.
4xx (klientfeil) Alle 4xx-feil behandles på samme måte, og det antas at ingen gyldig robots.txt-fil eksisterer. Det er antatt at det ikke er noen begrensninger. Dette er en «full tillatelse» for gjennomsøking.
5xx (serverfeil)

Serverfeil blir sett som midlertidige feil som resulterer i en «full tillatelse» av gjennomsøking. Forespørselen blir prøvd på nytt til en HTTP-resultatkode som ikke er serverfeil, oppnås. En feil på 503 (tjenesten utilgjengelig) resulterer i ganske hyppig prøving på nytt. Hvis robots.txt er ikke tilgjengelig i mer enn 30 dager, brukes den siste hurtigbufrede kopien av robots.txt. Hvis den ikke er tilgjengelig, antar Google at det ikke er noen gjennomsøkingsbegrensninger. For å midlertidig stanse gjennomsøking, anbefales det å levere en 503 HTTP-resultatkode.

Google-spesifikk: Hvis vi kan fastslå at et nettsted er feil konfigurert for å returnere 5xx i stedet for en 404 for manglende sider, behandler vi en 5xx-feil fra dette nettstedet som en 404.

mislyktes forespørsler eller ufullstendige data Håndtering av en robots.txt-fil som ikke kan hentes på grunn av DNS- eller nettverksproblemer, for eksempel tidsavbrudd, ugyldige svar, tilbakestillings- eller påhengsforbindelser, og HTTP-chunking-feil, blir behandlet som en serverfeil.
Bufring robots.txt-innhold er vanligvis hurtigbufret i opptil 24 timer, men kan hurtigbufres i situasjoner der oppdatering av hurtigbufret versjonen er ikke mulig (for eksempel på grunn av tidsavbrudd eller 5xx-feil). Det hurtigbufrede svaret kan deles av forskjellige gjennomsøkere. Google kan øke eller redusere cache-levetiden basert på HTTP-overskrifter for maksimal alder Cache-Control.

Filformat

Det forventede filformatet er ren tekst kodet i UTF-8. Filen består av linjer adskilt av CR, CR / LF eller LF.

Bare gyldige linjer blir vurdert; alt annet innhold ignoreres. Hvis det resulterende dokumentet for eksempel er en HTML-side, blir bare gyldige tekstlinjer tatt i betraktning, resten blir kastet uten advarsel eller feil.

Hvis det brukes en tegnkoding som resulterer i at tegn blir brukt som ikke er en delmengde av UTF-8, kan dette føre til at innholdet i filen blir analysert feil.

En valgfri Unicode BOM (bytebestillingsmerke) i begynnelsen av robots.txt-filen ignoreres.

Hver gyldig linje består av et felt, et kolon og en verdi. Plasser er valgfrie (men anbefales for å forbedre lesbarheten). Kommentarer kan inkluderes hvor som helst i filen ved å bruke tegnet «#»; alt innhold etter starten av en kommentar til slutten av linjen blir behandlet som en kommentar og ignorert. Det generelle formatet er <field>:<value><#optional-comment>. Hvitt mellomrom i begynnelsen og slutten av linjen ignoreres.

<field> -elementet er ikke skiftende på store og små bokstaver. < -verdien > -elementet kan være mellom store og små bokstaver, avhengig av < -feltet > element.

Håndtering av <field> elementer med enkle feil eller skrivefeil (for eksempel «brukeragent» i stedet for » user-agent «) støttes ikke.

En maksimal filstørrelse kan håndheves per søkerobot. Innhold som er etter maksimal filstørrelse blir ignorert. Google håndhever for tiden en størrelsesgrense på 500 kibibytes (KiB). For å redusere størrelsen på robots.txt-filen, konsolider direktiver som vil resultere i en overdimensjonert robots.txt-fil. Legg for eksempel ekskludert materiale i en egen katalog.

Formell syntaks / definisjon

Her er en Augmented Backus-Naur Form (ABNF) beskrivelse, som beskrevet i RFC 5234

Gruppering av linjer og regler

Én eller flere user-agent linjer som følges av en eller flere regler. Gruppen avsluttes av en user-agent linje eller slutten av filen. Den siste gruppen har kanskje ingen regler, noe som betyr at den implisitt tillater alt.

Eksempelgrupper:

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

Det er fire forskjellige grupper spesifisert :

  • En gruppe for «a»
  • En gruppe for «b»
  • En gruppe for både «e» og «f»
  • En gruppe for «h»

Med unntak av den siste gruppen (gruppe «h»), har hver gruppe sin egen gruppemedlemslinje. Den siste gruppen (gruppe «h») er tom.Legg merke til valgfri bruk av mellomrom og tomme linjer for å forbedre lesbarheten.

Prioritetsrekkefølgen for brukeragenter

Bare en gruppe er gyldig for en bestemt søkerobot. Søkeroboten må bestemme den riktige gruppen av linjer ved å finne gruppen med den mest spesifikke brukeragenten som fremdeles samsvarer. Alle andre grupper ignoreres av robotsøkeprogrammet. Brukeragenten er mellom store og små bokstaver. All tekst som ikke samsvarer, ignoreres (for eksempel googlebot/1.2 og googlebot* tilsvarer googlebot). Rekkefølgen til gruppene i robots.txt-filen er irrelevant.

Hvis det er erklært mer enn én gruppe for en spesifikk brukeragent, blir alle reglene fra gruppene som gjelder for den spesifikke brukeragenten, samlet i en enkelt gruppe.

Eksempler

Eksempel 1

Forutsatt følgende robots.txt-fil:

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

Dette er hvordan søkerobotene velger relevant gruppe:

Gruppe fulgt per crawler
Googlebot News Gruppen som følges er gruppe 1. Bare den mest spesifikke gruppen blir fulgt, alle andre blir ignorert.
Googlebot (web) Gruppen som følges er gruppe 3.
Googlebot Images Gruppen som følges er gruppe 3. Det er ingen spesifikk googlebot-images gruppe, så den mer generiske gruppen følges .
Googlebot News (når vi gjennomsøker bilder) > Gruppen som følges er gruppe 1. Disse bildene blir gjennomsøkt etter og av Googlebot News, derfor blir bare Googlebot News-gruppen fulgt.
Otherbot (web) Gruppen som følges er gruppe 2.
Otherbot (Nyheter) Gruppen som følges er gruppe 2. Selv om det er en oppføring for en relatert søkerobot, den er bare gyldig hvis den samsvarer spesifikt.

Eksempel 2

Forutsatt at følgende robots.txt-fil:

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

Dette er hvordan søkerobotene vil slå sammen grupper som er relevante for en bestemt brukeragent:

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

Se også Googles gjennomsøkere og brukeragentstrenger.

Gruppemedlemmeregler

Bare standard gruppemedlemsregler er dekket i denne delen. Disse reglene kalles også «direktiver» for crawlerne. Disse direktivene er spesifisert i form av directive: der er valgfritt. Som standard er det ingen begrensninger for gjennomsøking for de angitte gjennomsøkere. Direktiver uten ignoreres.

Verdien , hvis spesifisert, skal sees relativt fra roten til nettstedet som robots.txt-filen ble hentet for (ved hjelp av samme protokoll, portnummer, verts- og domenenavn). Baneverdien må starte med «/» for å betegne roten. Banen er mellom store og små bokstaver. Mer informasjon finner du i seksjonen «URL-samsvar basert på baneverdier» nedenfor.

avvis

Direktivet disallow spesifiserer baner som må ikke nås av de angitte crawlerne. Når ingen sti er spesifisert, ignoreres direktivet.

Bruk:

disallow: 

tillat

allow -direktivet spesifiserer baner som er angitt for de angitte søkerobotene. Når ingen sti er spesifisert, ignoreres direktivet.

Bruk:

allow: 

URL-samsvar basert på baneverdier

Baneverdien brukes som grunnlag for å avgjøre om en regel gjelder en spesifikk URL på et nettsted eller ikke. Med unntak av jokertegn brukes stien til å matche begynnelsen på en URL (og eventuelle gyldige URL-er som starter med samme bane). Ikke-7-biters ASCII-tegn i en bane kan inkluderes som UTF-8-tegn eller som prosent-rømte UTF-8-kodede tegn per RFC 3986.

Google, Bing og andre store søkemotorer støtter en begrenset form av «jokertegn» for baneverdier. Dette er:

  • * betegner 0 eller flere forekomster av et hvilket som helst gyldig tegn.
  • $ angir slutten av nettadressen.

Google-støttede ikke-gruppemedlemslinjer

Google, Bing og andre store søkemotorer støtter sitemap, som definert av sitemaps.org.

Bruk:

sitemap: 

peker på et områdekart, en indeksfil for et nettstedskart eller en tilsvarende nettadresse. URL-en trenger ikke å være på samme vert som robots.txt-filen. Flere sitemap oppføringer kan eksistere. Som ikke-gruppemedlemslinjer er disse ikke knyttet til noen spesifikke brukeragenter og kan følges av alle crawlere, forutsatt at det ikke er tillatt.

Forrangsrekkefølge for gruppemedlemmelinjer

På gruppemedlemnivå, spesielt for allow og disallow -direktivene, den mest spesifikke regelen basert på lengden på -oppføringen trumfer den mindre spesifikke (kortere) regelen. I tilfelle motstridende regler, inkludert de med jokertegn, brukes den minst restriktive regelen.

Testing av robots.txt-markering

Google tilbyr to alternativer for testing av robots.txt-markering:

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *