Google's Rich Results Test Displays No More Than 102 Objects for One JSON-LD Entity and Accepts an Invalid eventStatus Value

Stel je een bibliotheek voor waar elk boek niet alleen wordt beschreven door de titel en auteur, maar ook door een gedetailleerde kaart van de inhoud, de verbindingen met andere boeken en de specifieke feiten die het bevat. Dit is hoe moderne zoekmachines het web begrijpen. In plaats van alleen woorden op een pagina te lezen, zoeken ze naar een speciale vorm van code die verborgen zit in de structuur van de site. Deze code, geschreven in een formaat genaamd JSON-LD, fungeert als een gestructureerde kaart van de informatie op die pagina. Het vertelt de zoekmachine precies wie de site beheert, welke onderwerpen deze behandelt en hoe verschillende stukken informatie met elkaar verband houden. Voor website-eigenaren is dit een krachtig hulpmiddel. Door deze duidelijke, georganiseerde feiten te verstrekken, hopen zij dat hun pagina's verschijnen in zoekresultaten met rijkere details, zoals sterrenratings, evenementdata of directe antwoorden op vragen, waardoor het gemakkelijker wordt voor mensen om te vinden wat ze nodig hebben.

Er bestaat echter een kloof tussen wat website-eigenaren aanleveren en wat de tools die worden gebruikt om die informatie te controleren daadwerkelijk laten zien. Een recente studie door Brian R. Hatten, een orthopedisch chirurg en oprichter van een educatieve website voor patiënten met knievervanging, heeft twee stille fouten blootgelegd in Google's primaire testtool, de Rich Results Test. Deze tool is ontworpen om webmasters hun code te laten plakken en te zien hoe Google deze zal interpreteren. Hatten ontdekte dat de tool een verborgen plafond heeft: deze toont slechts de eerste 102 stukken informatie voor één persoon of organisatie, waarbij alles wat daarna komt stilzwijgend wordt genegeerd. Bovendien slaagt de tool er niet in bepaalde soorten fouten te detecteren, omdat het ongeldige gegevens accepteert die geweigerd hadden moeten worden. Deze bevindingen zijn van belang omdat ze betekenen dat een website-eigenaar een groen vinkje van goedkeuring kan ontvangen van de tool, in de veronderstelling dat hun gegevens perfect en compleet zijn, terwijl in werkelijkheid een aanzienlijk deel van hun informatie verborgen blijft voor het oog of technisch incorrect is.

Het verhaal van deze ontdekking begon bij Hatten's eigen website, My Knee Guide. In 2026 besloot hij een uitgebreide gestructureerde datakaart voor zijn site te bouwen om zoekmachines en kunstmatige intelligentiesystemen te helpen zijn werk en zijn kwalificaties te begrijpen. Hij creëerde een digitaal profiel, bekend als een "Physician" entiteit, die zijn carrière, zijn affiliaties, de artikelen die hij schreef en de evenementen die hij doceerde, beschreef. Naarmate hij meer details toevoegde, groeide dit profiel uit tot een lijst van 121 afzonderlijke stukken informatie. Toen hij dit profiel door de Google Rich Results Test haalde om te zien hoe het zou verschijnen, gaf de tool hem een schoon, geldig resultaat. Maar toen Hatten de output van de tool vergeleken met zijn originele bestand, realiseerde hij zich dat er iets ontbrak. De tool had precies 102 items weergegeven en stopte daarna. Het had de laatste 19 stukken informatie die hij had toegevoegd, niet getoond.

Wat deze ontdekking bijzonder lastig maakte, was dat de tool geen waarschuwing gaf. Er verscheen geen foutmelding of een rood licht om aan te geven dat er gegevens waren afgekapt. Het overzichtsscherm toonde een groen vinkje, wat suggereerde dat alles in orde was. Hatten moest de tekst van zijn originele bestand handmatig vergelijken met de tekst die de tool weergaf om te beseffen dat het laatste deel van zijn profiel simpelweg verdwenen was uit het overzicht. Hij voerde een reeks tests uit om dit gedrag te bevestigen. Hij maakte bestanden met variërende aantallen items en stelde vast dat de tool consequent alleen de eerste 102 items toonde wanneer een entiteit de 102 items overschreed. Het maakte niet uit of de items kort of lang waren; de limiet was gebaseerd op het aantal items, niet op de hoeveelheid tekst. Nog verbazingwekkender was dat de tool deze limiet blijkbaar toepaste op elke persoon of organisatie afzonderlijk. Als een pagina twee verschillende organisaties bevatte, toonde de tool de eerste 102 items voor de eerste organisatie en de eerste 102 voor de tweede, in plaats van te stoppen na 102 items in totaal voor de hele pagina.

Hatten ontdekte ook dat de tool niet altijd de kwaliteit van de getoonde informatie controleerde. In zijn profiel nam hij een evenement op dat al was afgerond en markeerde de status als "EventCompleted". Volgens de officiële regels voor dit type data zijn de geldige opties voor de status van een evenement specifieke termen zoals "EventScheduled" of "EventCancelled", maar "EventCompleted" staat niet op die lijst. Toen Hatten zijn bestand door Google's tool liet lopen, gaf de tool hem een groen vinkje en accepteerde de ongeldige term zonder klacht. Echter, toen hij exact hetzelfde bestand door een andere, onafhankelijke validator liet lopen, signaleerde die tool de fout correct en wees de term af. Dit betekende dat de website van Hatten maandenlang een stukje data bevatte dat technisch gezien incorrect was, terwijl de primaire tool die webmasters gebruiken om hun werk te verifiëren, hem vertelde dat het perfect was.

De implicaties van deze bevindingen zijn aanzienlijk voor iedereen die probeert zijn digitale aanwezigheid te beheren. De Rich Results Test is de standaardmanier voor website-eigenaren om te verifiëren of hun gestructureerde data correct werkt. Als de tool informatie stilzwijgend weglaat of ongeldige waarden accepteert, worden eigenaren achtergelaten met een vals gevoel van veiligheid. Ze kunnen denken dat hun rich results zoals bedoeld zullen verschijnen, om er vervolgens achter te komen dat zoekmachines cruciale details missen of dat de gegevens die zij hebben verstrekt niet voldoen aan de strikte normen die vereist zijn voor indexering. Hatten's studie suggereert dat de tool geen volledige controle is. Het kan valideren dat een bestand leesbaar is, maar het kan niet garanderen dat het volledige bestand wordt weergegeven of dat elke waarde correct is volgens de officiële definities.

Om deze verborgen beperkingen te navigeren, adviseert Hatten een meer voorzichtige aanpak. Website-eigenaren moeten niet uitsluitend vertrouwen op de groene vinkjes van de Rich Results Test. In plaats daarvan moeten ze handmatig het aantal items in hun data tellen om ervoor te zorgen dat ze onder de drempel van 102 items voor een enkele entiteit blijven. Ze moeten ook hun bestanden controleren met onafhankelijke validators om fouten te vangen die de tool van Google mogelijk mist. Misschien nog belangrijker is dat ze de tool moeten behandelen als een steekproef in plaats van een volledig rapport. Als een item niet wordt getoond in de preview van de tool, betekent dit niet noodzakelijkerwijs dat de zoekmachine het heeft genegeerd, maar het betekent wel dat de eigenaar niet zeker weet wat er wordt gezien. De studie concludeert dat totdat Google zijn tools bijwerkt om deze limieten en fouten duidelijk te rapporteren, de verantwoordelijkheid bij de websitebouwer ligt om hun eigen gegevens tegen meerdere bronnen te verifiëren, om ervoor te zorgen dat de digitale kaart die ze maken zowel compleet als accuraat is.