Robots.txt zonder ongelukken: wat je wel en niet blokkeert

Robots.txt is een tekstbestand in de root van je domein dat crawlers vertelt welke delen van je site ze niet mogen bezoeken. Het regelt crawlen, niet indexeren. Dat is de belangrijkste zin van dit artikel, want bijna elk robots.txt-ongeluk dat ik tegenkom komt voort uit het verwarren van die twee.

De vuistregel voor SEO: blokkeer zo weinig mogelijk. Gebruik robots.txt om crawlers weg te houden van eindeloze, waardeloze URL-ruimtes. Gebruik het nooit om pagina’s uit Google te houden.

Wat robots.txt wel en niet doet

Een crawler die je site bezoekt, vraagt eerst /robots.txt op. Staat een pad daar onder Disallow, dan haalt een nette crawler die URL niet op. Dat is alles.

Wat het niet doet:

• Het verwijdert niets uit de index. Een geblokkeerde URL kan nog steeds in Google verschijnen, bijvoorbeeld als er links naar wijzen. Je ziet dan een resultaat zonder beschrijving.
• Het beveiligt niets. Robots.txt is openbaar. Iedereen kan lezen welke paden je liever verborgen houdt. Een admin-pad erin zetten is een wegwijzer, geen slot.
• Het verbergt geen noindex. Blokkeer je een pagina met een noindex-tag, dan kan Google die tag nooit lezen. De pagina blijft dus juist langer in de index hangen.

Wil je een pagina echt uit de zoekresultaten, gebruik dan een noindex in de meta robots of de X-Robots-Tag header, en laat de pagina crawlbaar.

De opbouw in vijf regels

Een robots.txt bestaat uit groepen. Elke groep begint met een User-agent en bevat regels.

User-agent: *
Disallow: /winkelwagen/
Disallow: /*?sessionid=
Allow: /wp-admin/admin-ajax.php

Sitemap: https://www.voorbeeld.nl/sitemap.xml

Drie dingen om te weten:

1. De meest specifieke regel wint. Google kijkt naar de langste overeenkomende regel. Daarom kan een Allow binnen een geblokkeerde map een uitzondering maken.
2. Wildcards werken. * staat voor elke reeks tekens, $ voor het einde van de URL. Disallow: /*.pdf$ blokkeert alle pdf’s.
3. Hoofdlettergevoelig. /Blog/ en /blog/ zijn voor robots.txt twee verschillende paden.

Wat ik wel blokkeer

Robots.txt is een instrument voor crawlefficiëntie. Het loont vooral bij sites met veel gegenereerde URL’s, zoals webshops en grote contentsites. Hoe dat budget werkt, lees je in crawlbudget: wanneer het ertoe doet.

Kandidaten om te blokkeren:

Type URL	Waarom blokkeren	Voorbeeldregel
Interne zoekresultaten	Oneindige variaties, geen unieke waarde	Disallow: /zoeken
Filtercombinaties	Explosie aan bijna-duplicaten	Disallow: /*?*kleur=*&maat=
Winkelwagen en checkout	Geen zoekwaarde, alleen ruis	Disallow: /winkelwagen/
Sessie- en trackingparameters	Duplicaten van dezelfde pagina	Disallow: /*?sessionid=
Staging- of testpaden op productie	Mogen nooit in de index	Beter: wachtwoord erop

Bij filters is nuance nodig. Sommige filterpagina’s hebben juist zoekvolume, zoals “zwarte sneakers maat 43”. Die wil je crawlbaar en indexeerbaar houden. Blokkeer de combinaties zonder vraag erachter, niet het hele filtermechanisme.

Wat je nooit blokkeert

Hier gaan de echte ongelukken.

CSS en JavaScript. Google rendert je pagina’s. Blokkeer je de bestanden die nodig zijn om een pagina op te bouwen, dan ziet Google een kapotte versie. Oudere WordPress-setups met Disallow: /wp-includes/ doen dit nog steeds.

Pagina’s met een noindex of canonical. Google moet de pagina kunnen ophalen om die signalen te lezen. Blokkeer je ze, dan negeert Google ze noodgedwongen.

Je hele site. Klinkt absurd, gebeurt maandelijks. Een staging-omgeving heeft Disallow: /, iemand zet de site live en neemt het bestand mee. Binnen dagen zakt je verkeer weg. Dit is een van de vaste punten op elke checklist bij een SEO-migratie zonder verkeersverlies.

Afbeeldingen die je wilt laten ranken. Blokkeer je /images/ of je CDN-pad, dan verdwijnen je afbeeldingen uit Google Afbeeldingen.

Robots.txt en AI-crawlers

Sinds AI-assistenten het web lezen, staat robots.txt opnieuw op de agenda. GPTBot, ClaudeBot, PerplexityBot en Google-Extended respecteren hun eigen user-agent regels.

Mijn standpunt: blokkeer ze niet zonder reden. Wie AI-crawlers buitensluit, sluit zichzelf ook uit van de antwoorden waarin je genoemd en geciteerd wilt worden. Voor de meeste dienstverleners en webshops is zichtbaarheid in AI-antwoorden waardevoller dan de theoretische bescherming van je content.

Uitzondering: uitgevers met betaalde content of een licentiemodel. Daar is het een zakelijke afweging, geen technische. Maak dan wel onderscheid tussen crawlers voor training en crawlers die live zoeken voor een antwoord. Die hebben bij sommige aanbieders aparte user-agents.

Zo test je zonder risico

Pas robots.txt nooit live aan zonder te testen. Mijn vaste route:

1. Haal de huidige versie op en bewaar een kopie. Terugdraaien moet binnen een minuut kunnen.
2. Test elke regel tegen echte URL’s. Neem tien belangrijke pagina’s (home, categorieën, toppagina’s uit Search Console) en controleer dat ze niet geraakt worden.
3. Crawl na publicatie. Screaming Frog respecteert robots.txt standaard en toont geblokkeerde URL’s apart. Zo zie je meteen of je meer raakt dan bedoeld. Hoe je die eerste crawl opzet, staat in Screaming Frog voor beginners.
4. Check Search Console. Het robots.txt-rapport onder Instellingen laat zien welke versie Google heeft opgehaald en of er fouten in zitten.
5. Volg het indexeringsrapport een paar weken. Een stijging van “Geblokkeerd door robots.txt” bij URL’s die je wel wilde, is je vroege waarschuwing.

Veelgemaakte fouten op een rij

• Noindex en robots.txt combineren op dezelfde URL
• Disallow: / meenemen vanaf staging
• Robots.txt gebruiken als beveiliging
• CSS, JS of afbeeldingen blokkeren
• Een regel schrijven met een slash te weinig, waardoor /blog ook /blogger-tips raakt
• Vergeten dat elk subdomein een eigen robots.txt heeft

Kort samengevat

Robots.txt stuurt crawlers, niet de index. Gebruik het om waardeloze URL-ruimtes af te sluiten en laat de rest open. Test elke wijziging, en behandel het bestand als productiecode: één verkeerde regel kost meer verkeer dan welke contentfout ook.

Twijfel je of jouw robots.txt, noindex-tags en canonicals elkaar niet in de weg zitten? Dat is precies het soort technische fundament dat ik meeneem wanneer bedrijven hun SEO uitbesteden.