Het restaurant stond in Rotterdam, maar de machineleesbare data wees naar Haaksbergen

Tijdens een onderzoek naar de AI-zichtbaarheid van 22 restaurants in Rotterdam viel Ninety Rotterdam op. Niet alleen omdat het merk in de onderzochte aanbevelingsvragen beperkt zichtbaar was, maar vooral omdat verschillende openbare bronnen niet hetzelfde verhaal vertelden over de vestiging.

De zichtbare tekst op de website verwees naar het restaurant aan de G.H. Betzweg 445, 3068 AZ Rotterdam. Ook de gevonden lokale bedrijfsvermelding hoorde bij Ninety Rotterdam. Maar in een machineleesbaar LocalBusiness-gegevensblok op de Rotterdamse website stonden de naam, het adres, het telefoonnummer en de coördinaten van Ninety Haaksbergen.

De technische controle van dat moment zag wél dat structured data aanwezig was en gaf daarvoor een positieve aanwezigheidsscore. Hij controleerde nog niet systematisch of de waarden in dat gegevensblok overeenkwamen met de zichtbare pagina en de onderzochte vestiging. Daardoor werd een belangrijk bronverschil pas tijdens handmatige verdieping zichtbaar.

De onderzoeksvraag

De casus leidde tot een fundamentelere vraag dan “heeft deze website structured data?”:

Klopt wat een website machineleesbaar over een organisatie of vestiging vertelt met de andere beschikbare bronnen, en is duidelijk welke entiteit het gegevensblok vertegenwoordigt?

Die vraag is relevant omdat zoekmachines en AI-systemen niet alleen de tekst lezen die bezoekers op een pagina zien. Ze kunnen ook gebruikmaken van machineleesbare gegevens om namen, adressen, telefoonnummers, websites en relaties tussen organisaties en vestigingen te begrijpen.

Onderzoekscontext

De ontdekking kwam voort uit een handmatige benchmark met de vraag “Waar kan ik goed sushi eten in Rotterdam?” Die vraag werd in de consumenteninterfaces van ChatGPT, Claude, Gemini, DeepSeek en Grok gesteld. Per model werd geregistreerd welke van 22 onderzochte restaurantmerken werden genoemd.

Deze handmatige benchmark stond los van de automatische AIVisiScan-score. Het onderzoek was bedoeld om te toetsen in hoeverre die score aansloot bij de zichtbaarheid van restaurantmerken tijdens afzonderlijke handmatige zoekopdrachten in vijf consumenteninterfaces. De vermeldingen zijn nooit rechtstreeks als scoreonderdeel gebruikt. De vergelijking bracht duidelijke afwijkingen aan het licht en maakte zichtbaar waar de scanmethodiek verder moest worden verbeterd. Onderzoeksnotitie 003 beschrijft deze validatiestudie en de bewijsgrenzen ervan.

Ninety bleek later bovendien geen klassiek sushirestaurant te zijn, maar positioneert zich als een breder all-you-can-eat- en shared-diningconcept. Dat is relevante context bij de interpretatie van een sushi-vraag.

Op 18 juli 2026 werd de website van Ninety Rotterdam aanvullend onderzocht. Daarbij zijn de zichtbare pagina-informatie, machineleesbare websitegegevens en de gevonden lokale bedrijfsvermelding naast elkaar gelegd.

Wat de bronnen lieten zien

De bronnen verschilden op meerdere met elkaar samenhangende velden:

Het machineleesbare blok bevatte daarnaast een lege @id en de waarde * voor priceRange. Die velden waren technisch aanwezig, maar hielpen niet om de vestiging eenduidig en betekenisvol te identificeren.

Waarom “verkeerde vestiging” te snel kan zijn

De eerste formulering van de bevinding was stevig: de Rotterdamse website toont de verkeerde vestiging aan AI. De bronwaarden maakten de mismatch aantoonbaar, maar niet automatisch de organisatorische bedoeling erachter.

Ninety heeft meerdere vestigingen. Een ander adres kan bijvoorbeeld een centrale, administratieve of organisatorische functie hebben. Alleen uit de publieke code konden we niet vaststellen of Haaksbergen bewust in de Rotterdamse website was opgenomen, door een gedeeld sjabloon was meegekomen of simpelweg nog niet was aangepast.

Daarom is de preciezere conclusie:

De zichtbare en machineleesbare vestigingsgegevens verwezen niet volledig naar dezelfde locatie, terwijl uit het gegevensblok niet duidelijk werd waarom een andere vestiging werd beschreven.

Voor het onderzochte restaurant was de correctierichting wel duidelijk: wanneer het LocalBusiness- of Restaurant-blok de Rotterdamse vestiging hoort te beschrijven, moeten naam, adres, telefoon, coördinaten en unieke identificatie gezamenlijk naar Rotterdam verwijzen. Als Haaksbergen een geldige andere bedrijfsfunctie vertegenwoordigt, hoort die functie als een afzonderlijke, duidelijk gelabelde entiteit te worden gemodelleerd.

Waarom aanwezigheid alleen niet genoeg is

De technische audit controleerde destijds vooral of bepaalde voorzieningen aanwezig waren: was er schema.org-markering, een sitemap, een canonical-adres, toegankelijke pagina-inhoud en ruimte voor AI-crawlers? Dat is nuttig, maar het beantwoordt alleen de vraag of het technische huiswerk zichtbaar is gemaakt.

De Ninety-casus liet zien dat een positieve aanwezigheidstest en inhoudelijke juistheid twee verschillende dingen zijn. Een website kan technisch geldige structured data aanbieden die verouderd, onvolledig, generiek of op een andere entiteit gericht is. Een groen vinkje voor aanwezigheid mag daarom niet worden gelezen als bevestiging dat alle waarden kloppen.

De bruikbare controle bestaat uit minstens twee assen:

1. Consistentie: komen naam, adres, plaats, telefoon en website voldoende overeen tussen machineleesbare gegevens, zichtbare tekst en een betrouwbaar gekoppeld lokaal profiel?
2. Volledigheid en kwaliteit: bevatten de velden betekenisvolle waarden, een unieke identificatie en voldoende context om de entiteit te onderscheiden?

Het mogelijke effect op AI-zichtbaarheid

Het is aannemelijk dat tegenstrijdige locatiegegevens verwarring kunnen veroorzaken bij systemen die bronnen proberen te koppelen. Een Rotterdams restaurant dat in een relevant gegevensblok met een Haaksbergse naam, adres, telefoon en coördinaten wordt beschreven, geeft geen eenduidig lokaal signaal.

Maar deze casus bewijst niet dat de mismatch de gemeten lage zichtbaarheid van Ninety heeft veroorzaakt. De handmatige vraag ging over sushi, terwijl het restaurant een breder concept voert. Merkbekendheid, externe vermeldingen, bronselectie, vraagformulering, modelkennis en actuele zoekresultaten kunnen eveneens invloed hebben. Er is geen gecontroleerde voor- en nameting uitgevoerd waarin alleen het vestigingsblok werd gewijzigd.

De juiste formulering is daarom: het bronverschil was een concreet en potentieel schadelijk inconsistentiesignaal. Het maakte een verbeterpunt zichtbaar, maar leverde geen causaal bewijs voor een specifieke positie of score.

Wat deze casus wel en niet bewijst

Wat aantoonbaar was

• De zichtbare Rotterdamse pagina en het onderzochte machineleesbare blok verwezen naar verschillende vestigingen.
• De verschillen betroffen meerdere samenhangende velden: naam, adres, plaats, telefoon en coördinaten.
• De toenmalige automatische controle registreerde aanwezigheid van structured data, maar signaleerde dit inhoudelijke verschil niet.
• De mismatch kon deterministisch worden vastgesteld door exacte bronwaarden naast elkaar te leggen.

Wat niet was vastgesteld

• Welke organisatorische functie het Haaksbergse gegevensblok volgens Ninety moest vervullen.
• Of een specifiek AI-antwoord dit blok daadwerkelijk had gebruikt.
• Hoe groot het effect op aanbevelingen of lokale vindbaarheid was.
• Dat structured data op zichzelf de zichtbaarheidsscore bepaalt.

Van handmatige ontdekking naar productverbetering

De casus werd de aanleiding voor de Consistentie- & Volledigheidsmotor binnen AIVisiScan. Die motor vergelijkt beschikbare bronwaarden in plaats van alleen voorzieningen af te vinken. Naam, straat en huisnummer, postcode, plaats en website-adres worden per bron geëxtraheerd, genormaliseerd en onderling vergeleken.

De uitkomst maakt twee zaken afzonderlijk zichtbaar:

• Vergelijkingsstatus: komen waarden overeen, wijken ze af, ontbreken ze of bevatten ze een placeholder?
• Oplossingsstatus: is de correctie voldoende onderbouwd, of is eerst bevestiging van de organisatie nodig?

Geen enkele bron geldt automatisch als de waarheid, ook een lokaal bedrijfsprofiel niet. Het rapport bewaart daarom de exacte waarden en laat zien waar ze zijn aangetroffen. Bij machineleesbare websitegegevens kan de technische rapportage de onderzochte pagina, het gegevensblok en het veldpad tonen, zodat een webdeveloper gericht kan controleren waar de output vandaan komt.

Deze controle heeft bewust geen automatische score-impact. Eerst moet duidelijk zijn hoe vaak zulke verschillen voorkomen, hoe betrouwbaar ze kunnen worden beoordeeld en welke gevallen legitieme multivestigingsconstructies zijn.

Praktische les voor organisaties met meerdere vestigingen

Controleer per vestigingswebsite niet alleen wat bezoekers zien, maar ook wat in de broncode als organisatie of locatie wordt beschreven. Leg minimaal naam, adres, postcode, plaats, telefoon, website, coördinaten en unieke identificatie naast het lokale bedrijfsprofiel en de zichtbare contactpagina.

Wanneer een centrale organisatie en meerdere bezoeklocaties bestaan, modelleer die rollen afzonderlijk. Eén LocalBusiness-blok met gemengde gegevens uit verschillende vestigingen maakt de relatie niet duidelijker. Zorg dat ieder vestigingsobject een eigen stabiele identificatie heeft en dat relaties met de overkoepelende organisatie expliciet zijn.

De belangrijkste les is eenvoudig: controleer niet alleen of machineleesbare informatie bestaat, maar ook welke werkelijkheid die informatie beschrijft.

Bronnen en methode

• Gerichte website- en broncontrole van Ninety Rotterdam, uitgevoerd op 18 juli 2026.
• Vastgelegde zichtbare pagina-informatie en het aangetroffen LocalBusiness-gegevensblok.
• Lokale bedrijfsinformatie die tijdens het onderzoek bij Ninety Rotterdam werd gekoppeld.
• Handmatige Rotterdamse restaurantbenchmark met één identieke consumentenvraag in vijf AI-apps; uitsluitend gebruikt als onderzoekscontext, niet als onderdeel van de AIVisiScan-score.
• Ontwerp- en regressiedocumentatie van de later gebouwde Consistentie- & Volledigheidsmotor.