Immobilienportale halten sich an das übliche AEO-Playbook. Ihre Landingpages tragen FAQ-Schema. Ihre Startseite hat LocalBusiness-Markup. Sie haben dialogorientierte Inhalte für Long-Tail-Anfragen geschrieben. Trotzdem tauchen die meisten nicht auf, wenn jemand eine KI-Engine nach „Wohnungen mit zwei Schlafzimmern nahe der Universität in [Stadt]“ fragt.
Der Grund ist struktureller Natur, nicht kosmetischer. Inseratseiten sind keine Inhaltsseiten. AEO-Taktiken, die für redaktionelle Inhalte entwickelt wurden, greifen bei einem Inseratsbestand nicht. Dieser Leitfaden richtet sich an Betreiber von Inseratsplattformen: Immobilienportale, Portale für Ferienunterkünfte und Wohnungsmarktplätze. Einzelne Makler sind nicht die Zielgruppe. Die Herausforderung unterscheidet sich vom Sichtbarkeitsproblem von Hotels, die eigentliche Ursache ist aber dieselbe: Es fehlt die Geodaten-Ebene.
Warum die üblichen AEO-Ratschläge bei Inseratseiten nicht greifen
Die üblichen AEO-Ratschläge lauten ungefähr so: dialogorientierte Inhalte schreiben, FAQ-Schema ergänzen, Long-Tail-Fragen adressieren, thematische Autorität aufbauen. Für redaktionelle Inhalte wie Blogartikel, Leitfäden und Landingpages ist das richtig. Der vollständige AEO-Leitfaden für lokale Unternehmen behandelt diese Taktiken ausführlich.
Inseratseiten beantworten keine Fragen auf Kategorieebene. Sie bilden konkrete Entitäten ab: eine Wohnung mit drei Schlafzimmern an einem bestimmten Ort, mit bestimmten Merkmalen und zu einem bestimmten Preis verfügbar. KI-Engines rufen Entitäten ab, keine Aufsätze.
Fragt ein Nutzer Perplexity nach „Mietwohnungen nahe dem Parc de la Villette unter 1.500 Euro“, führt die KI einen geografischen Entitätsabgleich durch. Sie sucht nach Inseratsentitäten mit einem bestätigten Standort innerhalb eines auflösbaren geografischen Gebiets, mit einem Preis im genannten Rahmen als strukturiertem Attribut und mit maschinenlesbaren Beziehungen zum angefragten Orientierungspunkt oder Stadtviertel.
Ein FAQ-Block auf Ihrer Inseratseite hilft der KI bei diesem Abgleich nicht. Ein LocalBusiness-Schema auf Ihrer Startseite hilft ihr nicht, ein einzelnes Inserat zwei Ebenen tief in Ihrer URL-Struktur zu finden. Maschinenlesbar sein muss die Entität selbst, also die Inseratseite.
Was KI-Engines von einer Inseratseite tatsächlich brauchen
Einen spezifischen Schema-Typ. Schema.org bietet Typen, die für Inseratsbestände gedacht sind: RealEstateListing, Apartment, SingleFamilyResidence, House, LodgingBusiness, VacationRental. Wer auf Inseratseiten das generische LocalBusiness oder Article verwendet, ordnet sie für Immobilienanfragen der falschen Entitätskategorie zu.
Preis und Verfügbarkeit als strukturierte Daten. Ein Offer, verschachtelt im Inseratstyp, liefert KI-Engines die strukturierten Attribute für Preis und Verfügbarkeit. Diese brauchen sie, um Inserate mit Anfragen abzugleichen, die eine Preisgrenze enthalten. Ein Preis, der nur im sichtbaren Text der Seite steht, ist kein abfragbares Attribut.
Geodaten. Diese Ebene fehlt in fast jeder Implementierung. Der nächste Abschnitt behandelt sie im Detail.
Die drei Lücken bei den Geodaten
Lücke 1: Keine Koordinaten auf der Inseratseite selbst
Präzise GeoCoordinates mit latitude und longitude auf mindestens vier Nachkommastellen müssen im JSON-LD der Inseratseite selbst stehen. Adressangaben als Text sind kein Ersatz. Der typische Fehler: geo steht nur in einem seitenweiten LocalBusiness-Schema auf der Startseite. Einzelne Inseratseiten brauchen eigene Koordinaten, denn jedes Inserat ist eine eigenständige geografische Entität. Wie Sie das für jeden Inseratstyp korrekt umsetzen, zeigt der Leitfaden zum JSON-LD-Schema.
Lücke 2: Keine containedInPlace-Beziehung
containedInPlace verknüpft das Inserat mit den Entitäten für Stadtviertel, Bezirk und Stadt, in denen es geografisch liegt. Dadurch lässt sich das Inserat auch bei Anfragen auf Gebietsebene finden, nicht nur bei Anfragen nach einer Adresse.
Ohne diese Beziehung existiert das Inserat in Ihrem Schema zwar unter einer Straßenadresse, gehört aber zu keiner benannten geografischen Entität. Eine KI-Engine kann es für „Wohnungen in [Name des Viertels]“ nicht finden, weil keine strukturierte Verbindung zwischen dem Inserat und diesem Viertel besteht.
"containedInPlace": {
"@type": "Place",
"name": "Prenzlauer Berg",
"containedInPlace": {
"@type": "City",
"name": "Berlin"
}
}
Lücke 3: Keine Daten zu Orten in der Umgebung
Anfragen wie „Wohnungen nahe der S-Bahn“ oder „Häuser in der Nähe guter Schulen“ setzen voraus, dass das Inserat strukturierte Beziehungen zu geografischen Merkmalen in der Umgebung hat. Ein Satz in der Objektbeschreibung genügt nicht. Abfragbar wird dieselbe Information erst als strukturierte Place-Entität, verknüpft über amenityFeature, mit Koordinaten der Haltestelle und einer Entfernungsangabe.
Warum Inseratsdatenbanken diese Daten nicht enthalten
Die meisten Immobilienverwaltungssysteme und Inseratsdatenbanken speichern, was Betreiber eingeben: Adresse, Preis, Zimmerzahl, Fotos. Gebaut wurden sie für Menschen, die ein Portal durchsuchen. Koordinaten, Grenzen von Stadtvierteln und POI-Daten aus der Umgebung sind keine Standardfelder, weil Inseratssoftware nie dafür entworfen wurde, KI-Retrieval-Systemen maschinenlesbaren geografischen Kontext zu liefern.
Skaliert schließen lässt sich diese Lücke über eine Mapping-API. Geocoding-APIs wandeln Adressen in präzise Koordinaten um. POI-APIs liefern Haltestellen, Schulen, Parks und Sehenswürdigkeiten in einem festgelegten Radius. APIs für Viertelgrenzen ermitteln, in welchen geografischen Entitäten eine bestimmte Koordinate liegt. Die Ausgabe lässt sich direkt auf schema.org-Typen abbilden und über einen Build-Schritt oder serverseitig in großem Umfang in das JSON-LD der Inseratseiten einbetten. Wie KI diese Art von Daten heute nutzt, um Websites zu finden und zu bewerten, erklärt das übergeordnete Retrieval-Modell.
Die vollständige Schema-Struktur für eine Inseratseite
{
"@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"
}
}
Dieses Inserat ist jetzt eine auflösbare geografische Entität. Es lässt sich bei Anfragen nach Gebiet, Nähe, Preisgrenze und Zimmerzahl finden. Ein Inserat ohne die Geodaten-Ebene wird nur gefunden, wenn die KI seine Adresse als Text zufällig dem angefragten Ort zuordnet, und das ist unzuverlässig.
Der Unterschied zwischen AEO für Makler und AEO für Portale
Einzelne Makler, die AEO betreiben, lösen ein anderes Problem: die Sichtbarkeit ihrer Marke und ihrer Inhalte, Viertel-Guides, FAQ-Inhalte. Portalbetreiber lösen ein Skalierungsproblem über ihren gesamten Bestand. Jede Inseratseite braucht eigene, auf Seitenebene eingebettete Geodaten. Dafür ist eine systematische Datenpipeline nötig, keine Content-Strategie.
82 % der Verbraucher nutzen heute KI-Tools für die Recherche zu lokalen Angeboten und Immobilien. Nur 1,2 % der lokalen Unternehmen erscheinen in Empfehlungen der KI-Suche. Schließen werden diese Lücke die Portale, die jedes Inserat als Datenentität mit maschinenlesbarem geografischem Kontext behandeln und nicht nur als Inhaltsseite mit einer Straßenadresse.
Der MapAtlas AEO Checker zeigt genau, welche Geosignale Ihren Inseratseiten fehlen: Koordinaten, containedInPlace, POI-Daten aus der Umgebung. Er prüft die Signale, die KI-Engines bei Immobilienanfragen gewichten, und nicht nur die Felder, die ein üblicher Rich-Results-Test abfragt.
Häufig gestellte Fragen
Warum erscheinen meine Immobilien-Inseratseiten trotz Schema-Markup nicht in der KI-Suche?
Die meisten Schema-Implementierungen auf Inseratseiten enthalten Objekttyp und Preis, lassen aber die Geodaten-Ebene weg: präzise Koordinaten, containedInPlace-Beziehungen und Place-Entitäten in der Umgebung. KI-Engines nutzen diese Signale, um Inserate mit standortbezogenen Anfragen abzugleichen. Ohne sie kann selbst eine vollständig ausgezeichnete Inseratseite nicht für Anfragen wie „Wohnung mit zwei Schlafzimmern nahe der U-Bahn“ gefunden werden.
Welcher Schema-Typ ist für eine Immobilien-Inseratseite richtig?
Verwenden Sie RealEstateListing als Basistyp, verschachtelt mit GeoCoordinates für präzise Koordinaten, PostalAddress für die vollständige Adresse, containedInPlace zur Verknüpfung des Objekts mit den Entitäten für Stadtviertel und Stadt sowie Offer für Preis und Verfügbarkeit. Verwenden Sie auf Inseratseiten nicht nur LocalBusiness oder ein generisches Article-Schema.
Worin unterscheidet sich AEO für ein Immobilienportal von AEO für einen Makler?
AEO für Makler konzentriert sich auf Marken- und Inhaltsseiten: FAQ-Schema, konversationelle Blog-Inhalte und thematische Autorität in einem lokalen Markt. AEO für Portale ist ein Skalierungsproblem über den gesamten Bestand. Jede Inseratseite muss in den strukturierten Daten eine auflösbare geografische Entität sein. Taktiken, die für Markenseiten von Maklern funktionieren, lassen sich nicht auf Inseratsbestände übertragen.
Kann eine Mapping-API dafür sorgen, dass meine Inseratseiten in der KI-Suche erscheinen?
Ja. Inseratsdatenbanken speichern meist Adresse, Preis und Zimmerzahl, aber keine Geokoordinaten, keine ÖPNV-Anbindung in der Nähe und keine Grenzen von Stadtvierteln. Eine Mapping-API liefert all das in Formaten, die sich direkt auf schema.org abbilden lassen. So betten Sie die Geodaten-Ebene skaliert und ohne manuelle Eingabe in das JSON-LD Ihrer Inseratseiten ein.
