XML-sitemap: een identieke lastmod op alle URL's maakt je sitemap nutteloos

Een XML-sitemap vertelt de zoekmachines welke URL's bestaan, en welke zijn veranderd. De eerste functie vervult bijna elk CMS. De tweede mislukt bij een flink deel ervan, en dat gebeurt onzichtbaar: het bestand is geldig, Search Console leest het zonder fout, en toch levert het geen enkele informatie meer over wat er is bewogen. De oorzaak zit in één enkel veld, lastmod, en in de manier waarop het wordt gevuld.

Wat Google werkelijk met lastmod doet

Het standpunt van Google staat zwart op wit in zijn documentatie over het bouwen van een sitemap: de waarde van lastmod wordt gebruikt "als die consistent en verifieerbaar is", bijvoorbeeld door haar te vergelijken met de werkelijke laatste wijziging van de pagina. Google voegt eraan toe dat de velden priority en changefreq worden genegeerd. Van de drie optionele velden van het format telt er één, en alleen als het de waarheid vertelt.

Vanuit de zoekmachine bekeken is de rekensom de volgende. Een bot beschikt per site over een beperkt crawlbudget. Als hij een sitemap opnieuw leest, vergelijkt hij de opgegeven datums met de datums die hij heeft onthouden. Een URL waarvan de datum is opgeschoven, verdient een nieuw bezoek; een URL waarvan de datum niet is bewogen, kan wachten. Schuiven alle datums bij elke leesbeurt tegelijk op, dan kan de zoekmachine een werkelijk bijgewerkte pagina niet meer onderscheiden van een ongewijzigde pagina. Uiteindelijk vertrouwt hij het veld niet meer en valt hij terug op zijn eigen heuristiek, die doorgaans trager is.

Het typische defect: de datum van de build

Veel generatoren van statische sites, en een flink aantal CMS'en, schrijven in lastmod de datum waarop de site opnieuw is gegenereerd. Op een site die dagelijks publiceert, dragen alle URL's dan de datum van vandaag, ook artikelen van drie jaar oud waar niemand aan heeft gezeten. De sitemap kondigt permanent aan dat alles is veranderd.

We hebben dit defect in de zomer van 2026 op meerdere productiesites gecontroleerd, over in totaal meer dan driehonderd URL's: in elk geval één enkele lastmod-waarde voor de hele sitemap, gelijk aan het tijdstip van de laatste build. Geen van die sites stuurde bovendien een HTTP-header Last-Modified of ETag mee op zijn pagina's, en geen enkele beantwoordde de conditionele requests van de bots. De zoekmachine had dus geen enkele manier om te weten wat er herladen moest worden.

Diagnose in drie controles

De controle kost een paar minuten, met een eenvoudige terminal.

1. Tel de verschillende lastmod-waarden. Haal de sitemap op, pak de lastmod-tags eruit en tel de unieke waarden. Een gezonde sitemap op een site van enkele honderden pagina's telt er tientallen. Eén enkele waarde, of een handvol met allemaal dezelfde dag, wijst op het defect.
2. Vergelijk lastmod met de pagina. Neem een oude URL uit de sitemap, open de pagina en vergelijk de wijzigingsdatum die in het artikel of in de gestructureerde data staat met de lastmod-waarde. Een verschil van meerdere maanden bevestigt dat lastmod de pagina niet beschrijft.
3. Test de HTTP-headers. Vraag een pagina op met een HEAD-request en kijk of de server Last-Modified of ETag teruggeeft. Stuur daarna dezelfde request opnieuw met If-Modified-Since op de ontvangen datum. Een server die 304 Not Modified antwoordt, kan zeggen dat een pagina niet is veranderd; een server die elke keer 200 teruggeeft, dwingt de bot om alles opnieuw te downloaden.

Die drie tests vragen geen betaald gereedschap. Ze horen bij de controles die we aanraden voordat er ook maar één gesprek over de indexering van een mediasite begint.

Waarom dit erger is voor een mediasite dan voor een bedrijfssite

Een bedrijfssite van twintig pagina's wordt hoe dan ook volledig opnieuw gecrawld. Een mediasite die meerdere artikelen per week publiceert en er andere van corrigeert, leeft van een betrouwbaar actualiteitssignaal: dat signaal laat een bijgewerkt artikel weer opkomen, en het voorkomt dat de bot zijn budget op bevroren pagina's uitgeeft. Is het signaal kapot, dan verschijnen er na een paar weken twee symptomen:

• Nieuwe artikelen doen er langer over om geïndexeerd te raken, omdat ze verdrinken in een sitemap waarin alles nieuw lijkt.
• Correcties op oude artikelen worden niet meegenomen, omdat niets een gecorrigeerde pagina onderscheidt van een pagina die gewoon door een build opnieuw is opgebouwd.

Op een mediasite die ook op generatieve engines mikt, wordt het probleem een tweede keer betaald: de bots van de zoek-AI's, die op dezelfde sitemaps steunen, erven het. Een pagina die is herzien om een cijfer te corrigeren, wordt wekenlang in de oude versie geserveerd.

Het correctiecriterium

Het defect corrigeren betekent lastmod de datum van de laatste redactionele wijziging van elke pagina laten dragen, en niets anders. Concreet:

Het opleveringscriterium is hetzelfde als dat van de diagnose: na correctie moet het aantal verschillende lastmod-waarden de werkelijke geschiedenis van de mediasite weerspiegelen, en twee opeenvolgende builds zonder redactionele wijziging moeten twee identieke sitemaps opleveren. Verandert de sitemap terwijl er niets is geschreven, dan is de correctie niet gedaan.

Het bijzondere geval van de mediasite in een submap

Wordt een mediasite onder een pad van de hoofdsite gehost, bijvoorbeeld een blog die vanaf een ander platform onder /blog/ wordt geserveerd, dan komt daar een tweede moeilijkheid bij: het robots.txt-bestand dat de sitemap aangeeft, wordt alleen op de root van de host gelezen. Een robots.txt in de submap wordt nooit geraadpleegd, en de Sitemap-regels daarin bestaan niet voor de zoekmachines, zoals de documentatie van Google over robots.txt in herinnering brengt. Je moet de sitemap van de mediasite dan aangeven in het robots.txt van de hoofdsite, of hem rechtstreeks indienen in Search Console. Google heeft in 2023 de mogelijkheid geschrapt om een sitemap te "pingen" met een eenvoudige HTTP-request: zonder expliciete aangifte heeft een mediasite in een subpad geen enkel ontdekkingskanaal.

Die twee defecten, uniforme lastmod en niet-ontdekte sitemap, corrigeer je eens en voor altijd op het niveau van de publicatietool. Het is het soort detail dat een CMS dat voor een mediasite is bedacht, structureel moet regelen, omdat geen enkele redactie het bij elke publicatie met de hand nagaat. Voor de andere actualiteitssignalen, de getoonde herzieningsdatum en de gestructureerde data, verwijzen we naar ons artikel "Actualiteit: dateren, herzien, bewijzen".