WordPress robots.txt in 2026: wat er echt in hoort

Een goede WordPress robots.txt is ongeveer vijf regels lang. Blokkeer /wp-admin/, sta admin-ajax.php toe, wijs crawlers naar je sitemap en stop daar. De uitdijende blokkeerlijsten van veertig regels die je op forums vindt, slopen meestal je weergave of doen helemaal niets. Het complete bestand:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://example.com/wp-sitemap.xml

Vervang het domein, en gebruik je een SEO-plugin die de sitemaps overneemt, laat de Sitemap-regel dan naar de index van die plugin wijzen. Meer is het niet. Is jouw bestand langer, dan kosten die extra regels je waarschijnlijk iets.

WordPress maakt er al een, tot je een echt bestand aanmaakt

WordPress levert een virtuele robots.txt. Komt er een verzoek binnen voor /robots.txt en staat er geen echt bestand in je webroot, dan onderschept WordPress het verzoek en drukt het een antwoord af in het geheugen. Er wordt niets naar schijf geschreven. De standaarduitvoer is het wp-admin-blok hierboven, plus een Sitemap:-regel voor wp-sitemap.xml die core sinds WordPress 5.5 meegeeft.

Twee dingen veranderen die uitvoer. Staat er een vinkje bij Instellingen → Lezen → Zoekmachines ontmoedigen deze site te indexeren, dan vervangt WordPress het geheel door Disallow: /, wat alles blokkeert. Dat vinkje is verreweg de meest voorkomende oorzaak van een site die na een lancering uit de zoekresultaten verdwijnt. Daarnaast kunnen plugins en thema’s de virtuele uitvoer aanpassen via de robots_txt-filter; zo injecteren SEO-plugins hun eigen sitemapregels en directives.

Dan het deel dat mensen hun middag kost. Een fysiek robots.txt-bestand in je webroot overschrijft dit alles stilletjes. Je webserver vindt een echt bestand op schijf, serveert het, en WordPress laadt nooit. De virtuele generator draait niet. De robots_txt-filter komt niet aan bod. De robots.txt-editor van je SEO-plugin toont je misschien nog steeds een keurige interface met de juiste regels erin, en niets daarvan bereikt een crawler.

Waar de regels staan	Aanpasbaar in WordPress-beheer	Wint bij een live verzoek
Virtueel (geen bestand op schijf)	Ja, via de robots_txt-filter of een plugin	Alleen als er geen fysiek bestand bestaat
Fysiek bestand in de webroot	Alleen als de plugin naar schijf schrijft	Altijd

Dus voordat je iets gaat uitzoeken: open https://jouwsite.nl/robots.txt in een browser, verbind daarna via SFTP of de bestandsbeheerder van je host en kijk of er een echt robots.txt naast wp-config.php en .htaccess staat. Zo ja, dan is dat bestand jouw robots.txt. Bewerk het daar of verwijder het en laat WordPress het overnemen, maar kies één van de twee. Allebei tegelijk draaien is precies hoe sites eindigen met een verouderde sitemap-URL die niemand kan vinden.

Waarom /wp-admin/ geblokkeerd is maar admin-ajax.php niet

In /wp-admin/ zit het dashboard. Die URL’s zijn nutteloos in zoekresultaten en ze crawlen verbrandt crawlbudget aan pagina’s die doorsturen naar een inlogscherm. Die map blokkeren is onomstreden.

admin-ajax.php staat in diezelfde map maar is geen beheerpagina. Het is het eindpunt dat plugins en thema’s gebruiken voor AJAX-verzoeken aan de voorkant: meer-laden-knoppen, gefilterde productoverzichten, rekentools, formulieren. Kan een crawler het niet ophalen, dan ziet hij de content niet die deze functies laden, en rendert Google je pagina zoals een bezoeker hem zou zien met die functie kapot.

Of Google admin-ajax.php op jouw specifieke site echt moet ophalen, hangt ervan af of je voorkant het gebruikt. Eerlijk antwoord: op veel moderne sites maakt het geen enkel verschil, omdat het thema in plaats daarvan de REST API op /wp-json/ gebruikt. De Allow-regel is een goedkope verzekering tegen een reëel faalscenario, geen rankingfactor. Laat hem staan, want hij kost niets.

Blokkeer /wp-content/ of /wp-includes/ niet

Dit is het slechtste robots.txt-advies dat nog steeds rondgaat, en het stamt uit een tijd waarin Google pagina’s nog niet renderde.

In /wp-content/ zitten je thema’s, plugins en uploads: de stylesheets, scripts en afbeeldingen die van je pagina’s pagina’s maken. In /wp-includes/ zit core-JavaScript waar plugins van afhankelijk zijn. Google rendert je pagina’s met een headless browser voordat het ze beoordeelt. Blokkeer je die mappen, dan krijgt de renderer een pagina zonder CSS en zonder afbeeldingen. Wat Google beoordeelt is een ongestileerde muur van tekst met een kapotte layout, en dat beïnvloedt zowel hoe het je content begrijpt als hoe het je mobiele bruikbaarheid scoort.

Heb je een bestand met deze regels geërfd, gooi ze eruit:

Disallow: /wp-content/
Disallow: /wp-includes/
Disallow: /wp-content/plugins/
Disallow: /wp-content/themes/

Je kunt de schade zelf bevestigen in de URL-inspectietool van Google Search Console. Voer een live test uit op een willekeurige pagina, bekijk de gerenderde schermafbeelding en controleer de lijst met paginabronnen op geblokkeerde items. Staat je CSS als geblokkeerd, dan heb je de oorzaak te pakken.

De Sitemap-regel

Eén regel, absolute URL, en hij mag overal in het bestand staan: hij hangt niet aan een User-agent-groep.

Sitemap: https://example.com/wp-sitemap.xml

Gebruik de URL die daadwerkelijk werkt. WordPress core serveert wp-sitemap.xml. De meeste SEO-plugins schakelen de core-sitemaps uit en serveren hun eigen index op een ander pad, meestal sitemap_index.xml. Laad je URL in een browser voordat je hem vastlegt: een Sitemap-regel die naar een 404 wijst is erger dan geen regel, omdat hij in een audit correct oogt.

Meerdere sitemaps opsommen mag, één per regel. Sitemaps indienen in Search Console blijft apart de moeite waard; de robots.txt-regel is hoe crawlers die je Search Console-account nooit zien ze alsnog vinden.

robots.txt is geen noindex, en geen beveiliging

Deze twee misverstanden veroorzaken de meeste robots.txt-schade.

Een URL blokkeren haalt hem niet uit Google. Robots.txt gaat over crawlen. Linkt een andere site naar een geblokkeerde URL, dan kan Google de URL zelf indexeren en krijg je een resultaat met alleen het kale adres en de melding dat er geen informatie beschikbaar is. En er zit een venijniger val in: heeft een pagina al een noindex-metatag en blokkeer je hem daarna in robots.txt, dan kan Google hem niet crawlen, ziet het de noindex niet, en kan de pagina onbeperkt geïndexeerd blijven. Wil je een pagina verwijderen, sta het crawlen dan toe en serveer een noindex meta robots-tag in de paginakop of een X-Robots-Tag-HTTP-header. Google ondersteunt noindex-regels binnen robots.txt sinds 2019 niet meer.

Een pad blokkeren beschermt het niet. Je robots.txt is per definitie openbaar. /private-client-files/ erin zetten vertelt elke bezoeker en elke scanner precies waar ze moeten kijken, en naleving is vrijwillig: Google respecteert het, vijandige bots niet. Alles wat bescherming nodig heeft, heeft authenticatie, een IP-beperking of serverregels in .htaccess nodig, en niet een regel in een tekstbestand dat het doelwit aanwijst.

Regels die het waard zijn, en regels om over te slaan

Twee toevoegingen zijn op veel sites echt nuttig. Een pad met zoekresultaten blokkeren voorkomt dat crawlers eindeloze waardeloze URL’s genereren uit je interne zoekfunctie. Een winkelwagen- of afrekenpad blokkeren bij WooCommerce houdt URL’s met sessieparameters buiten de crawl.

Disallow: /?s=
Disallow: /search/

Deze kun je overslaan:

• Crawl-delay — Google negeert het volledig. Gebruik de crawlsnelheidsinstellingen in Search Console als je een echt probleem met serverbelasting hebt.
• /feed/ of /trackback/ blokkeren — onschuldige URL’s, en feeds zijn nuttig.
• Lange lijsten met individuele botnamen — de meeste bots die mensen willen blokkeren maken zich toch niet eerlijk bekend.
• /wp-json/ blokkeren — het kan precies zijn wat je thema gebruikt om content weer te geven.

Bouw het bestand met de WordPress robots.txt-generator, die de minimale correcte versie oplevert en je de zoek- en webshopregels laat toevoegen zonder de syntaxis met de hand te schrijven.

Nadat je het hebt aangepast

Laad https://jouwsite.nl/robots.txt rechtstreeks en bevestig dat de geserveerde bytes zijn wat je verwacht, en niet wat de editor van je plugin je toont. Voer daarna een live URL-inspectie uit in Search Console op een gewone pagina en controleer of er geen CSS- of JavaScript-bronnen als geblokkeerd terugkomen. Google bewaart robots.txt ongeveer een dag in de cache, dus een correctie werkt niet meteen door en een fout ook niet. Juist die vertraging is de reden om zorgvuldig te controleren in plaats van in productie te testen en af te wachten.