Robots.txt en Googlebot - wat is het en hoe voorkom je fouten?

Inhoudsopgave

• Wat is robots.txt?
• Een beetje geschiedenis
• Welke robots lezen het robots.txt bestand?
• Waarom een robots.txt bestand gebruiken?
• Basisrichtlijnen in robots.txt: user-agent, allow and disallow
• Sitemap richtlijn
• Clean-param richtlijn
• Host richtlijn
• Fouten in robots.txt en de gevolgen daarvan
• Moet u bij het maken van een robots.txt-bestand letten op de grootte ervan?
• Wat is er nog meer, naast het robots.txt bestand?
• Samenvatting

Wat is robots.txt?

Het bestand robots.txt wordt gebruikt om zoekmachine robots en crawlprogramma's te voorzien van informatie over wat ze wel en niet moeten doen op de pagina. Richtlijnen worden verzonden met behulp van de Robots Exclusion Protocol standaard, hoewel het moet worden opgemerkt dat sommige zoekmachines zich niet precies houden aan deze standaard. De basis bevat een commando waardoor delen van de pagina niet door robots gelezen moeten worden, hoewel er meer mogelijkheden zijn waarvoor je het robots.txt-bestand kan gebruiken.

Een beetje geschiedenis

Het Robots Exclusion Protocol is letterlijk een kwart eeuw geleden, in februari 1994, in het leven geroepen - en is sindsdien niet veel veranderd, met uitzondering van het bovengenoemde. Omdat er in de tijd van de "jeugd" veel zoekmachines op de markt waren (het is genoeg om AltaVista, HotBot, Lycos of InfoSeek te noemen - en de lijst was nog veel langer), werd het al snel de onofficiële standaard. Er moet hier echter worden vermeld dat de standaard ongewoon is omdat het echt een suggestie was en nog steeds is. Een suggestie die robots vaak niet, of slechts gedeeltelijk, respecteren.

Interessant is dat Google in juli 2019 - waarvan de bots ook niet altijd volledig voldoen aan de richtlijnen - heeft voorgesteld om het Robots Exclusion Protocol te beschouwen als een officiële standaard. Kan het op dit moment iets veranderen aan de manier waarop robots.txt wordt gebruikt? Theoretisch gezien niet. Het kan echter wel leiden tot discussies over de introductie van nieuwe items die kunnen helpen bij een efficiëntere "controle" van zoekmachinerobots.

Welke robots lezen het robots.txt bestand?

Het bestand robots.txt is bedoeld voor alle automatische systemen die op de site binnenkomen. Dit geldt, vanuit het oogpunt van SEO, niet alleen voor de meest voor de hand liggende zoekmachine robots. Bots waarop de richtlijnen van dit bestand gericht zijn, zijn ook automatische archiveringsmachines (zoals Web Archive), programma's die de site downloaden (bijvoorbeeld HTTrack Website Copier), website-analysetools (inclusief SEO-tools zoals Xenu, maar ook de Majestic SEO- en Ahrefs-bots).
Natuurlijk is het gemakkelijk te raden dat de makers zich in veel gevallen geen zorgen hoeven te maken over richtlijnen. Aan de andere kant laten sommige robots hun gebruikers kiezen of ze zich aan de gedetecteerde richtlijnen willen houden.

Waarom een robots.txt bestand gebruiken?

Dit is een fundamentele vraag die de moeite waard is om te stellen - vooral in de context van de informatie waarin meerdere malen is genoemd dat het de vermeldingen in het robots.txt-bestand respecteert. Het antwoord is eenvoudig: weinig controle over de robots is altijd beter dan het ontbreken ervan. En wat heeft u er aan? Ten eerste, het niet toestaan van programma's om te bladeren door die delen van de website die ze niet moeten bezoeken om verschillende redenen en het tonen van plaatsen waar bezoeken het meest aan te raden zijn.
Het blokkeren van specifieke delen van de pagina kan om verschillende redenen belangrijk zijn:
    -Veiligheid- Misschien wil je gewoon niet dat robots (of toevallige gebruikers die later door robots gekropen bronnen gebruiken) in staat zijn om bij secties te komen waar ze niet al te gemakkelijk toegang tot zouden moeten hebben.
    -Bescherming tegen dubbele content - als er een grote hoeveelheid intern gedupliceerde content op de pagina staat, en het URL-schema tegelijkertijd toelaat om duidelijk te worden geïdentificeerd. Met behulp van een robots.txt-bestand kunt u zoekmachines een signaal geven dat dit deel van de site niet moet worden gevolgd. U kunt hierbij denken aan een testversie van een site.
    -Besparende overdracht - met behulp van robots.txt-items kunt u proberen hele submappen of specifieke soorten bestanden te verwijderen, uit de paden die robots afleggen, - zelfs een map met afbeeldingen of grotere versies hiervan. Voor sommige websites kunnen de dataverkeer besparingen aanzienlijk zijn.
-Inhoudsbescherming tegen "lekken" naar buiten - Merk op dat de voorgestelde bovenstaande bescherming voor een map met groot formaat afbeeldingen ook kan worden gebruikt om alleen kleinere versies te presenteren in de zoekmachine voor afbeeldingen. Dit kan belangrijk zijn in het geval van fotobanken.
-Crawl budget optimalisatie - hoewel het als laatste in de lijst benoemd is, is het zeker geen onbeduidende zaak. Hoe groter de website, hoe meer de nadruk moet worden gelegd op het optimaliseren van de paden waarlangs de zoekmachine-indexeringsbots zich bewegen. Door het blokkeren van sites die niet relevant zijn voor SEO bij robots.txt, verhoogt u simpelweg de kans dat robots het juiste indexeren.

Basisrichtlijnen in robots.txt: user-agent, allow and disallow

Laten we vanaf het begin beginnen: hoe moet het robots.txt-bestand eruit zien. Het moet per definitie een tekstbestand zijn dat in de hoofddirectory van de website, waarop het betrekking heeft, wordt geplaatst. De belangrijkste, meest voorkomende richtlijnen zijn user-agent, allow en disallow. Met behulp van de eerste is het mogelijk om te bepalen aan welke bots een bepaalde regel is geadresseerd. De andere twee geven aan tot welke gebieden de robot toegang moet hebben en waar deze niet welkom is.
Het is de moeite waard om te onthouden dat het robots.txt bestand de variabele ondersteunt in de vorm van een sterretje (*) en de bestandspaden waarop het commando van toepassing is moeten altijd met alles worden gevuld, zelfs met een schuine streep (/). Doet u dit niet dan zal het genegeerd worden.
Een voorbeeld van een goede vulling kan het volgende zijn:
User-agent: * Allow: /
- dat wil zeggen, verklaring dat alle bots de hele site kunnen indexeren. Of:
User-agent: * Disallow: /afbeeldingen/
- betekent het ontzeggen van de toegang tot de /afbeeldingen/ map.
Maar:
User-agent: * Disallow:
- betekent niets, vanwege het ontbreken van een pad na de weigering van toegang.
Natuurlijk kunnen er in een robots.txt-bestand meer allow- en disallow voorkomen. Voorbeeld:
User-agent: * Allow: / Disallow: /afbeeldingen/ Disallow: /wp-admin/
- dat wil zeggen, toestemming voor de robots om de hele site te bezoeken, met uitzondering van de /afbeeldingen/ en /wp-admin/ mappen.

Hieraan moet worden toegevoegd dat de richtlijnen zelf niet alleen van toepassing kunnen zijn op hele mappen, maar ook op individuele bestanden.

De volgorde van toestaan en weigeren in robots.txt
Er kan een probleem zijn met de interpretatie van de toestemmings- en weigering, bijvoorbeeld als u robots de toegang tot een map wilt verbieden, maar een uitzondering wilt maken voor een specifieke submap, vergeet dan niet dat de toestemmingen boven het verbod moeten staan, bijvoorbeeld:
User-agent: * Allow: / Allow: /afbeeldingen/submap/ Disallow: /afbeeldingen/
User-agent: Ahrefsbot Disallow: /
User-agent: MJ12bot Disallow: /
In het bovenstaande voorbeeld ziet u het geval wanneer er aparte regels worden gebruikt voor sommige bots - op deze manier "vraag" je de robots van Ahrefs en Majestic SEO om deze pagina uit te sluiten.

Sitemap richtlijn

Naast "uitnodigingen" en suggesties voor het overslaan van mappen, kan het bestand robots.txt ook gebruikt worden om robots de locatie van de sitemap te laten zien. Hiervoor wordt de sitemap-richtlijn gebruikt, gevolgd door het volledige pad van het bestand. Een voorbeeld van het bovenstaande ziet er als volgt uit:
Sitemap: https://www.domain.com/sitemap.xml
Natuurlijk kunt u meer Sitemaps aangeven, die nuttig kunnen zijn voor zeer complexe websites.
Richtlijn inzake Crawling
Voor zeer grote websites ontstaat vaak een dilemma - aan de ene kant willen hun eigenaren de hele site laten indexeren, aan de andere kant kan overmatige activiteit van de zoekmachinebots nogal wat dataverkeer verbruiken en de server voortdurend belasten. Het idee om dit probleem op te lossen is om het gebruik van de aangepaste crawl-delay richtlijn in te voeren.
Het wordt gebruikt om robots te informeren dat ze niet vaker dan elke x seconde nieuwe urls moeten bezoeken, wat zich vertaalt in het uitrekken van de tijd die de robot neemt.
User-agent: * Crawl-delay: 2
Dit wil dus zeggen, het crawlen van volgende urls, om de twee seconden.
Het is de moeite waard om te onthouden dat de meeste zoekmachines dit niet precies hanteren, maar vaak gewoon negeren. Google heeft enige tijd de irrelevantie van deze richtlijn gecommuniceerd, en heeft tot slot in juli 2019 officieel aangekondigd dat zij deze richtlijn niet zal steunen. Bing verklaart dat het record door BingBot wordt gelezen, de waarde ervan zou tussen 1 en 30 moeten liggen. De richtlijn wordt ook theoretisch gesteund door Yandex, hoewel het in de praktijk anders is.
Interessant is dat de Tsjechische zoekmachine Seznam voorstelt om een andere richtlijn te gebruiken, namelijk de vraagprijs en het toekennen van een waarde door het aantal documenten, een schuine streep en de tijd in de vorm van aantal en eenheid (s als seconden, m als minuten, heeft uren en dagen, telkens zonder spaties na het nummer) te geven. Een voorbeeld hiervan kan zijn
User-agent: SeznamBot Request-rate: 500/1h
of:
User-agent: SeznamBot Request-rate: 100/20m

Seznam verklaart dat de richtlijn niet mag verplichten tot een tragere indexering dan één url per 10 seconden.

Clean-param richtlijn

Clean-param is een zeer interessante richtlijn. Helaas is het een algemene norm. Deze richtlijn wordt gelezen door de Yandex-zoekmachinebots en maakt het mogelijk om specifieke parameters die zijn toegewezen aan adressen in gespecificeerde paden te negeren.
Hoe werkt het in de praktijk? Laten we aannemen dat er adressen zijn binnen uw pagina:
domain.com/catalogus/pagina?background=1&id=3 domain.com/catalogus/pagina?background=2&id=3 domain.com/catalogus/pagina?background=3&id=3
Wat gebeurt er als de variabele (achtergrond) alleen het uiterlijk van een pagina met steeds dezelfde inhoud wijzigt? In dergelijke gevallen stelt Yandex voor om de parameter clean-param te gebruiken. Het juiste record kan er als volgt uitzien:
Gebruikersagent: Yandex Clean-param: background/catalogus/
- dit betekent dat alle drie de adressen in het vorige voorbeeld worden gelezen als:
domain.com/catalogus/pagina?id=3
Zoals u ziet, is deze richtlijn handiger omdat u deze kan beperken tot specifieke mappen.

Host richtlijn

De aangepaste robots.txt richtlijn vermeldt ook het host commando. Dit werd door de meeste zoekmachines genegeerd en werd al enige tijd vermeld op de Yandex-hulppagina's, maar nu is de beschrijving ervan verdwenen.
Het hostcommando wordt gebruikt als (of misschien diende het als) een indicatie van het gewenste domein, wanneer u meerdere (mirror) servers op verschillende adressen heeft. Wat belangrijk is, is dat er hooguit één hostrichtlijn in één robots.txt-bestand zit (als er meer worden geplaatst, worden de volgende genegeerd), en dat de invoer van het domein na het hostcommando geen fouten of poortnummers kan bevatten.

Voorbeeld:
Host: domain.com
Helaas is niet duidelijk of het commando nog werkt, maar er kan wel vanuit worden gegaan dat het alleen maar heeft geleid tot diverse experimenten. Als troost voor "gewone webmasters" moet worden vermeld dat Yandex, bij het noemen van de richtlijn op zijn pagina's, presenteerde als een "suggestie" voor robots - dus het werd niet als verplicht behandeld.

Fouten in robots.txt en de gevolgen daarvan

Hoewel de inhoud van het robots.txt-bestand kan worden gebruikt om samen te werken met zoekmachinerobots, kan het net zo goed leiden tot het falen van uw site. Hoe? Door uw website inhoud uit te sluiten van de resultaten die in de index zou moeten verschijnen. Het effect kan een aanzienlijk verlies van zichtbaarheid in de zoekresultaten zijn. Vooral in het geval van uitgebreide robots.txt-bestanden met veel invoer in verschillende submappen, is het gemakkelijk om ergens onderweg een fout te maken en te veel secties van de pagina uit te sluiten.
De tweede grote fout is om alle afbeeldingen, CSS-stijlen en Java Script-bestanden te ontsluiten met de "disallow"-richtlijn. Het lijkt misschien een goede zet, maar de realiteit is iets anders, en dat om twee redenen. Ten eerste is het in veel gevallen een goed idee als uw pagina wordt gevonden in de zoekresultaten van de afbeeldingen (hoewel u natuurlijk de toegang tot bijvoorbeeld de ''grote formaat'' versies kunt verbieden, wat al eerder benoemd is).
De tweede reden is echter belangrijker, en dat is de weergave van de site door Google Bot. Als u de bot niet toestaat om toegang te krijgen tot bestanden die belangrijk zijn voor het uiteindelijke uiterlijk van de pagina, zal deze zonder deze bestanden worden weergegeven, waardoor de pagina in sommige gevallen onvolledig kan zijn - en dit kan van invloed zijn op de ranking.

Moet u bij het maken van een robots.txt-bestand letten op de grootte ervan?

Een Googler, John Mueller, verklaarde ooit op zijn Google+ profiel dat de maximale grootte van een robots.txt bestand 500 KB is. Men kan dus concluderen dat het probleem abstract is, omdat een dergelijke uitbreiding van de lijst met richtlijnen absurd zou zijn. Het is echter de moeite waard om ervoor te zorgen dat zelfs een kort robots.txt bestand niet overmatig groeit en gewoon leesbaar blijft voor iemand die er naar zal moeten kijken en het eventueel zal moeten aanvullen of aanpassen.
Daarnaast moet u er ook rekening mee houden dat het hier alleen gaat om de geaccepteerde waarde van de Google Bot - voor andere zoekmachines kan de bestandsgrootte van robots.txt variëren.
Is het blokkeren van paginas's in robots.txt voldoende?
Helaas niet. Ten eerste respecteren de belangrijkste zoekmachinerobots de verboden pagina's niet altijd (om nog maar te zwijgen van de manier waarop sommige tools ze benaderen). Ten tweede kan Google, zelfs na het lezen van het verbod, de pagina bekijken en toevoegen aan de index met alleen de titel en het URL-adres, en soms de volgende verklaring toevoegen: "Voor deze pagina is informatie niet beschikbaar".
Het is dus nog steeds mogelijk om deze pagina te bereiken vanaf het niveau van de zoekmachine, hoewel dit onwaarschijnlijk is. Bovendien gaan bots nog steeds door dergelijke pagina's heen, ook al geven ze geen linkjuice meer, en bevat het resultaat in de zoekmachine geen gegevens over de precieze inhoud.

Wat is er nog meer, naast het robots.txt bestand?

Als u bepaalde delen van de pagina wilt uitsluiten van de indexeren van de zoekmachines, kunt u altijd nog de meta-tag van de robots gebruiken die in de <HEAD>-sectie van de afzonderlijke subpagina's is geplaatst:
<meta name="robots" inhoud="noindex, nofollow" />
- Dit is nog steeds geen methode die 100% succes garandeert (en bovendien minder handig is), maar het is wel een extra signaal voor bots.
Maar wat als je de toegang tot bots en willekeurige mensen volledig wilt blokkeren? In deze situatie, in plaats van het gebruiken van passieve methoden, is het veel beter om gewoon het gegeven gedeelte van de website te blokkeren met een wachtwoord (bijvoorbeeld door middel van htaccess).
Theoretisch kunt u ook andere maatregelen nemen, bijvoorbeeld in de vorm van het blokkeren van de toegang voor oproepen van specifieke adressen en IP-klassen (die worden gebruikt door zoekmachinebots), maar in de praktijk zou u enkele adressen missen en zou het probleem nog steeds bestaan. Dit leidt ons weer tot de conclusie dat het forceren, van bijvoorbeeld een wachtwoord, voor volledige veiligheid zal zorgen.

Samenvatting

Tot slot kunnen we terugkomen op de kwestie van de gevolgen van mogelijke fouten in het robots.txt-bestand. Wat er ook ingetypt wordt, het is de moeite waard om te onthouden wat de effecten kunnen zijn en wat het doet. Als u iets wilt indexeren, let er dan op of dit tot bijwerkingen leidt (zie een voorbeeld met de moeilijkheid om de pagina door Google Bot te renderen). Wanneer u zich op uw beurt zorgen maakt over beveiligingsproblemen, bedenk dan dat Google's uitsluiting van indexering nog steeds de toegang tot automatische scraping niet blokkeert.