Publicatiedatum of bijwerkdatum: houd ze eerlijk

De publicatiedatum zegt wanneer de inhoud voor het eerst beschikbaar was. De bijwerkdatum zegt wanneer die inhoud inhoudelijk werd herzien. Het zijn twee verschillende feiten en je bewaart ze apart, ook als je site er maar één toont.

Een bijwerkdatum is een belofte aan de lezer: sinds de vorige versie is er iets veranderd dat telt. Dat kan een gecorrigeerd cijfer zijn, een vervangen stap, een nieuwe voorwaarde of een verwijderde, niet meer geldende bewering. Een gewijzigde komma, een nieuwe afbeeldingsgrootte of een herordend menu horen daar niet bij. Daarmee bepaal je jouw eigenregel: wat noem je een inhoudelijke wijziging en wat niet? Schrijf die regel één keer op en pas hem op elke pagina hetzelfde toe.

Twijfel je? Vraag je af: zou een lezer die de vorige versie las, iets anders doen of geloven na deze wijziging? Zo ja, dan verdient ze een datum en een notitie.

Maak per pagina een eenvoudig logboek, in een spreadsheet of in het systeem dat je gebruikt. Controleer zelf wat jouw CMS bewaart: dit verschilt per systeem. Kolommen die volstaan: pagina-URL, eerste publicatiedatum, datum van de wijziging, wat er veranderde in één zin, wie het controleerde, en de bron of aanleiding.

Leg het verschil ook voor de lezer zichtbaar uit, bijvoorbeeld met een regel onderaan de pagina: 'Oorspronkelijk gepubliceerd op [datum]. Bijgewerkt op [datum]: stap 3 vervangen en prijsvoorbeeld aangepast.' Dat is concreter dan alleen een nieuwe datum en voorkomt dat bezoekers moeten raden wat er veranderde.

Let ook op automatische processen. Sommige systemen werken de bijwerkdatum automatisch bij elke opslagactie bij, ook bij een onzichtbare technische wijziging. Test dat zelf: sla een pagina op zonder inhoud te wijzigen en kijk of de datum verschuift. Dat gedrag hangt van je systeem en je instellingen af en kan wijzigen.

Een datum kan op drie plekken verschillen: in wat de bezoeker ziet, in de broncode en in je sitemap. Vergelijk ze:

1. Open de pagina in een browser en noteer de zichtbare datum(s).
2. Bekijk de paginabron en zoek de datum in tekst of in gestructureerde gegevens als die op je site worden gebruikt. Controleer of dezelfde waarde terugkomt.
3. Check je sitemap als die een wijzigingsdatum bevat en vergelijk die met je logboek. Dit is een eigen consistentiecontrole; de gebruikte bronnen gaan hier niet op in.
4. Controleer pagina's die datums met JavaScript invullen. De pagina https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics beschrijft dat Google JavaScript in drie fasen verwerkt (crawlen, renderen, indexeren) en dat pagina's eerst in een wachtrij komen, waarbij niet direct duidelijk is wanneer renderen aan de beurt is. Wordt je datum alleen door JavaScript ingevuld, dan staat ze niet in de eerste HTML-respons en hangt het van het renderen af wanneer ze wordt gezien. Vergelijk daarom de ruwe broncode met de gerenderde pagina.
5. Zorg dat verschillende plekken niet elk een andere datum tonen.

Zo ontdek je welke datum werkelijk wordt getoond. Een tegenstrijdigheid tussen zichtbare tekst, broncode en sitemap is geen bewezen oorzaak van een rankingprobleem, maar wel een onnodige verwarring die je zelf kunt wegnemen.

Search Console toont hoe Google je site crawlt, indexeert en weergeeft. De pagina https://developers.google.com/search/docs/monitor-debug/search-console-start beschrijft onder meer de indexeringsrapportage, het prestatierapport en het indienen van een sitemap om ontdekking te ondersteunen. Gebruik dit als hulpmiddel om na een belangrijke herziening te controleren of de pagina nog wordt gecrawld en geïndexeerd. Hoe snel een wijziging in zoekresultaten verschijnt, kun je niet voorspellen. Exacte rapportnamen en schermen kunnen wijzigen; controleer ze in je eigen account.

Een tweede valkuil: dezelfde inhoud op meerdere URL's, bijvoorbeeld met parameters of een afdrukversie, met elk een andere datum. Google beschrijft op https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls dat redirects een sterk signaal zijn voor de canonieke URL, rel="canonical" ook een sterk signaal, en opname in een sitemap een zwak signaal. Het zijn signalen, geen opdrachten. Zorg dat de datum die je beheert op de URL staat die je als hoofdversie bedoelt. Welke URL Google daadwerkelijk koos, lees je af in de geïndexeerde URL-inspectiegegevens en niet in de live test.

Fictief voorbeeld. Een pagina met een stappenplan werd op 3 maart gepubliceerd. Op 20 september wordt stap 4 vervangen omdat een voorwaarde is gewijzigd, en op 21 september wordt een typfout verbeterd. Invoer: logboek met beide wijzigingen, zichtbare datum 'bijgewerkt 21 september', sitemapdatum 21 september. Verwachte controles: (1) de typfout rechtvaardigt geen nieuwe datum, dus de zichtbare datum hoort 20 september te zijn; (2) de wijzigingsnotitie noemt stap 4; (3) broncode en sitemap tonen dezelfde datum als de pagina; (4) de eerste publicatiedatum 3 maart blijft zichtbaar of ten minste in het logboek bewaard. Wat er daarna met zoekresultaten gebeurt, laat je open.

Voer na elke inhoudelijke wijziging deze korte controle uit:

1. Staat de wijziging in het logboek met een zin uitleg?
2. Komt de datum in de zichtbare tekst overeen met het logboek?
3. Komt dezelfde datum terug in broncode en sitemap, voor zover je die gebruikt?
4. Wijst de canonical of redirect naar de URL die je als hoofdversie bedoelt?
5. Controleer op een zelf gekozen moment later in Search Console of de pagina nog is geïndexeerd, zonder een bepaald resultaat of tempo te verwachten.

Wil je zien welke zichtbare signalen je pagina's publiek tonen, bekijk dan je site via Marketing Scan. Die scan meet zichtbare signalen en bewijst niet dat al deze controles in je systeem correct zijn uitgevoerd.