Robots.txt uitgelegd: wat is het en hoe gebruik je het voor SEO?
Een robots.txt-bestand is klein, maar kan een grote invloed hebben op hoe zoekmachines je website bezoeken. Met enkele regels geef je crawlers instructies over welke delen van je website ze mogen bekijken en welke ze beter overslaan.
Dat klinkt eenvoudig, maar robots.txt wordt regelmatig verkeerd begrepen. Zo denken veel website-eigenaren dat je met dit bestand pagina’s uit Google kunt verwijderen. Of dat een geblokkeerde map automatisch beschermd is tegen ongewenste bezoekers. Geen van beide klopt.
Wat doet robots.txt dan wel? Wanneer is het nuttig voor SEO? En hoe zit het tegenwoordig met AI-crawlers zoals GPTBot? We leggen uit hoe het werkt, welke instellingen belangrijk zijn en welke fouten je beter vermijdt.
Wat is robots.txt?
Robots.txt is een tekstbestand dat instructies bevat voor automatische programma’s die websites bezoeken. Zulke programma’s noemen we crawlers of bots. Zoekmachines zoals Google gebruiken ze om webpagina’s te ontdekken, inhoud te analyseren en wijzigingen op websites op te merken.
Het bestand bevindt zich op een vaste plaats: rechtstreeks achter de domeinnaam van je website.
https://theotherconcept.be/robots.txt
Wanneer een crawler je website wil bezoeken, kan die eerst het robots.txt-bestand raadplegen. Daarin staat bijvoorbeeld dat bepaalde mappen niet gecrawld mogen worden of dat een specifieke bot andere regels moet volgen.
Je kunt robots.txt vergelijken met een bord aan de ingang van een gebouw. Het vertelt bezoekers welke ruimtes toegankelijk zijn en welke niet. Alleen is er een belangrijk verschil: robots.txt is een verzameling instructies, geen afgesloten deur. Betrouwbare zoekmachinecrawlers respecteren die instructies, maar niet iedere bot doet dat.
Waarom bestaat robots.txt eigenlijk?
Toen zoekmachines het internet begonnen te doorzoeken, ontstond de behoefte om websitebeheerders enige controle te geven over automatische bezoeken. In 1994 werd daarvoor het Robots Exclusion Protocol geïntroduceerd.
Het principe was eenvoudig: één publiek toegankelijk bestand waarin website-eigenaren konden aangeven welke delen van hun website crawlers beter niet bezoeken.
In 2022 werd dit protocol formeel vastgelegd in RFC 9309. De basisgedachte is al die jaren grotendeels hetzelfde gebleven, maar het aantal toepassingen en soorten crawlers is sterk gegroeid.
Hoe werkt een robots.txt-bestand?
Een robots.txt-bestand bestaat uit eenvoudige tekstregels. Je hebt er geen ingewikkelde programmeertaal voor nodig.
Een basisvoorbeeld ziet er zo uit:
User-agent: *
Disallow: /private/
Sitemap: https://theotherconcept.be/sitemap_index.xmlDeze regels betekenen het volgende:
- User-agent: * – De instructies gelden voor alle crawlers die deze regels ondersteunen.
- Disallow: /private/ – Crawlers krijgen de instructie om URL’s onder deze map niet te bezoeken.
- Sitemap: – Verwijst naar de XML-sitemap van de website.
De meeste websites hebben geen bijzonder uitgebreid robots.txt-bestand nodig. Vaak volstaan enkele regels om ongewenste crawlactiviteiten te beperken en zoekmachines naar de sitemap te verwijzen.
De belangrijkste robots.txt-richtlijnen
| Richtlijn | Functie |
|---|---|
User-agent |
Bepaalt op welke crawler een groep regels van toepassing is. |
Disallow |
Geeft aan welke URL-paden niet gecrawld mogen worden. |
Allow |
Maakt het mogelijk om uitzonderingen toe te staan binnen een bredere blokkade. |
Sitemap |
Verwijst naar de locatie van een XML-sitemap. |
# |
Wordt gebruikt om commentaar toe te voegen aan het bestand. |
Met User-agent: * richt je je tot alle crawlers. Wil je specifiek instructies geven aan Googlebot, dan kun je een aparte groep maken.
User-agent: Googlebot
Disallow: /voorbeeldmap/Je kunt ook verschillende groepen combineren. Houd er wel rekening mee dat crawlers regels op hun eigen manier kunnen ondersteunen en interpreteren. Een regel die bij Google werkt, hoeft niet automatisch hetzelfde effect te hebben bij iedere andere bot.
Wat betekenen het sterretje en het dollarteken?
Bij Google kun je in URL-patronen ook speciale tekens gebruiken.
Het sterretje * kan overeenkomen met een willekeurige reeks tekens. Het dollarteken $ markeert het einde van een URL.
Bijvoorbeeld:
User-agent: *
Disallow: /*.pdf$Voor Googlebot betekent dit dat URL’s die eindigen op .pdf niet gecrawld mogen worden.
Dat kan in specifieke situaties nuttig zijn, maar het is geen standaardregel die je zomaar op iedere website moet toepassen. Misschien wil je net dat bepaalde PDF-documenten via Google gevonden worden.
Een andere richtlijn die je soms tegenkomt, is Crawl-delay. Sommige crawlers ondersteunen die, maar Googlebot houdt geen rekening met Crawl-delay in robots.txt.
Robots.txt is niet hetzelfde als noindex
Dit is waarschijnlijk het belangrijkste onderscheid in het volledige artikel.
Robots.txt regelt welke URL’s een crawler mag bezoeken. Noindex geeft aan dat een pagina niet in de zoekresultaten mag worden opgenomen.
Dat lijkt misschien op hetzelfde neer te komen, maar technisch zijn het twee verschillende zaken.
Stel dat je een pagina hebt die niet in Google mag verschijnen. Je voegt de volgende regel toe:
User-agent: *
Disallow: /verborgen-pagina/Google krijgt nu de instructie om die pagina niet te crawlen. Maar dat betekent niet noodzakelijk dat de URL uit de zoekresultaten verdwijnt.
Wanneer andere websites naar die URL linken, kan Google het bestaan ervan nog steeds ontdekken. De URL kan dan onder bepaalde omstandigheden in de zoekresultaten verschijnen, zelfs zonder dat Google de inhoud heeft bezocht.
Wil je voorkomen dat een toegankelijke pagina geïndexeerd wordt, dan gebruik je doorgaans een noindex-instructie.
Waarom robots.txt en noindex elkaar kunnen tegenwerken
Een veelgemaakte fout is om dezelfde pagina zowel via robots.txt te blokkeren als een noindex-instructie mee te geven.
Het probleem? Als Google de pagina niet mag crawlen, kan Google de noindex-instructie op die pagina mogelijk niet lezen.
Daardoor bereik je net niet wat je wilde.
Wil je een pagina uit de zoekresultaten houden, dan moet Google de noindex-instructie kunnen ontdekken. Voor echt vertrouwelijke informatie is zelfs dat niet voldoende: die beveilig je met toegangscontrole, bijvoorbeeld via een wachtwoord.
En wat doet een XML-sitemap dan?
Een XML-sitemap heeft opnieuw een andere functie. Ze helpt zoekmachines belangrijke URL’s van je website te ontdekken.
Waar robots.txt bepaalde crawlactiviteiten kan beperken, geeft een sitemap juist aan welke URL’s je onder de aandacht van zoekmachines wilt brengen.
Een sitemap is geen garantie op indexering en kan een blokkade in robots.txt niet opheffen.
In ons artikel over XML-sitemaps en SEO leggen we uitgebreider uit hoe zo’n sitemap werkt en waarom een correcte samenstelling belangrijk is.
Welke pagina’s kun je beter wel of niet blokkeren?
Niet iedere URL op een website is even belangrijk voor zoekmachines.
Een website kan bijvoorbeeld interne zoekresultaten, filtercombinaties, tijdelijke URL’s of technische onderdelen bevatten die weinig waarde hebben als afzonderlijke zoekresultaten.
Voor sommige van die URL’s kan het nuttig zijn om crawling te beperken. Maar dat betekent niet dat je ze allemaal automatisch in robots.txt moet blokkeren.
Wanneer kan een blokkade nuttig zijn?
Denk aan een grote webshop met honderden productfilters. Eén categorie kan via combinaties van kleur, maat, merk en prijs duizenden verschillende URL’s opleveren.
Wanneer zoekmachines al die varianten proberen te bezoeken, kan dat onnodige crawlactiviteit veroorzaken.
In zo’n situatie kan robots.txt onderdeel zijn van een bredere technische SEO-aanpak. Je moet dan wel rekening houden met de vraag of bepaalde filterpagina’s misschien juist relevant zijn voor organisch zoekverkeer.
Ook technische mappen of interne zoekresultaten kunnen kandidaten zijn, afhankelijk van hoe de website is opgebouwd.
Wat blokkeer je doorgaans beter niet?
Belangrijke dienstenpagina’s, productpagina’s, categoriepagina’s en blogartikelen moeten normaal toegankelijk blijven voor zoekmachines.
Hetzelfde geldt voor CSS- en JavaScript-bestanden die nodig zijn om je website correct weer te geven. Google probeert pagina’s namelijk ook te begrijpen zoals een bezoeker ze ziet.
Als je essentiële bestanden blokkeert, kan dat de manier waarop Google je pagina interpreteert negatief beïnvloeden.
Let ook op met het blokkeren van afbeeldingen. Wanneer je wilt dat productfoto’s of andere beelden via Google Afbeeldingen gevonden worden, is het doorgaans niet verstandig om hun bestanden voor Googlebot-Image af te schermen.
Robots.txt instellen in WordPress
Gebruik je WordPress? Dan hoef je niet noodzakelijk zelf een robots.txt-bestand aan te maken.
WordPress kan standaard een virtueel robots.txt-bestand aanbieden. Dat betekent dat de inhoud dynamisch wordt weergegeven, ook wanneer er geen fysiek bestand in de hoofdmap van je hosting staat.
Een veelvoorkomend voorbeeld voor WordPress is:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://theotherconcept.be/sitemap_index.xmlHiermee wordt de WordPress-beheermap voor crawlers geblokkeerd, met een uitzondering voor het bestand admin-ajax.php.
De sitemap-URL is slechts een voorbeeld. Welke URL je gebruikt, hangt af van de sitemap die jouw website daadwerkelijk aanbiedt.
Kun je robots.txt aanpassen met Yoast SEO?
Bij WordPress zijn er verschillende manieren om robots.txt te beheren. Afhankelijk van je configuratie kun je hiervoor een SEO-plugin, een bestandsbeheerder of een FTP-verbinding gebruiken.
Yoast SEO biedt in bepaalde configuraties een bestandseditor waarmee je robots.txt kunt aanmaken of aanpassen. De beschikbaarheid daarvan hangt onder meer af van je WordPress- en serverinstellingen.
Werk je met een fysiek robots.txt-bestand, dan heeft dat doorgaans voorrang op het virtuele bestand van WordPress.
Pas robots.txt nooit zomaar aan omdat een online voorbeeld beweert dat bepaalde regels je SEO-score verbeteren. De juiste instellingen hangen af van je website, je technische opbouw en de URL’s die je wilt laten crawlen.
En wat met WooCommerce?
Bij WooCommerce komen er extra aandachtspunten bij.
Een webshop heeft vaak een winkelmandje, afrekenpagina, klantaccount, productfilters en interne zoekresultaten. Sommige van die URL’s hoeven niet in Google te verschijnen.
Toch is robots.txt niet automatisch de beste oplossing om ze uit de zoekresultaten te houden. Voor bepaalde pagina’s is noindex geschikter, terwijl je voor filter- en parameter-URL’s ook moet kijken naar canonical-tags, interne links en de structuur van de webshop.
Een goede WooCommerce-configuratie is dus meer dan een lijstje mappen blokkeren.
Veelgemaakte fouten met robots.txt
Een verkeerd robots.txt-bestand kan belangrijke delen van je website ontoegankelijk maken voor zoekmachines. Daarom is het verstandig om wijzigingen altijd zorgvuldig te controleren.
Per ongeluk je volledige website blokkeren
De bekendste fout is deze:
User-agent: *
Disallow: /Deze regels geven alle crawlers die ze respecteren de instructie om geen enkele URL van de website te crawlen.
Zo’n instelling kan bewust worden gebruikt tijdens de ontwikkeling van een website. Maar wanneer ze na de lancering blijft staan, kan dat grote gevolgen hebben voor de organische vindbaarheid.
Een bestaande indexering verdwijnt daardoor niet noodzakelijk onmiddellijk, maar zoekmachines kunnen de inhoud niet meer normaal opnieuw crawlen.
Robots.txt gebruiken als beveiliging
Een robots.txt-bestand is publiek toegankelijk. Iedereen kan het openen en zien welke paden je erin vermeldt.
Het is daarom geen geschikte plaats om gevoelige URL’s te verbergen.
Een regel zoals Disallow: /vertrouwelijke-documenten/ verhindert niet dat iemand die het adres kent de bestanden rechtstreeks probeert te openen.
Voor vertrouwelijke informatie gebruik je echte beveiliging, zoals authenticatie en correcte toegangsrechten.
Verkeerde paden of onnodige blokkades
Robots.txt werkt met URL-paden. Een kleine fout kan ervoor zorgen dat een regel meer of minder blokkeert dan je bedoelde.
Ook een robots.txt-bestand op de verkeerde locatie werkt niet zoals verwacht. Het bestand hoort in de hoofdmap van de betreffende host en geldt niet automatisch voor andere subdomeinen.
Controleer daarom altijd het uiteindelijke effect van je regels, niet alleen of het bestand technisch bestaat.
Robots.txt en AI-crawlers: kun je AI-bots blokkeren?
Robots.txt krijgt tegenwoordig een extra dimensie door de opkomst van generatieve AI.
Naast traditionele zoekmachinecrawlers bezoeken ook AI-gerelateerde systemen websites. Sommige verzamelen informatie die mogelijk wordt gebruikt voor modeltraining, terwijl andere websites bezoeken om informatie voor zoek- en antwoordfuncties te verzamelen.
Die toepassingen zijn niet allemaal hetzelfde. Daarom is het belangrijk om te begrijpen welke crawler je precies aanstuurt.
Wat is het verschil tussen GPTBot en OAI-SearchBot?
OpenAI maakt onder meer onderscheid tussen twee crawlers.
GPTBot wordt gebruikt om inhoud te crawlen die mogelijk kan bijdragen aan de training van generatieve AI-modellen.
OAI-SearchBot wordt gebruikt voor zoekfuncties van ChatGPT. Deze crawler helpt websites vindbaar te maken binnen de zoekresultaten van ChatGPT.
Je kunt voor beide afzonderlijke robots.txt-instructies instellen.
Stel dat je crawling voor mogelijke modeltraining wilt beperken, maar wel gevonden wilt kunnen worden via ChatGPT Search. Dan kan een configuratie er bijvoorbeeld zo uitzien:
User-agent: GPTBot
Disallow: /
User-agent: OAI-SearchBot
Allow: /Hiermee geef je GPTBot de instructie om je website niet te crawlen, terwijl OAI-SearchBot toegang krijgt.
Dat is geen garantie dat je website daadwerkelijk in ChatGPT-antwoorden verschijnt. Het betekent alleen dat je die specifieke zoekcrawler niet via robots.txt blokkeert.
OpenAI gebruikt daarnaast ChatGPT-User voor bepaalde bezoeken die door een gebruiker worden gestart. Omdat dit geen gewone automatische zoekcrawler is, kunnen robots.txt-regels daar anders op van toepassing zijn.
De actuele verschillen staan beschreven in de officiële documentatie over OpenAI-crawlers.
En hoe zit het met Google-Extended?
Google heeft met Google-Extended een afzonderlijk controlemechanisme waarmee websitebeheerders bepaalde toepassingen van hun inhoud voor Google’s generatieve AI-systemen kunnen beperken.
Google-Extended is geen afzonderlijke crawler die zelfstandig je website bezoekt, maar een controletoken dat via robots.txt gebruikt wordt.
Belangrijk: Google-Extended blokkeren is niet hetzelfde als Googlebot blokkeren. Het betekent ook niet dat je pagina’s automatisch verdwijnen uit AI Overviews of andere AI-functies binnen Google Search.
Voor de AI-functies van Google Search blijven de gewone zoek- en previewinstellingen relevant. Denk bijvoorbeeld aan noindex, nosnippet en andere ondersteunde previewbeperkingen.
Wat is het verschil tussen robots.txt en llms.txt?
Door de opkomst van AI wordt ook steeds vaker gesproken over llms.txt.
Hoewel de bestandsnamen op elkaar lijken, hebben ze een ander doel.
Robots.txt is een gevestigde standaard voor het aansturen van crawlers. Llms.txt is een voorstel om AI-systemen een gestructureerd overzicht van relevante website-inhoud aan te bieden.
Het is dus geen vervanging voor robots.txt en biedt niet dezelfde controle over crawling.
In ons artikel llms.txt: nuttig voor AI-vindbaarheid of vooral hype? bekijken we wat dat bestand precies belooft en welke beperkingen er vandaag nog zijn.
Hoe controleer je of je robots.txt correct werkt?
Je hoeft geen programmeur te zijn om de basis van je robots.txt te controleren.
Begin door je domeinnaam te openen met /robots.txt erachter. Verschijnt er een tekstbestand, dan kun je de regels rechtstreeks bekijken.
Controleer vervolgens of er geen algemene blokkade staat die je volledige website uitsluit. Kijk ook of belangrijke onderdelen, zoals je dienstenpagina’s, blogartikelen en productpagina’s, toegankelijk blijven.
Voor een meer gerichte controle kun je gebruikmaken van Google Search Console.
Met de URL-inspectietool kun je onderzoeken of Google een specifieke pagina mag crawlen en welke indexeringsinformatie beschikbaar is. Daarnaast biedt Search Console informatie over de robots.txt-bestanden die Google voor je website heeft opgehaald.
De officiële robots.txt-documentatie van Google is een goede referentie wanneer je twijfelt over de werking van een bepaalde regel.
Controleer ook wat er na een wijziging gebeurt
Een robots.txt-aanpassing heeft niet noodzakelijk onmiddellijk effect. Zoekmachines bewaren het bestand tijdelijk en moeten gewijzigde regels opnieuw ophalen en verwerken.
Daarom is het verstandig om na een aanpassing belangrijke URL’s te controleren en eventuele crawlproblemen op te volgen.
Wil je daarnaast de technische kwaliteit van je website onderzoeken? Met Google Lighthouse kun je onder andere prestaties, toegankelijkheid en bepaalde technische SEO-aspecten analyseren. Voor de specifieke werking van robots.txt blijft Search Console de meest gerichte keuze.
Heeft robots.txt invloed op je SEO?
Ja, maar niet op de manier die soms wordt voorgesteld.
Een robots.txt-bestand is geen rechtstreekse rankingfactor waarmee je hoger in Google verschijnt. Door een extra regel toe te voegen, stijgt je website dus niet automatisch in de zoekresultaten.
Het bestand kan wel een belangrijke rol spelen in de technische toegankelijkheid van je website.
Wanneer zoekmachines je belangrijkste pagina’s niet mogen crawlen, kunnen ze de inhoud niet normaal verwerken. Omgekeerd kan het beperken van onnodige crawlactiviteiten op grote websites helpen om beschikbare crawlcapaciteit gerichter te benutten.
Dat brengt ons bij het begrip crawlbudget.
Wat is crawlbudget?
Crawlbudget verwijst naar de hoeveelheid URL’s die een zoekmachine binnen een bepaalde periode kan en wil crawlen.
Voor een kleine bedrijfswebsite met enkele tientallen pagina’s is crawlbudget doorgaans geen groot aandachtspunt. Google kan zulke websites meestal zonder problemen bezoeken.
Bij grote webshops, nieuwssites of websites met zeer veel URL-varianten kan dat anders liggen. Daar kunnen overbodige filterpagina’s, parameters en dubbele URL’s onnodig veel crawlactiviteit veroorzaken.
Robots.txt kan dan onderdeel zijn van een bredere strategie, samen met een goede URL-structuur, interne links, canonical-tags en een verzorgde XML-sitemap.
Wie zijn website beter vindbaar wil maken, moet dus verder kijken dan één technisch bestand. In ons artikel over hoger scoren in Google bespreken we de belangrijkste SEO-principes die samen het verschil maken.
Veelgestelde vragen over robots.txt
Is een robots.txt-bestand verplicht?
Nee. Een website heeft niet verplicht een robots.txt-bestand nodig. Als er geen geldig bestand aanwezig is, kunnen zoekmachines de website doorgaans crawlen, voor zover andere technische beperkingen dat toelaten. Je gebruikt robots.txt vooral wanneer je bepaalde crawlactiviteiten bewust wilt sturen.
Kan Google een geblokkeerde pagina toch indexeren?
Ja. Een URL die via robots.txt geblokkeerd is, kan onder bepaalde omstandigheden toch in de zoekresultaten verschijnen, bijvoorbeeld wanneer andere websites ernaar linken. Google kan de inhoud dan niet normaal crawlen, maar kent mogelijk wel het bestaan van de URL.
Kan ik robots.txt gebruiken om een pagina uit Google te verwijderen?
Niet betrouwbaar. Voor een toegankelijke pagina die je niet geïndexeerd wilt hebben, gebruik je doorgaans noindex. Voor vertrouwelijke informatie is toegangsbeveiliging noodzakelijk. Robots.txt is geen vervanging voor die maatregelen.
Hoe vaak leest Google mijn robots.txt?
Google haalt robots.txt regelmatig opnieuw op en bewaart het bestand doorgaans tijdelijk in een cache. Hoe snel een wijziging wordt verwerkt, kan variëren. Ga er daarom niet van uit dat nieuwe regels onmiddellijk door iedere crawler worden toegepast.
Is robots.txt hetzelfde als llms.txt?
Nee. Robots.txt bevat instructies over crawling. Llms.txt is een voorstel om AI-systemen te helpen relevante website-inhoud te vinden en te interpreteren. Het heeft niet dezelfde status of functie als robots.txt.
Moet ik AI-crawlers blokkeren?
Dat hangt af van je doelstellingen. Wil je vooral voorkomen dat bepaalde systemen je inhoud voor modeltraining crawlen, dan kun je specifieke bots beperken. Wil je juist zo goed mogelijk gevonden worden via AI-zoekfuncties, dan moet je opletten dat je de daarvoor gebruikte crawlers niet onbedoeld blokkeert.
Een klein bestand met grote gevolgen
Robots.txt is geen magische SEO-oplossing, maar wel een belangrijk onderdeel van de technische basis van je website.
Met de juiste regels kun je zoekmachinecrawlers helpen om je website efficiënter te bezoeken. Met verkeerde regels kun je echter ook belangrijke pagina’s onbedoeld afsluiten.
Het belangrijkste is daarom niet dat je robots.txt zoveel mogelijk instructies bevat, maar dat iedere regel een duidelijke reden heeft.
Bij The Other Concept bekijken we technische SEO altijd als onderdeel van het grotere geheel. Van websitestructuur en indexering tot laadsnelheid en vindbaarheid in zoekmachines en AI-toepassingen. Want een website moet niet alleen goed ogen en vlot werken, maar ook correct ontdekt en begrepen kunnen worden.
Ontdek hoe we dat aanpakken met SEO en AI-vindbaarheid.
Laatst bijgewerkt op 14 oktober 2026.
Gerelateerde artikelen
XML-sitemap: wat is het en waarom is het belangrijk voor SEO?
Een zoekmachine moet je pagina’s eerst ontdekken voordat ze gecrawld en uiteindelijk eventueel geïndexeerd kunnen worden. Interne links spelen daarbij een belangrijke rol, maar je kunt zoekmachines ook rechtstreeks een overzicht geven van de URL’s die je belangrijk vindt.
Dat gebeurt met een XML-sitemap.
Een XML-sitemap is een technisch bestand met URL’s van je website. Het helpt zoekmachines zoals Google om pagina’s te ontdekken en geeft aanvullende informatie over die URL’s door.
Maar wat staat er precies in zo’n sitemap? Heeft iedere website er één nodig? En zorgt het indienen van een sitemap ervoor dat Google je pagina’s automatisch indexeert?
Wat is een XML-sitemap?
Een XML-sitemap is een bestand waarin je zoekmachines informatie geeft over belangrijke pagina’s en andere bestanden op je website.
Je kunt het zien als een gestructureerd overzicht van de URL’s waarvan je wilt dat zoekmachines ze kennen. Dat maakt een XML-sitemap fundamenteel anders dan llms.txt: dat bestand is een voorgestelde standaard om AI-agents een gecureerde, machinevriendelijke ingang tot belangrijke informatie te geven.
Google kan een website ook ontdekken door links te volgen. Wanneer pagina A naar pagina B linkt, kan Googlebot via die link op pagina B terechtkomen. Een goede structuur van interne links helpt zoekmachines bovendien begrijpen hoe verschillende pagina’s en onderwerpen op je website met elkaar samenhangen.
Een sitemap biedt daarnaast een afzonderlijke route om URL’s te ontdekken.
Volgens Google Search Central kan een sitemap zoekmachines helpen een website efficiënter te crawlen. Dat kan vooral interessant zijn bij grotere websites, nieuwe websites met weinig externe links en sites met veel media of regelmatig nieuwe content.
Een sitemap vervangt een goede interne linkstructuur dus niet. Beide vullen elkaar aan.
Hoe ziet een XML-sitemap eruit?
XML staat voor Extensible Markup Language. Een sitemap is daardoor in de eerste plaats gemaakt om door machines gelezen te worden, niet om er voor bezoekers aantrekkelijk uit te zien.
Een eenvoudige sitemap kan bijvoorbeeld informatie bevatten zoals:
<url>
<loc>https://www.example.com/webdesign/</loc>
<lastmod>2026-09-28</lastmod>
</url>
De belangrijkste informatie is hier de URL in het <loc>-element.
Daarnaast kan <lastmod> aangeven wanneer de pagina voor het laatst betekenisvol gewijzigd werd.
Dat laatste is interessanter dan het misschien lijkt.
Wat doet lastmod?
Met <lastmod> kun je aangeven wanneer de inhoud van een URL voor het laatst substantieel gewijzigd werd.
Dat betekent niet dat je de datum moet veranderen telkens wanneer er ergens automatisch een jaartal, footer of ander klein detail wijzigt.
Google geeft aan dat lastmod bruikbaar is wanneer die waarde consistent en aantoonbaar correct is. Een wijziging aan de hoofdinhoud, structured data of belangrijke links kan bijvoorbeeld wel een relevante aanpassing zijn.
Dat maakt lastmod bijzonder interessant wanneer je oudere artikels regelmatig grondig actualiseert.
En priority en changefreq?
In oudere sitemapvoorbeelden kom je soms nog elementen zoals <priority> en <changefreq> tegen.
Daarmee kon je aangeven hoe belangrijk een URL volgens jou was of hoe vaak een pagina ongeveer veranderde.
Voor Google hoef je daar tegenwoordig geen tijd in te steken. Google geeft expliciet aan dat het de waarden van priority en changefreq negeert.
Een correcte lijst met canonieke URL’s en betrouwbare lastmod-informatie is dus veel interessanter.
Een sitemap index is niet hetzelfde als één sitemap
Bij een WordPress-website kom je vaak eerst op een sitemap index terecht.
Die bevat niet noodzakelijk alle pagina-URL’s rechtstreeks, maar verwijst naar verschillende onderliggende sitemaps.
Je kunt bijvoorbeeld aparte sitemaps hebben voor:
- pagina’s;
- blogposts;
- producten;
- portfolio-items;
- categorieën of andere relevante contenttypes.
Zo blijft de structuur overzichtelijk en kunnen grote aantallen URL’s over verschillende bestanden verdeeld worden.
Dat is ook nodig bij zeer grote websites: één sitemapbestand mag volgens Google maximaal 50 MB ongecomprimeerd of 50.000 URL’s bevatten. Wanneer je daarboven komt, moet de sitemap worden opgesplitst. Een sitemap index kan die afzonderlijke bestanden vervolgens samenbrengen.
Welke pagina’s horen in je XML-sitemap?
Een sitemap hoeft geen inventaris te zijn van iedere URL die technisch op je website bestaat.
Het uitgangspunt is veel eenvoudiger: neem URL’s op waarvan je wilt dat ze in de zoekresultaten kunnen verschijnen.
Voor een bedrijfswebsite zijn dat bijvoorbeeld dienstenpagina’s, relevante informatieve pagina’s, blogartikels en portfolio-items.
URL’s die bewust op noindex staan, horen daar normaal gesproken niet tussen.
Hetzelfde geldt voor URL’s die naar een andere canonieke versie verwijzen. Google raadt aan om in een sitemap de URL’s op te nemen die je zelf als canonieke versies beschouwt.
Een goede sitemap en je andere technische SEO-signalen vertellen dus hetzelfde verhaal.
Heb je voor SEO altijd een XML-sitemap nodig?
Niet noodzakelijk.
Google geeft zelf aan dat het bij een kleine website met een goede interne linkstructuur meestal in staat is om belangrijke pagina’s via links te ontdekken.
Een sitemap wordt interessanter wanneer een website groot is, pas gelanceerd werd, relatief weinig externe links heeft of veel content bevat die moeilijker ontdekt kan worden.
Toch zou ik ook bij een kleinere bedrijfswebsite gewoon een sitemap voorzien.
Moderne contentmanagementsystemen en SEO-plugins kunnen ze automatisch genereren en onderhouden. De technische kost is daardoor minimaal en je geeft zoekmachines een extra, gestandaardiseerde manier om je belangrijke URL’s te ontdekken.
Belangrijk is wel de nuance: een sitemap is een hulpmiddel voor crawling en ontdekking, geen garantie op indexatie.
Een URL die in je sitemap staat, krijgt niet automatisch een plaats in Google.
Crawlen en indexeren zijn niet hetzelfde
Dit onderscheid is belangrijk.
Wanneer Google een URL ontdekt, weet de zoekmachine dat de pagina bestaat.
Vervolgens kan Google de pagina crawlen: Googlebot bezoekt de URL en verwerkt wat er staat.
Daarna kan de pagina eventueel worden geïndexeerd, waardoor ze in aanmerking komt om in zoekresultaten te verschijnen.
Een XML-sitemap helpt vooral bij de eerste stappen van dat proces.
Ze vertelt Google welke URL’s je belangrijk vindt en kan helpen nieuwe of gewijzigde pagina’s te ontdekken. Maar Google beslist nog altijd zelf welke URL’s gecrawld en geïndexeerd worden.
Daarom is de gedachte mijn URL staat in de sitemap, dus Google moet hem indexeren niet correct.
De inhoud en technische kwaliteit van de pagina blijven belangrijk.
Hoe maak je een XML-sitemap in WordPress?
Bij een WordPress-website hoef je meestal niet zelf een XML-bestand te schrijven.
WordPress beschikt over sitemapfunctionaliteit en verschillende SEO-plugins kunnen uitgebreidere XML-sitemaps genereren.
Bij The Other Concept werken we onder andere met Yoast SEO.
Yoast maakt automatisch een sitemap index en onderliggende sitemaps aan. Wanneer content wordt toegevoegd of verwijderd, worden die automatisch bijgewerkt. Contenttypes die via Yoast als noindex zijn ingesteld, worden eveneens uit de XML-sitemap gehouden.
Dat laatste is handig omdat je instellingen voor indexatie en sitemap zo beter op elkaar afgestemd blijven.
Bij een standaard Yoast-installatie vind je de sitemap index doorgaans via:
https://theotherconcept.be/sitemap_index.xml
Je hoeft die sitemap dus niet iedere keer handmatig opnieuw te genereren wanneer je een blogpost publiceert.
Hoe dien je een XML-sitemap in bij Google?
Wanneer je sitemap beschikbaar is, kun je ze indienen via Google Search Console.
Binnen de juiste property vind je daarvoor het onderdeel Sitemaps. Daar kun je het adres van je sitemap of sitemap index doorgeven.
Bij een WordPress-site met Yoast is dat vaak eenvoudigweg:
sitemap_index.xml
Na verwerking kan Search Console aangeven of Google de sitemap succesvol kon lezen en of er eventuele problemen zijn.
Het indienen via Search Console heeft bovendien een praktisch voordeel: je kunt er controleren of Google de sitemap kon verwerken en wanneer ze voor het laatst gelezen werd.
Je hoeft een ongewijzigde sitemap vervolgens niet voortdurend opnieuw in te dienen.
Google kan een sitemap ook ontdekken wanneer je ernaar verwijst vanuit je robots.txt-bestand.
Zorgt een sitemap ervoor dat nieuwe pagina’s sneller in Google staan?
Niet automatisch.
Een actuele sitemap kan Google helpen een nieuwe of gewijzigde URL te ontdekken, maar dat betekent niet dat de pagina onmiddellijk gecrawld of geïndexeerd wordt.
Google beschrijft een ingediende sitemap zelf als een hint.
Dat onderscheid is belangrijk omdat SEO anders al snel gereduceerd wordt tot technische vinkjes: sitemap indienen, klaar.
Zo werkt het niet.
Wanneer een belangrijke pagina na langere tijd nog altijd niet geïndexeerd wordt, moet je verder kijken. Is de pagina crawlbaar? Staat er per ongeluk een noindex? Is de canonical correct? Zijn er interne links naar de pagina? En biedt de inhoud voldoende waarde?
Voor individuele belangrijke URL’s kun je daarnaast de URL-inspectietool in Google Search Console gebruiken om de indexeringsstatus te onderzoeken.
Veelgemaakte fouten bij XML-sitemaps
Een sitemap automatisch laten genereren betekent niet dat er nooit iets fout kan lopen.
Een aantal zaken zijn het controleren waard.
Niet-indexeerbare URL’s opnemen
Pagina’s die bewust niet geïndexeerd mogen worden, horen normaal gesproken niet in je sitemap.
Wanneer je sitemap zegt deze URL is belangrijk voor Search terwijl een noindex-instructie zegt indexeer deze pagina niet, geef je tegenstrijdige signalen.
Niet-canonieke URL’s opnemen
Gebruik in je sitemap bij voorkeur de URL die je ook als canonical beschouwt.
Verschillende URL-varianten van dezelfde content in een sitemap plaatsen levert weinig op en maakt de technische structuur minder duidelijk.
Onbetrouwbare lastmod-datums
Een automatisch bijgewerkte datum heeft alleen waarde wanneer hij daadwerkelijk iets zegt over een betekenisvolle wijziging aan de pagina.
Google kan lastmod gebruiken wanneer de informatie consequent betrouwbaar blijkt te zijn.
Denken dat een sitemap interne links vervangt
Ook met een perfecte sitemap blijft een logische interne linkstructuur belangrijk.
Interne links helpen zoekmachines niet alleen pagina’s ontdekken, maar geven ook context en laten zien hoe verschillende onderwerpen op je website met elkaar samenhangen.
Een sitemap is dus een aanvulling op je websitestructuur, geen alternatief ervoor.
Een XML-sitemap is klein, maar nuttig
Een XML-sitemap gaat je website niet plots bovenaan Google plaatsen.
Dat is ook niet haar functie.
Ze geeft zoekmachines een duidelijk overzicht van de URL’s die jij belangrijk vindt en kan helpen bij het ontdekken van nieuwe of gewijzigde content. Vooral op grotere, nieuwe of regelmatig bijgewerkte websites is dat nuttig.
Voor WordPress-websites kan het beheer bovendien grotendeels automatisch gebeuren met een SEO-plugin zoals Yoast.
Daarmee is een XML-sitemap een relatief klein onderdeel van technische SEO, maar wel eentje dat gewoon correct moet staan.
Bij The Other Concept bekijken we zo’n sitemap daarom niet los van de rest. Indexeerbaarheid, canonicals, interne links, structured data, performance en inhoud moeten uiteindelijk samen één technisch consistente website vormen.
Laatst bijgewerkt op 15 oktober 2026.
