AI-citatiefactoren: de drie lagen (domein, schema

De meeste gidsen over AI-zoekranking behandelen twee lagen: domain authority en schema markup. Die gidsen hebben gelijk, maar zijn onvolledig op een manier die specifiek vermeldingspagina's, vastgoedportals, vakantieverhuurplatforms en elke site met locatiegebonden inventaris treft.

De derde laag is geo data. Het is de minst gedocumenteerde, de meest ontbrekende, en de laag die bepaalt of uw pagina's locatiespecifieke zoekopdrachten überhaupt kunnen beantwoorden. Begrijpen wat AEO werkelijk betekent is het startpunt, maar deze gids gaat dieper in op de structurele factoren die bepalen of individuele pagina's worden geciteerd.

Laag 1: Domein- en entiteitsautoriteit

Domain authority is de toelatingsvereiste, niet het rankingsignaal. Beschouw het als een drempel. Pagina's van domeinen onder ruwweg DA 20 tot 30 verschijnen zelden in AI-citatiegroepen voor competitieve zoekopdrachten, ongeacht de inhoudskwaliteit. Boven die drempel heeft ruw DA een afnemende correlatie met citatiefrequentie.

Wat het als primair signaal heeft vervangen boven de DA-drempel is entiteitsautoriteit: hoe duidelijk en consistent AI-modellen begrijpen wat uw site is, wat het behandelt en wie het bedient.

Consistente entiteitsidentiteit over het web. Uw organisatienaam, adres, URL en categorie moeten identiek verschijnen op uw eigen siteschema, Google Business Profile, branchedirectories en citatiesbronnen. NAP-inconsistentie fragmenteert uw entiteitsidentiteit direct over meerdere zwakke representaties in plaats van één sterke.

Thematische coherentie. AI-modellen beoordelen of uw site een duidelijk, consistent onderwerpcluster heeft. Een site met 30 artikelen in één smalle niche is entiteitsauthoritatief in die niche dan een site met hetzelfde DA verspreid over 20 niet-gerelateerde onderwerpen.

sameAs-verwijzingen. De sameAs-eigenschap in uw JSON-LD koppelt uw entiteit aan haar representaties op Wikidata, Crunchbase, LinkedIn en andere gezaghebbende grafen. AI-modellen gebruiken deze om te bevestigen dat de entiteit die ze redeneren dezelfde is als beschreven in meerdere bronnen. De volledige LocalBusiness JSON-LD-implementatiegids behandelt hoe dit correct te structureren.

Als uw domein de DA-drempel haalt, leveren verbeteringen van entiteitsautoriteit meer op voor AI-citatie dan extra linkbuilding.

Laag 2: Schema Markup

Schema markup is de communicatielaag tussen uw pagina's en AI-retrievalsystemen. Pagina's met gestructureerde data worden significant vaker geciteerd dan pagina's zonder schema. Google AI Overviews geven de voorkeur aan pagina's met gestructureerde data, en de selectiewinst is materieel voor competitieve zoekopdrachten.

De meeste implementaties stoppen bij de velden die voldoen aan de Rich Results Test van Google, wat niet hetzelfde is als voldoen aan AI-citatiesystemen.

Wat de meeste implementaties goed doen: @type, name, description, url, openingHours, telephone, address, FAQ-schema.

Wat de meeste implementaties missen voor vermeldingspagina's: De schematypes die zijn ontworpen voor vermeldingsinventaris vereisen andere eigenschappen dan de types die de meeste gidsen bespreken.

Voor vastgoed-, vakantieverhuur- en hospitalityvermeldingspagina's zijn de relevante types RealEstateListing, LodgingBusiness, Hotel, VacationRental, Apartment en SingleFamilyResidence, elk genest met Offer voor prijzen en beschikbaarheid. Deze types vervullen hun functie voor AI-retrieval alleen wanneer ze gecombineerd worden met de juiste locatie-eigenschappen.

De FAQ-schemafout

FAQ-schema is waardevol voor redactionele content. Het vertelt AI-engines precies welke vraag een stuk content beantwoordt. Vermeldingspagina's zijn geen redactionele content. Een vastgoedvermelding beantwoordt geen algemene vraag over vakantieverhuur. Het vertegenwoordigt een specifieke entiteit op een specifieke locatie. FAQ-schema helpt een AI-engine niet die vermelding te koppelen aan "2-slaapkamerappartement bij de metro." Het juiste schema voor vermeldingspagina's is entiteitsrelationeel, niet Q&A-vormig.

Laag 3: Geo Data (de onderdocumenteerde laag)

AI-modellen die locatiespecifieke zoekopdrachten beantwoorden ("vakantieverhuur bij Yellowstone", "appartementen binnen 10 minuten van het centrum") doen impliciete geospatiale matching. Ze lossen geografische relaties op tussen de opgevraagde locatie en de entiteiten in hun retrievalgroep. Om die matching te laten werken, moeten uw vermeldingspagina's die relaties expliciet coderen in gestructureerde data.

Precieze GeoCoordinates op elke vermeldingspagina

De GeoCoordinates geo-eigenschap met latitude en longitude tot ten minste vier decimalen is het fundamentele signaal. Zonder dit geocoderen AI-engines uw adresstring, wat mislukt bij elke inconsistentie en veel lagere precisie oplevert. De meeste implementaties die geo überhaupt bevatten, passen dit alleen toe op een sitebreed LocalBusiness-schema, niet op individuele vermeldingspagina's. Elke vermeldingspagina moet zijn eigen oplosbare geografische entiteit zijn.

"geo": {
  "@type": "GeoCoordinates",
  "latitude": 48.8566,
  "longitude": 2.3522
}

containedInPlace: De eigenschap koppelen aan een geografische hiërarchie

De containedInPlace-eigenschap koppelt uw vermelding aan de buurt-, wijk-, stad- en regioentiteiten die het bevatten. Zo beantwoorden AI-engines zoekopdrachten als "appartementen in de Marais" in plaats van alleen "appartementen op [straatadres]." Zonder dit bestaat een eigenschap als een adres maar niet als lid van een geografische entiteit.

"containedInPlace": {
  "@type": "Place",
  "name": "Le Marais",
  "containedInPlace": {
    "@type": "City",
    "name": "Paris"
  }
}

Nabijgelegen Place-entiteiten: OV, scholen, bezienswaardigheden

Wanneer een gebruiker vraagt naar "verhuur bij de metro", zoekt de AI naar expliciete machine-leesbare relaties tussen de eigenschap en de OV-infrastructuur. Een zin in uw beschrijving die zegt "5 minuten lopen naar Metrolijn 4" doet niets voor AI-retrieval. Dezelfde informatie gestructureerd als een Place-entiteit gekoppeld via amenityFeature is opvraagbaar.

Waarom vermeldingsdatabases deze data niet van nature bevatten

De meeste vastgoedbeheer- en vermeldingsdatabases slaan op wat operators invoeren: adres, prijs, slaapkamers, badkamers, foto's. Ze zijn gebouwd voor mensen die door een portal bladeren, niet voor machine-leesbare geografische context. Een kaart-API vult dit gat. Geocoding-API's converteren adressen naar precieze coördinaten. Points-of-interest API's retourneren OV-haltes, scholen, parken en bezienswaardigheden binnen een bepaalde straal. De uitvoer komt direct overeen met schema.org-types en kan worden ingebed in vermeldingspagina-JSON-LD op schaal.

Hoe het sluiten van alle drie de hiaten eruitziet

Een vermeldingspagina die goed presteert in AI-retrieval:

1. Staat op een domein met consistente entiteitsidentiteit, sameAs-verwijzingen en een duidelijk thematisch cluster
2. Gebruikt het meest specifieke toepasselijke schematype genest met Offer voor prijzen
3. Bevat GeoCoordinates op de vermeldingspagina zelf, containedInPlace die het koppelt aan buurt- en stadsentiteiten, en gestructureerde nabijgelegen Place-data voor OV, scholen en bezienswaardigheden

De meeste vermeldingspagina's dekken delen van Laag 1 en de basisonderdelen van Laag 2. Vrijwel geen enkele dekt Laag 3. De pagina's die alle drie dekken zijn de pagina's die verschijnen in AI-antwoorden op locatiespecifieke zoekopdrachten.

Slechts 1,2% van de lokale bedrijven verschijnt momenteel in AI-zoekaanbevelingen. Ze zijn gemiddeld niet degenen met de hoogste domain authority. Het zijn degenen die alle drie de hiaten hebben gesloten.