Hoe u robots.txt controleert op geblokkeerde pagina's
Open https://uwdomein.com/robots.txt in een browser: wat daar wordt geserveerd, is uw robots.txt, en dat bepaalt wat crawlers mogen ophalen. Het bepaalt niet wat wordt geïndexeerd, en dat is het belangrijkste dat u over het bestand moet begrijpen voordat u het bewerkt.
Waar robots.txt moet staan
Het moet in de root van de host staan, als /robots.txt, in gewone UTF-8-tekst. Het geldt voor precies één combinatie van schema, host en poort, dus https://example.com/robots.txt regelt niets op https://shop.example.com en niets op de http-versie van dezelfde host. Elke subdomein die u wilt regelen, heeft zijn eigen bestand nodig.
De statuscode die het bestand teruggeeft, doet er net zoveel toe als de inhoud. Een 404 wordt gelezen als "geen beperkingen, alles crawlen", wat een volkomen geldige status is. Een herhaalde 5xx wordt gelezen als een tijdelijke storing, en Google kan het crawlen van de host pauzeren in plaats van aan te nemen dat het door mag gaan. Een 403 gedraagt zich voor dit doel als een serverfout. Is robots.txt onbetrouwbaar, dan wordt crawlen dat ook.
De syntax, in vijf regels
User-agent: *
Disallow: /admin/
Allow: /admin/public-page.html
Disallow: /*?sessionid=
Sitemap: https://example.com/sitemap.xmlUser-agent opent een groep. Disallow blokkeert een padvoorvoegsel, Allow snijdt een uitzondering uit een blokkade, * matcht elke reeks tekens en $ verankert het einde van een URL. Sitemap staat los van elke groep en neemt een absolute URL. Het formaat is gestandaardiseerd als RFC 9309, dus het hier beschreven gedrag is niet leverancierspecifiek.
Twee resolutieregels bepalen wat er werkelijk gebeurt. Een crawler gebruikt alleen de specifiekste groep die hem noemt, en negeert de *-groep helemaal zodra een groep hem rechtstreeks noemt. Binnen die groep wint de langste overeenkomende regel, en bij gelijkspel wint Allow.
De fouten die een hele site blokkeren
Disallow: /overgebleven van een staging-deployment. Eén teken, de hele site geblokkeerd. Het glipt er precies zo doorheen als een staging-noindex: een configuratiebestand dat met een release wordt meegepromoveerd.- CSS en JavaScript blokkeren. Google rendert pagina's, dus een geblokkeerde assetmap kan een pagina er voor de crawler kapot laten uitzien terwijl die er voor u prima uitziet.
- Verwachten dat robots.txt een pagina uit zoekresultaten haalt. Dat kan niet. Een geblokkeerde URL kan nog steeds worden vermeld via externe links, meestal zonder snippet, en omdat de crawler hem niet kan ophalen, wordt een noindex op die pagina nooit gezien. Om een pagina te verwijderen, staat u de crawl toe en serveert u noindex.
noindex:gebruiken als een instructie binnen robots.txt. Dat was nooit onderdeel van de standaard, en Google is er op 1 september 2019 mee gestopt dit te honoreren. Het wordt tegenwoordig stilzwijgend genegeerd.- Een groep toevoegen voor een met naam genoemde bot en verwachten dat de wildcardregels nog steeds gelden. Dat gebeurt niet. Zodra
User-agent: Googlebotbestaat, leest Googlebot die groep en niets anders, dus elke gedeelde regel moet daarin worden herhaald. - Een lege regel binnen een groep. Een lege regel beëindigt de groep, dus de regels erna horen bij niets tot de volgende
User-agent-regel. - Privépaden vermelden. Het bestand is openbaar.
/internal-admin/erin noemen publiceert de locatie van precies het ding dat u probeert te verbergen.
Hoe u een enkel pad test
Haal het bestand op en lees eerst de groep die op u van toepassing is:
curl -s https://example.com/robots.txtPas dan de langste-overeenkomst-regel handmatig toe op het betreffende pad. Met Disallow: /blog/ en Allow: /blog/public/ is de URL /blog/public/post toegestaan, omdat de bijpassende Allow-regel langer is. Voor een eigendom dat u bezit, toont het robots.txt-rapport in Search Console het opgehaalde bestand, wanneer het voor het laatst is opgehaald en eventuele parsefouten, wat de snelste manier is om te bevestigen dat de crawler leest wat u denkt dat hij leest.
Bevestig dat het overal bereikbaar is
Een robots.txt die vanaf uw eigen bureau laadt, kan nog steeds falen voor een crawler. Bot-beschermingsregels, rate limits en geografische blokkades geven routinematig 403 terug aan adresbereiken van datacenters terwijl ze gewone bezoekers thuis normaal bedienen, en het resultaat is een host waarvan Google het crawlen vertraagt of stopt om redenen die niets in uw logs een fout noemt.
De manier om het te zien, is het bestand ergens vandaan op te vragen dat niet uw kantoor is. Richt de gratis HTTP-controletool op https://example.com/robots.txt en lees de statuscode die wordt teruggegeven vanaf controlepunten in verschillende landen. Een 200 overal is het gezonde antwoord; een 200 thuis en een 403 vanuit drie regio's is de bevinding. Om te testen of de regels een specifieke pagina blokkeren, toetst de gratis robots.txt-tester een URL tegen de groep voor alle crawlers en meldt of die in de sitemap staat vermeld. Robots.txt staat los van de pagina, dus de optie Indexability op een HTTP-monitor van HostTracker leest het niet: die houdt de noindex- en canonical-tags op de pagina zelf in de gaten, terwijl de geplande crawl, in bèta, elke gecrawlde pagina kruislings toetst aan robots.txt. SEO-monitoring legt uit welke van de twee wat dekt.