Immobilienportale folgen dem standard-aeo-playbook. Sie haben faq-schema auf ihren landing pages. Sie haben LocalBusiness markup auf ihrer homepage. Sie haben konversationalen inhalt geschrieben, der lange-tail-abfragen zielt. Und die meisten von ihnen erscheinen trotzdem nicht, wenn jemand ein ki-engine fragt fuer '2-schlafzimmer wohnungen nah bei der universitaet in [stadt]'.
Der grund ist strukturell, nicht kosmetisch. Inseratseiten sind keine inhalt-seiten. Die aeo-taktiken, entworfen fuer editorial-inhalt, gelten nicht fuer einlage-inventar. Dieser leitfaden ist geschrieben fuer betreiber von einlage-plattformen: immobilienportale, ferienmieterseiten, wohnungsmaerkte. Nicht fuer einzelne agenten. Die herausforderung unterscheidet sich von dem hotel-sichtbarkeitsproblem, aber die grundlegende ursache ist die gleiche fehlende geo-datenschicht.
Warum Standard-AEO-Rat nicht fuer Einlage-Seiten funktioniert
Der standard-aeo-rat laeuft ungefaehr so: schreiben Sie konversationalen inhalt, fuegen Sie faq-schema hinzu, ziele lange-tail-fragen, erstellen Sie topische autoritaet. Dies ist korrekt fuer editorial-inhalt wie blog-beitrag, leitfaden und landing pages. Der komplette aeo-leitfaden fuer lokale unternehmen behandelt diese taktiken gut.
Einlage-seiten beantworten keine kategorien-ebenen-fragen. Sie repraesentieren spezifische einheiten: eine drei-schlafzimmer-wohnung an einem spezifischen ort mit spezifischen attributen, verfuegbar zu einem spezifischen preis. Ki-engines rufen einheiten ab, nicht essays.
Wenn ein benutzer Perplexity fragt 'mietungen nah bei parc de la villette unter 1500 euro', fuehrt die ki geografische einheit-matching durch. Sie sucht nach einlaga-einheiten mit einem bestaettigten standort innerhalb eines aufloesten geografischen gebietes, ein preis innerhalb der angegebenen spanne als strukturiertes attribut, und maschinen-lesbare beziehungen zu dem abfragten landmark oder nachbarschaft.
Ein faq-block auf Ihrer einlage-seite hilft nicht der ki, diese match auszufuehren. Ein LocalBusiness schema auf Ihrer homepage hilft es nicht, eine einzelne einlage zwei seiten tief in Ihrer url-struktur abzurufen. Die einheit, die maschinen-lesbar sein muss, ist die einlaga-seite selbst.
Was KI-Engines wirklich von einer Einlaga-Seite benoetigt
Ein spezifischer schema-typ. Schema.org hat typen, entworfen fuer einlage-inventar: RealEstateListing, Apartment, SingleFamilyResidence, House, LodgingBusiness, VacationRental. Generisch LocalBusiness oder Article zu verwenden auf einlaga-seiten setzt sie in die falschen einheiten-kategorie fuer immobilien-abfragen.
Preisgestaltung und verfuegbarkeit als strukturierte daten. Ein Offer verschachtelt in dem einlaga-typ gibt ki-engines die strukturierten preis- und verfuegbarkeits-attributen, benoetigt, um einlagen gegen abfragen, die preiseinschraenkungen einbeziehen, zu entsprechen. Ein preis, der nur in dem sichtbaren text der seite angezeigt wird, ist kein abfragefahiges attribut.
Geodaten. Dies ist die schicht, die fast alle implementierungen vermissen, und es wird im naechsten abschnitt vollstaendig behandelt.
Die drei Geo-Daten-Luecken
Luecke 1: Keine Koordinaten auf der Einlaga-Seite selbst
Praezise GeoCoordinates mit latitude und longitude zu mindestens vier dezimalstellen muessen in dem json-ld der einlaga-seite selbst angezeigt werden. Adresszeichenketten sind kein ersetzer. Der haeufige fehler ist das anwenden geo nur auf einem seiten-ebenen LocalBusiness schema auf der homepage. Individuelle einlaga-seiten benoetigen ihre eigenen koordinaten. Jede einlage ist eine unterschiedliche geografische einheit. Wie zu implementieren dies korrekt fuer jeden einlaga-typ ist in dem json-ld-schema-leitfaden behandelt.
Luecke 2: Keine containedInPlace-Beziehung
containedInPlace verknuepft die einlage zu dem nachbarschaft, distrikt und stadt einheiten, die sie geografisch enthalten. Dies macht die einlage fuer gebiet-ebenen-abfragen abrufbar, nicht nur adress-ebenen-abfragen.
Ohne es, eine einlage existiert auf einer strasse adresse in Ihrem schema, aber ist nicht ein mitglied von jeder benannten geografischen einheit. Eine ki-engine kann es fuer 'wohnungen in [nachbarschaft-name]' nicht abrufen, weil es keine strukturierte link zwischen dem einlage und dieser nachbarschaft gibt.
"containedInPlace": {
"@type": "Place",
"name": "Prenzlauer Berg",
"containedInPlace": {
"@type": "City",
"name": "Berlin"
}
}
Luecke 3: Keine Nearby Place Data
Abfragen wie 'flats nah bei der S-Bahn' oder 'haeuser nah bei guten schulen' erfordern das einlage strukturierte beziehungen zu nearby geografischen funktionen zu haben. Ein satz in Ihrer eigenschaeft-beschreibung ist nicht ausreichend. Die gleiche informationen wie eine strukturierte Place einheit verknuepft via amenityFeature, mit koordinaten fuer die transit-stop und ein entfernungs-attribut, ist abfragefahig.
Warum Einlage-Datenbanken diese Daten nicht trugen
Die meisten vermoegens-verwaltungs-systeme und einlage-datenbanken speichern was betreiber eingeben: adresse, preis, schlafzimmer, fotos. Sie wurden fuer menschen, die durch ein portal blaettern, gebaut. Koordinaten, nachbarschaft-grenzen und nearby poi-daten sind nicht standard-felder, weil einlage-software wurde nie entworfen, um maschinen-lesbare geografische kontexte zu ki-abruf-systemen zu liefern.
Der weg zu dieser luecke im massstab zu schliessen, durch eine zuordnung api ist. Geocoding apis konvertieren adressen zu praezisen koordinaten. Points-of-interest apis geben transit-stops, schulen, parks und landmarks innerhalb einer angegebenen radius zurueck. Nachbarschaft-grenzen apis loesung welche geografische einheiten eine gegebene koordinate enthalten. Die ausgabe mapt direkt zu schema.org-typen und kann in einlage-seite json-ld durch ein build-zeit oder server-seite verarbeitung im massstab eingebettet werden. Wie ki derzeit diese art von daten nutzt, um websites zu finden und zu evaluieren erklaert das breiter abruf-modell.
Die vollstaendige Schema-Struktur fuer eine Einlaga-Seite
{
"@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"
}
}
Diese einlage ist nun eine aufloesbare geografische einheit. Sie kann fuer abfragen durch gebiet, durch naehe, durch preis-einschraenkung und durch zimmer-zahl abgerufen werden. Eine einlage ohne die geo-schicht kann nur abgerufen werden, wenn die ki zufaellig ihre adresszeichenkette zur abfragten standort abgleicht, was unzuverlaessig ist.
Der Unterschied zwischen Agent AEO und Portal AEO
Einzelne agenten, die aeo-arbeit durchfuehren, loesen ein unterschiedliches problem: marke und inhalts-sichtbarkeit, nachbarschaft-leitfaeden, faq-inhalte. Portal-betreiber loesen ein inventar-im-massstab-problem. Jede einlaga-seite benoetigt ihre eigenen geo-daten, die auf der seiten-ebene eingebettet sind. Dies erfordert eine systematische daten-pipeline, nicht inhalts-strategie.
82 % der verbraucher nutzen jetzt ki-tools fuer lokale und immobilien-recherche. Nur 1,2 % der lokalen unternehmen erscheinen in ki-suchempfehlungen. Die portale, die diese luecke schliessen, werden diejenigen sein, die jede einlage als eine daten-einheit mit maschinen-lesbarem geografischen kontext behandelt haben, nicht nur eine inhalts-seite mit einer strasse adresse.
Das MapAtlas AEO Checker identifiziert genau welche geo-signale Ihre einlaga-seiten vermissen: koordinaten, containedInPlace, nearby poi-daten. Es prueft gegen die signale, die ki-engines fuer immobilien-abfragen wiegen, nicht nur die felder ein standard-reiche-ergebnis test prueft.
