Vorige week kreeg ik van een klant de vraag: "We hebben een schemas.ts bestand in onze codebase staan, maar niemand weet meer waarom die er is of wat elk blok doet." Dat is geen uitzondering. Bij zeker de helft van de projecten die ik onder ogen krijg, staat er ergens een verdwaald JSON-LD bestand dat ooit door een developer is neergezet — zonder documentatie, zonder duidelijk doel, en vaak zonder dat iemand nog weet of het klopt.
Dat is zonde, want structured data is precies het soort informatie waar AI-systemen als ChatGPT, Perplexity en Google's AI Overviews naar hongeren. Het is machine-leesbare context die zegt: "dit is wie we zijn, dit is waar we zitten, dit zijn de antwoorden op veelgestelde vragen." Zonder die context moet een taalmodel gokken op basis van ongestructureerde tekst. Mét die context krijgt het een directe, betrouwbare bron.
In dit artikel leg ik de drie meest gebruikte schema-types uit — Organization, LocalBusiness en FAQPage — met concrete voorbeelden die je vandaag kunt implementeren.
Waarom structured data er nog steeds toe doet in het AI-tijdperk
Structured data (JSON-LD, meestal) bestaat al sinds 2011 dankzij schema.org, opgezet door Google, Bing, Yahoo en Yandex samen. Het doel was toen simpel: zoekmachines helpen content te begrijpen zodat ze rijke resultaten konden tonen — sterretjesreviews, openingstijden, FAQ-uitklappers in de zoekresultaten.
Wat er veranderd is: de "lezer" van je structured data is niet meer alleen een crawler die indexeert voor een resultatenlijst. Het is nu ook een taalmodel dat je content parseert om een antwoord te formuleren voor een gebruiker die niet eens op jouw site komt. Als iemand aan ChatGPT vraagt "welke bedrijven in Utrecht doen AI-consultancy", dan is de kans dat jouw JSON-LD wordt meegenomen in het antwoord vele malen groter dan de kans dat een stuk marketingtekst wordt geïnterpreteerd.
Dat komt doordat structured data ondubbelzinnig is. Een stuk tekst als "Wij zitten in het hart van Utrecht" moet een model interpreteren en aannames doen. Een PostalAddress-object met addressLocality: "Utrecht" heeft geen interpretatie nodig — het is een feit dat direct te extraheren is.
Voor de bredere strategie achter dit soort optimalisatie raad ik aan om ook wat GEO precies inhoudt door te lezen — structured data is namelijk één puzzelstukje van een groter geheel.
De drie schema-types die je bijna altijd nodig hebt
Organization: wie ben je, echt?
Het Organization-schema is de basis. Het beantwoordt de vraag die AI-systemen het vaakst niet kunnen beantwoorden: wat is dit bedrijf, en waarom zou ik het vertrouwen? Dit schema hoort thuis op je homepage, en idealiter herhaal je het (of verwijs je ernaar) op elke pagina via je layout.
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "WeArkMedia",
"url": "https://wearkmedia.nl",
"logo": "https://wearkmedia.nl/logo.png",
"description": "AI-native webontwikkeling en GEO/AEO-optimalisatie voor bedrijven die gevonden willen worden door ChatGPT, Perplexity en Google AI Overviews.",
"sameAs": [
"https://www.linkedin.com/company/wearkmedia",
"https://twitter.com/wearkmedia"
],
"contactPoint": {
"@type": "ContactPoint",
"email": "hallo@wearkmedia.nl",
"contactType": "customer service"
}
}
Wat hier belangrijk is: sameAs is geen decoratie. Dit veld koppelt je bedrijf aan externe, verifieerbare bronnen — je LinkedIn, je Wikipedia-pagina (als die bestaat), je Crunchbase-profiel. AI-modellen gebruiken dit soort kruisverwijzingen om te bepalen of een entiteit "echt" is. Een Organization-schema zonder sameAs is als een LinkedIn-profiel zonder connecties: technisch geldig, maar weinig overtuigend.
De description moet je niet kopiëren uit je meta-description. Schrijf een zin die specifiek is over wat je doet en voor wie — niet "wij zijn een toonaangevend bureau", maar concreet: wat, voor wie, waarom anders.
LocalBusiness: cruciaal als je fysiek vindbaar moet zijn
Als je een fysieke locatie hebt — een kantoor, winkel, praktijk — dan is LocalBusiness (of een specifiekere subtype zoals ProfessionalService, Restaurant, Store) essentieel. Dit schema is de directe reden waarom AI-assistenten "in de buurt"-vragen kunnen beantwoorden.
{
"@context": "https://schema.org",
"@type": "ProfessionalService",
"name": "WeArkMedia",
"image": "https://wearkmedia.nl/kantoor.jpg",
"address": {
"@type": "PostalAddress",
"streetAddress": "Vredenburg 40",
"addressLocality": "Utrecht",
"postalCode": "3511 BD",
"addressCountry": "NL"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 52.0907,
"longitude": 5.1214
},
"telephone": "+31-30-1234567",
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
"opens": "09:00",
"closes": "17:30"
}
],
"priceRange": "€€€"
}
Twee dingen die vaak fout gaan. Ten eerste: mensen vergeten geo-coördinaten, terwijl dit precies is wat systemen gebruiken om afstand te berekenen bij "dichtstbijzijnde" queries. Ten tweede: het @type is vaak te generiek. Gebruik niet standaard LocalBusiness als er een specifieker subtype bestaat — Google en AI-systemen kunnen met een specifiek type (zoals Dentist, Accountant, MarketingAgency waar beschikbaar) veel gerichter matchen op intentie.
Dit is precies het onderwerp dat ik uitgebreider behandel in GEO voor lokale bedrijven — daar ga ik ook in op hoe je met meerdere vestigingen omgaat.
FAQPage: de meest onderschatte schema voor AEO
Als er één schema-type is dat direct invloed heeft op of je wordt geciteerd in een AI-antwoord, is het FAQPage. Waarom? Omdat het letterlijk de structuur van vraag-antwoord aanlevert die een taalmodel nodig heeft om jouw content te hergebruiken in zijn eigen antwoord — vaak woord voor woord.
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Wat kost een AI-native website?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Een AI-native website begint doorgaans bij €4.500 voor een MKB-bedrijf, afhankelijk van de complexiteit van content en integraties. Grotere projecten met meertalige content of maatwerk-functionaliteit lopen op tot €15.000-€25.000."
}
},
{
"@type": "Question",
"name": "Werkt structured data ook zonder een technisch team?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Ja. De meeste CMS-systemen en frameworks ondersteunen JSON-LD via plugins of eenvoudige code-snippets. Je hebt geen dedicated developer nodig om Organization- of FAQPage-schema te implementeren."
}
}
]
}
De valkuil hier is dat mensen FAQPage-schema invullen met marketingvragen ("Waarom kiezen voor ons?") in plaats van vragen die mensen daadwerkelijk stellen aan een zoekmachine of AI-assistent. Kijk naar de "People Also Ask"-sectie in Google, of test zelf in ChatGPT en Perplexity welke vragen rond jouw onderwerp opkomen. Schrijf antwoorden die op zichzelf staan — een antwoord moet begrijpelijk zijn zonder de vraag opnieuw te lezen, want dat is precies hoe een taalmodel het eruit knipt.
Ik heb dit uitgebreider uitgewerkt in de praktische AEO-gids, inclusief hoe je bepaalt welke vragen de moeite waard zijn om te beantwoorden.
Van los bestand naar werkend systeem: praktische implementatie
Waar plaats je dit in je codebase?
Als je al een lib/schemas.ts hebt (of iets vergelijkbaars), is de logische structuur: exporteer functies die JSON-LD objecten genereren op basis van je content, niet statische strings. Zoiets:
// lib/schemas.ts
export function generateOrganizationSchema() {
return {
"@context": "https://schema.org",
"@type": "Organization",
name: "WeArkMedia",
url: "https://wearkmedia.nl",
// ...
};
}
export function generateFAQSchema(faqs: { question: string; answer: string }[]) {
return {
"@context": "https://schema.org",
"@type": "FAQPage",
mainEntity: faqs.map((faq) => ({
"@type": "Question",
name: faq.question,
acceptedAnswer: {
"@type": "Answer",
text: faq.answer,
},
})),
};
}
Dit voorkomt dat je schema's los van je content raken — een veelvoorkomend probleem waarbij de FAQ-tekst op de pagina wordt aangepast, maar het schema erachter niet meegroeit. Inconsistentie tussen zichtbare content en schema-data is precies wat je niet wilt: het ondermijnt vertrouwen bij zowel Google als AI-crawlers.
Test en valideer voordat je live gaat
Gebruik Google's Rich Results Test en Schema.org's eigen validator voordat je iets publiceert. Een veelgemaakte fout is een tikfout in @type (bijvoorbeeld Organisation met Britse spelling in plaats van Organization) — het schema faalt dan stil, zonder foutmelding op je site, en je komt er pas achter als je afvraagt waarom niets werkt.
Vergeet ook niet te checken of je robots.txt geen AI-crawlers blokkeert die deze data juist zouden moeten lezen — zie de handleiding voor robots.txt en AI-crawlers als je twijfelt of jouw configuratie klopt.
Veelgestelde vragen
Moet ik alle drie de schema-types gebruiken, of kan ik kiezen?
Dat hangt af van je bedrijfstype. Organization hoort bij vrijwel elke website thuis. LocalBusiness is essentieel als je een fysieke locatie hebt waar klanten langskomen. FAQPage is waardevol zodra je content hebt die vraag-antwoord beantwoordt — wat bij de meeste bedrijven wel het geval is.
Zorgt structured data direct voor hogere posities in Google?
Niet direct — Google gebruikt schema vooral voor rich results, niet als directe rankingfactor. Het indirecte effect is wel groot: betere klikratio's door rich snippets, en een grotere kans dat AI-systemen jouw data correct interpreteren en citeren, wat weer verkeer en zichtbaarheid oplevert.
Kan ik meerdere schema-types combineren op één pagina?
Ja, dat is zelfs aan te raden. Een homepage kan prima Organization, LocalBusiness én WebSite-schema tegelijk bevatten, mits je ze correct nest of als losse <script type="application/ld+json"> blokken plaatst. Zorg wel dat de informatie onderling consistent is — dezelfde naam, hetzelfde adres overal.
Hoe vaak moet ik mijn schema data bijwerken?
Elke keer dat de onderliggende feiten veranderen: nieuw adres, nieuwe openingstijden, nieuwe FAQ's op de pagina. Behandel schema-data niet als een eenmalige technische taak, maar als onderdeel van je content-onderhoud — net zoals je een verouderde prijs op je pagina zou aanpassen.