SEO
Robots.txt-valkuilen bij headless en JAMstack-sites
De meest gemaakte robots.txt-configuratiefouten op JAMstack- en headless-sites, en de juiste patronen om in plaats daarvan te gebruiken.
Robots.txt is bij een traditioneel CMS meestal eenvoudig. Bij een JAMstack- of headless-opzet leveren teams er juist regelmatig subtiele fouten mee op, omdat het buildproces het bestand zo genereert dat je nauwelijks nog ziet wat erin staat. Dit artikel gaat over de specifieke robots.txt-valkuilen bij statische en headless deployments, met de juiste patronen per framework.
Het patroon ‘staging per ongeluk geïndexeerd’
De meest voorkomende en schadelijkste fout: dezelfde codebase wordt uitgerold naar staging en productie. De robots.txt-logica hangt af van een omgevingsvariabele die tijdens de productiebuild niet is ingesteld, waardoor productie per ongeluk een User-agent: * Disallow: / uit de staging-standaardwaarden meekrijgt. Binnen een paar dagen is de hele productiesite uit de index verdwenen. De oplossing: laat de productiebuild de productie-robots.txt expliciet instellen en laat de build mislukken als de variabele ontbreekt.
Next.js: de public-map versus de API-route
Next.js ondersteunt robots.txt als statisch bestand in /public/robots.txt of als dynamische API-route op /pages/api/robots.txt (of app/robots.txt). Als je beide mengt, ontstaat er een race bij het bepalen welk bestand wordt geserveerd, afhankelijk van de Next.js-versie. Kies één aanpak en hou je eraan. Voor de meeste sites is het statische bestand eenvoudiger en betrouwbaar.
Nuxt: de module versus het gegenereerde bestand
Nuxt heeft een robots-module die robots.txt tijdens de build genereert. Om die goed te configureren moet je weten in welke omgeving de build draait. De veelgemaakte fout: robots wordt geconfigureerd in ontwikkeling maar niet in productie, waardoor de robots.txt van ontwikkeling op productie terechtkomt.
Headless WordPress: wie serveert wat
Bij headless WordPress heeft de API-backend een eigen robots.txt en de frontend ook. Beide zijn bereikbaar. Zorg dat de API-backend alles blokkeert (je wilt niet dat het GraphQL-endpoint wordt geïndexeerd) en dat de frontend de echte productie-robots.txt serveert. De standaard-robots.txt van WordPress is voor een headless-opzet vrijwel zeker niet wat je wilt.
Robots.txt per omgeving
Het patroon dat over frameworks heen betrouwbaar werkt, is een robots.txt-bestand per omgeving in de repo, waarbij het buildproces aan de hand van een expliciete omgevingsvlag kiest welk bestand wordt uitgerold. Namen als robots.production.txt, robots.staging.txt en robots.preview.txt maken de bedoeling duidelijk. Vermijd slimme generatie tijdens runtime als een statisch bestand per omgeving volstaat.
Sitemapverwijzingen
Robots.txt moet je sitemap met een absolute URL aanwijzen. Veel robots.txt-bestanden verwijzen relatief naar /sitemap.xml. Google kan dat aan, maar het is kwetsbaarder. Gebruik de volledige URL inclusief protocol en domein, en controleer in een browser of die laadt voordat je commit.
Regels per user-agent
De meeste sites hebben geen regels per user-agent nodig. De verleiding om specifieke bots als AhrefsBot of SemrushBot te blokkeren is echt, maar levert zelden iets op: de bots houden zich aan robots.txt, en blokkeren verraadt vooral aan je concurrenten welke tools je gebruikt. Blijf voor bijna alles bij User-agent: *, tenzij er een concrete reden is om onderscheid te maken.
Crawl-delay en andere verouderde directives
Google negeert Crawl-delay. Bing houdt er deels rekening mee. De meeste andere bots negeren het. Heb je last van serverbelasting, dan zit de oplossing niet in robots.txt maar in rate limiting of het opschalen van de server. Haal crawl-delay-regels uit elke robots.txt die ze bevat: ze wekken de valse indruk dat je iets nuttigs hebt ingesteld.
Allow vóór Disallow bij conflicterende paden
Standaard wint de langere regel. Met Disallow: /api/ en Allow: /api/public/ wint de Allow voor /api/public/ en de Disallow overal elders onder /api/. Test specifieke paden in de robots.txt-tester van Google voordat je aanneemt dat een ingewikkelde set regels werkt.
Validatie in CI
De betrouwbaarste bescherming tegen robots.txt-fouten is een CI-controle die de build laat mislukken als robots.txt niet overeenkomt met het verwachte productiepatroon. Twintig regels testcode voorkomen de hele categorie deploymentfouten. De meeste teams hebben deze controle niet, maar ze zouden hem wel moeten hebben.
Het auditritme
Robots.txt hoort ongeacht het framework op elke kwartaalchecklist voor audits, omdat wijzigingen ongemerkt worden doorgevoerd. Een tool voor continue audits die wijzigingen in robots.txt meldt, vangt problemen op binnen enkele uren na de deploy in plaats van weken later.
Bij JAMstack- en headless-sites is robots.txt een van de riskantste bestanden in de build, omdat één gewijzigd teken een hele site vanuit Google gezien offline kan halen. Investeren in expliciete, omgevingsbewuste configuratie en CI-validatie verdient zich de eerste keer dat het een bijna-ongeluk opvangt direct terug. UtilitySEO en vergelijkbare audittools volgen wijzigingen in robots.txt in de tijd, precies de juiste vorm van monitoring voor een bestand dat zelden zou moeten veranderen en dan drastisch.
Veelgestelde vragen
Productiesites worden vaak gedeïndexeerd door robots.txt-valkuilen wanneer staging-configuraties per ongeluk worden uitgerold, met een Disallow: /-regel die crawlers van zoekmachines blokkeert.
- Dit gebeurt als de omgevingsvariabelen voor robots.txt tijdens productiebuilds niet goed zijn ingesteld.
- Zorg dat je productiebuild expliciet het juiste productie-robots.txt-bestand gebruikt.
- Bouw buildcontroles in die mislukken als de benodigde omgevingsvariabelen ontbreken.
Bij de meeste Next.js-projecten kom je robots.txt-valkuilen het eenvoudigst en betrouwbaarst te boven met een statisch bestand in de map /public/robots.txt.
- Next.js ondersteunt voor robots.txt zowel statische bestanden als dynamische API-routes.
- Meng beide aanpakken niet, want dat kan leiden tot conflicten bij het bepalen van het bestand, afhankelijk van de Next.js-versie.
- De aanpak met een statisch bestand is meestal voorspelbaarder en makkelijker te beheren.
Bij een headless WordPress-opzet hebben zowel de API-backend als de frontend een eigen robots.txt, en het goed aanpakken van deze robots.txt-valkuilen is cruciaal.
- Zorg dat de robots.txt van de API-backend alle crawling blokkeert, zodat API-endpoints niet worden geïndexeerd.
- De frontend moet de echte productie-robots.txt voor je publieke site serveren.
- Vertrouw voor je headless frontend niet op de standaard-robots.txt van WordPress.
De betrouwbaarste strategie tegen veelvoorkomende robots.txt-valkuilen is een robots.txt-bestand per omgeving, direct in je repository.
- Geef bestanden duidelijke namen, zoals robots.production.txt of robots.staging.txt, zodat hun doel duidelijk is.
- Configureer je buildproces zo dat het aan de hand van een omgevingsvlag expliciet het juiste bestand kiest en uitrolt.
- Deze aanpak is over het algemeen robuuster dan slimme generatielogica tijdens runtime.
Om robots.txt-valkuilen rond het vinden van je sitemap te voorkomen, verwijs je altijd met een absolute URL naar je sitemap, inclusief protocol en domein.
- Google kan wel met relatieve paden overweg, maar een absolute URL is robuuster en minder foutgevoelig.
- Gebruik bijvoorbeeld Sitemap: https://www.example.com/sitemap.xml in plaats van /sitemap.xml.
- Controleer vóór de deployment altijd of de absolute sitemap-URL in een browser goed laadt.
Weet wat je nu moet oplossen.
Scan je website voor een duidelijker beginpunt.
Ongeveer 30 seconden. Geen creditcard nodig.