Vastgoed listing-pagina's in AI-zoeken: waarom ze verstopt blijven

Vastgoedportalen volgen het standaard AEO-playbook. Ze hebben FAQ-schema op hun landingspagina's. Ze hebben LocalBusiness-markup op hun homepage. Ze hebben conversationele content geschreven die zich op long-tail zoekvragen richt. En toch verschijnen de meeste niet wanneer iemand een AI-engine vraagt naar "appartementen met 2 slaapkamers bij de universiteit in [stad]."

De reden is structureel, niet cosmetisch. Listingpagina's zijn geen contentpagina's. De AEO-tactieken voor redactionele content zijn niet van toepassing op aanbod. Deze gids is geschreven voor exploitanten van listingplatforms: vastgoedportalen, sites voor vakantieverhuur en marktplaatsen voor huurwoningen. Niet voor individuele makelaars. De uitdaging verschilt van het zichtbaarheidsprobleem van hotels, maar de onderliggende oorzaak is dezelfde ontbrekende geodatalaag.

Waarom standaard AEO-advies niet werkt voor listingpagina's

Het standaard AEO-advies gaat ongeveer zo: schrijf conversationele content, voeg FAQ-schema toe, richt je op long-tail vragen en bouw topical authority op. Dat klopt voor redactionele content zoals blogposts, gidsen en landingspagina's. De complete AEO-gids voor lokale bedrijven behandelt die tactieken goed.

Listingpagina's beantwoorden geen vragen op categorieniveau. Ze vertegenwoordigen specifieke entiteiten: een appartement met drie slaapkamers op een specifieke locatie, met specifieke kenmerken, beschikbaar voor een specifieke prijs. AI-engines halen entiteiten op, geen essays.

Vraagt een gebruiker Perplexity naar "huurwoningen bij Parc de la Villette onder 1500 euro", dan doet de AI aan geografische entity matching. Hij zoekt listing-entiteiten met een bevestigde locatie binnen een herleidbaar geografisch gebied, een prijs binnen het genoemde bereik als gestructureerd kenmerk en machineleesbare relaties met het genoemde herkenningspunt of de genoemde buurt.

Een FAQ-blok op je listingpagina helpt de AI niet bij die match. Een LocalBusiness-schema op je homepage helpt hem niet om een losse listing twee niveaus diep in je URL-structuur op te halen. De entiteit die machineleesbaar moet zijn, is de listingpagina zelf.

Wat AI-engines echt nodig hebben van een listingpagina

Een specifiek schematype. Schema.org heeft types die speciaal voor aanbod zijn ontworpen: RealEstateListing, Apartment, SingleFamilyResidence, House, LodgingBusiness, VacationRental. Gebruik je generieke LocalBusiness of Article op listingpagina's, dan vallen ze bij vastgoedvragen in de verkeerde entiteitscategorie.

Prijs en beschikbaarheid als gestructureerde data. Een Offer genest in het listingtype geeft AI-engines de gestructureerde prijs- en beschikbaarheidskenmerken die nodig zijn om listings te matchen met zoekvragen die een prijsgrens bevatten. Een prijs die alleen in de zichtbare tekst van de pagina staat, is geen doorzoekbaar kenmerk.

Geodata. Dit is de laag die bijna elke implementatie mist. De volgende sectie behandelt die volledig.

De drie gaten in geodata

Gat 1: geen coördinaten op de listingpagina zelf

Precieze GeoCoordinates met latitude en longitude tot minstens vier decimalen moeten in de eigen JSON-LD van de listingpagina staan. Adresstrings zijn geen vervanging. De veelgemaakte fout is geo alleen toepassen op een LocalBusiness-schema op siteniveau, op de homepage. Individuele listingpagina's hebben hun eigen coördinaten nodig. Elke listing is een aparte geografische entiteit. Hoe je dit voor elk listingtype correct implementeert, lees je in de gids over JSON-LD-schema.

Gat 2: geen containedInPlace-relatie

containedInPlace koppelt de listing aan de buurt-, wijk- en stadsentiteiten waarin die geografisch ligt. Daardoor is de listing vindbaar voor zoekvragen op gebiedsniveau, niet alleen op adresniveau.

Zonder die relatie bestaat een listing in je schema op een straatadres, maar hoort hij bij geen enkele benoemde geografische entiteit. Een AI-engine kan hem dan niet ophalen voor "appartementen in [naam van de buurt]", omdat er geen gestructureerde koppeling is tussen de listing en die buurt.

"containedInPlace": {
  "@type": "Place",
  "name": "Prenzlauer Berg",
  "containedInPlace": {
    "@type": "City",
    "name": "Berlin"
  }
}

Gat 3: geen data over plaatsen in de buurt

Zoekvragen als "appartementen bij de S-Bahn" of "huizen dicht bij goede scholen" vereisen dat de listing gestructureerde relaties heeft met geografische kenmerken in de buurt. Een zin in je woningomschrijving is niet genoeg. Dezelfde informatie als gestructureerde Place-entiteit, gekoppeld via amenityFeature, met coördinaten voor de halte en een afstandskenmerk, is wel doorzoekbaar.

Waarom listingdatabases deze data niet bevatten

De meeste vastgoedbeheersystemen en listingdatabases slaan op wat exploitanten invoeren: adres, prijs, slaapkamers, foto's. Ze zijn gebouwd voor mensen die door een portal bladeren. Coördinaten, buurtgrenzen en data over POI's in de buurt zijn geen standaardvelden, omdat listingsoftware nooit is ontworpen om AI-retrievalsystemen machineleesbare geografische context te leveren.

Dit gat dicht je op schaal met een mapping-API. Geocoding-API's zetten adressen om in precieze coördinaten. Points-of-interest-API's geven haltes, scholen, parken en herkenningspunten binnen een opgegeven straal terug. API's voor buurtgrenzen bepalen welke geografische entiteiten een bepaalde coördinaat bevatten. De output sluit direct aan op schema.org-types en kan via een proces bij de build of op de server op schaal in de JSON-LD van listingpagina's worden opgenomen. Hoe AI dit soort data nu gebruikt om websites te vinden en te beoordelen legt het bredere retrievalmodel uit.

De volledige schemastructuur voor een listingpagina

{
  "@context": "https://schema.org",
  "@type": "Apartment",
  "name": "3-room apartment, Prenzlauer Berg",
  "description": "Bright 3-room apartment, 78 sqm, renovated kitchen, south-facing balcony.",
  "numberOfRooms": 3,
  "floorSize": { "@type": "QuantitativeValue", "value": 78, "unitCode": "MTK" },
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Kastanienallee 42",
    "addressLocality": "Berlin",
    "postalCode": "10435",
    "addressCountry": "DE"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 52.5384,
    "longitude": 13.4132
  },
  "containedInPlace": {
    "@type": "Place",
    "name": "Prenzlauer Berg",
    "containedInPlace": { "@type": "City", "name": "Berlin" }
  },
  "amenityFeature": [
    {
      "@type": "LocationFeatureSpecification",
      "name": "S-Bahn Prenzlauer Allee",
      "value": true,
      "description": "350m, approximately 4 minutes walk"
    },
    {
      "@type": "LocationFeatureSpecification",
      "name": "Grundschule am Kollwitzplatz",
      "value": true,
      "description": "600m, approximately 7 minutes walk"
    }
  ],
  "offers": {
    "@type": "Offer",
    "price": 1450,
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock"
  }
}

Deze listing is nu een herleidbare geografische entiteit. Hij kan worden opgehaald voor zoekvragen op gebied, nabijheid, prijsgrens en aantal kamers. Een listing zonder geolaag wordt alleen opgehaald als de AI toevallig de adresstring aan de gezochte locatie koppelt, en dat is onbetrouwbaar.

Het verschil tussen AEO voor makelaars en AEO voor portals

Individuele makelaars die aan AEO werken, lossen een ander probleem op: zichtbaarheid van merk en content, buurtgidsen, FAQ-content. Exploitanten van portals hebben een probleem van aanbod op schaal. Elke listingpagina heeft eigen geodata nodig, ingebed op paginaniveau. Dat vraagt een systematische datapipeline, geen contentstrategie.

82% van de consumenten gebruikt nu AI-tools voor lokaal onderzoek en woningonderzoek. Slechts 1,2% van de lokale bedrijven verschijnt in aanbevelingen van AI-zoekmachines. De portals die dat gat dichten, zijn de portals die elke listing behandelen als data-entiteit met machineleesbare geografische context, niet alleen als contentpagina met een straatadres.