Een website met honderden pagina’s zonder XML-sitemap is een concreet probleem: recente inhoud blijft wekenlang onzichtbaar omdat crawlers deze niet kunnen vinden. Dit komt vaak voor op e-commerce sites, op blogs met dagelijkse publicaties of op institutionele portals waarvan de structuur meer dan vier niveaus diep is.
De sitemap lost niet alles op, maar versnelt de ontdekking van URL’s door Google en Bing door hen een gestructureerde lijst te bieden van wat er op de site aanwezig is.
De lastmod-tag in een XML-sitemap: een vaak verkeerd gebruikte signalering
De meeste CMS’en vullen automatisch de lastmod-tag van de sitemap in bij elke pagina-opslag, zelfs voor een cosmetische wijziging. Google geeft aan dat deze tag alleen nuttig is als deze een significante update van de hoofdinhoud, gestructureerde gegevens of interne links weerspiegelt. Het wijzigen van een voettekst of een copyrightvermelding rechtvaardigt geen update van de datum.
Wanneer de lastmod-tag onbetrouwbare data verzendt, negeert Googlebot deze uiteindelijk. We verliezen dan het enige mechanisme van de sitemap dat een prioriteit voor recrawl kan signaleren. Voor een site die zijn productinformatie (prijzen, beschikbaarheid, beschrijvingen) bijwerkt, is dit een verspilde hefboom.
De beste praktijk is om lastmod alleen in te vullen bij daadwerkelijk waarneembare wijzigingen: gewijzigde redactionele inhoud, nieuwe afbeelding toegevoegd, bijgewerkte gestructureerde gegevens. Als we de juistheid van de datum niet kunnen garanderen, is het beter om de tag weg te laten dan om valse signalen te verzenden. We kunnen een concreet voorbeeld bekijken door de sitemap van de site Experts Marketing te raadplegen, die de structuur van een XML-bestand met zijn datum-tags illustreert.
Sitemap en crawlbudget: waarom de bestandsgrootte telt
Op een site met enkele tientallen pagina’s en een goede interne linkstructuur is de XML-sitemap bijna overbodig. Google zal de URL’s vinden door de links te volgen. De situatie verandert radicaal voor grote sites of voor sites waarvan sommige pagina’s zwak met elkaar zijn verbonden.
Het sitemapprotocol legt een limiet op van 50.000 URL’s per bestand en een maximaal ongecomprimeerd gewicht volgens de standaard. Daarboven splitsen we in meerdere bestanden die worden verwezen door een sitemapindex. Deze splitsing is niet alleen een technische formaliteit: een overbelaste sitemap met verouderde URL’s verzwakt de aandacht van crawlers voor de belangrijke pagina’s.
- Exclusief de omgeleide URL’s (301), pagina’s in noindex en de gecanonicaliseerde URL’s naar andere pagina’s uit de sitemap. Hun aanwezigheid genereert fouten in de Google Search Console en verstoort de diagnose.
- Verschillende soorten inhoud (artikelen, productbladen, afbeeldingen, video’s) in aparte sitemap-bestanden scheiden om het volgen in de Search Console te vergemakkelijken.
- De sitemap automatisch regenereren bij elke publicatie of verwijdering van inhoud, in plaats van op vaste intervallen, om de kloof tussen het bestand en de realiteit van de site te vermijden.
De meningen verschillen over de directe impact van de sitemap op het crawlbudget: Google beschouwt de sitemap als een ontdekking signaal, niet als een richtlijn. Maar op catalogi met duizenden referenties blijft een schone sitemap de meest betrouwbare manier om nieuwe URL’s te signaleren zonder te wachten tot een interne link handmatig wordt aangemaakt.
Indiening in Google Search Console: wat het sitemaprapport echt onthult
Een sitemap indienen via Search Console garandeert niet de indexering van de vermelde URL’s. Dit is een punt dat veel gidsen vergeten. De sitemap is een ontdekking signaal, geen indexeringsinstructie. Google beslist vervolgens, pagina voor pagina, of de inhoud het waard is om geïndexeerd te worden.
Het sitemaprapport van Search Console geeft de datum van de laatste toegang door Googlebot en het aantal gedetecteerde URL’s aan. Deze diagnose maakt het mogelijk om snel een probleem te identificeren:
- Als het aantal ontdekte URL’s lager is dan het aantal ingediende URL’s, bevatten sommige regels van het bestand fouten (URL’s geblokkeerd door robots.txt, 404-antwoorden, lusomleidingen).
- Als Googlebot de sitemap al weken niet heeft benaderd, is het bestand mogelijk niet toegankelijk of geeft de server een intermitterende foutcode terug.
- Als geïndexeerde URL’s niet in de sitemap staan, betekent dit dat het bestand incompleet is of dat de automatische regeneratie niet goed werkt.
We gebruiken dit rapport als een monitoringtool, niet als een dashboard voor de algehele SEO. Het combineren van de gegevens van de sitemap met het indexeringsdekking rapport geeft een completer beeld van de crawlstatus van de site.
XML- of HTML-sitemap: kiezen op basis van de werkelijke behoefte
De XML-sitemap is gericht op crawlers. De HTML-sitemap is gericht op bezoekers. Beide hebben niet hetzelfde formaat of dezelfde functie, en de verwarring tussen de twee blijft bestaan.
Voor natuurlijke SEO blijft het XML-bestand de prioriteit. Het structureert de URL’s met hun metadata (wijzigingsdatum, voorgestelde wijzigingsfrequentie) in een formaat dat leesbaar is voor zoekmachines. De HTML-sitemap daarentegen neemt de vorm aan van een klassieke webpagina die de secties van de site opsomt met klikbare links.
Een HTML-sitemap kan de navigatie op een site met een complexe structuur verbeteren, maar vervangt het XML-bestand niet voor de ontdekking van inhoud door zoekmachines. Op een goed gestructureerde site met een sterke interne linkstructuur voegt de HTML-sitemap niet veel toe. Op een institutionele site met tientallen subsecties die weinig met elkaar zijn verbonden, helpt het bezoekers een pagina te vinden zonder via de interne zoekfunctie te gaan.
De keuze hangt af van het profiel van de site. Een blog met minder dan vijftig artikelen en een duidelijke navigatie kan volstaan met de native XML die door zijn CMS wordt gegenereerd. Een e-commerce site met diepe categorieën en facettenfilters heeft behoefte aan een gesegmenteerde XML-sitemap en mogelijk een HTML-sitemap voor zijn gebruikers.
De sitemap blijft een technisch bestand onder andere optimalisatie-instrumenten. De echte bijdrage ervan meet je in Search Console, door de indexeringsdekking en de snelheid van ontdekking van nieuwe pagina’s te observeren. Een schoon, actueel bestand, ontdaan van onnodige URL’s, bespaart tijd voor crawlers en voor degenen die indexeringsproblemen diagnosticeren.
