Los portales inmobiliarios de listados siguen el manual estándar de AEO. Tienen esquema FAQ en sus páginas de inicio. Tienen marcado LocalBusiness en su página principal. Han escrito contenido conversacional dirigido a consultas de cola larga. Y la mayoría de ellos aún no aparecen cuando alguien le pide a un motor de IA "apartamentos de 2 dormitorios cerca de la universidad en [ciudad]".
La razón es estructural, no cosmética. Las páginas de listados no son páginas de contenido. Las tácticas de AEO diseñadas para contenido editorial no se aplican al inventario de listados. Esta guía está escrita para operadores de plataformas de listados: portales inmobiliarios, sitios de alquileres vacacionales, mercados de apartamentos. No para agentes individuales. El desafío es diferente del problema de visibilidad de hoteles, pero la causa raíz es la misma capa de geodatos faltante.
Por qué el consejo estándar de AEO no funciona para páginas de listados
El consejo estándar de AEO se ve algo así: escribe contenido conversacional, agrega esquema FAQ, apunta a preguntas de cola larga, construye autoridad temática. Esto es correcto para contenido editorial como publicaciones de blog, guías y páginas de inicio. La guía completa de AEO para negocios locales cubre bien esas tácticas.
Las páginas de listados no están respondiendo preguntas a nivel de categoría. Están representando entidades específicas: un apartamento de tres dormitorios en una ubicación específica con atributos específicos, disponible a un precio específico. Los motores de IA recuperan entidades, no ensayos.
Cuando un usuario le pregunta a Perplexity "alquileres cerca de Parc de la Villette bajo 1500 euros", el IA está haciendo coincidencia de entidades geográficas. Está buscando entidades de listado con una ubicación confirmada dentro de un área geográfica resoluble, un precio dentro del rango indicado como un atributo estructurado, y relaciones legibles por máquina con el punto de referencia o barrio consultado.
Un bloque FAQ en tu página de listado no ayuda al IA a realizar esa coincidencia. Un esquema LocalBusiness en tu página principal no ayuda a recuperar un listado individual dos páginas en tu estructura de URL. La entidad que debe ser legible por máquina es la página de listado en sí.
Qué necesitan realmente los motores de IA de una página de listado
Un tipo de esquema específico. Schema.org tiene tipos diseñados para inventario de listados: RealEstateListing, Apartment, SingleFamilyResidence, House, LodgingBusiness, VacationRental. Usar LocalBusiness o Article genérico en páginas de listados las coloca en la categoría de entidad incorrecta para consultas inmobiliarias.
Precios y disponibilidad como datos estructurados. Una Offer anidada dentro del tipo de listado proporciona a los motores de IA los atributos de precio y disponibilidad estructurados necesarios para hacer coincidir listados con consultas que incluyen restricciones de precio. Un precio que aparece solo en el texto visible de la página no es un atributo consultable.
Geodatos. Esta es la capa que casi cada implementación está perdiendo, y se cubre completamente en la siguiente sección.
Las tres brechas de geodatos
Brecha 1: Sin coordenadas en la propia página de listado
GeoCoordinates precisas con latitude y longitude a por lo menos cuatro decimales deben aparecer en el propio JSON-LD de la página de listado. Las cadenas de dirección no son un sustituto. El error común es aplicar geo solo a un esquema LocalBusiness a nivel de sitio en la página principal. Las páginas de listados individuales necesitan sus propias coordenadas. Cada listado es una entidad geográfica distinta. Cómo implementar esto correctamente para cualquier tipo de listado se cubre en la guía de esquema JSON-LD.
Brecha 2: Sin relación containedInPlace
containedInPlace vincula el listado a las entidades de barrio, distrito y ciudad que lo contienen geográficamente. Esto hace que el listado sea recuperable para consultas a nivel de área, no solo a nivel de dirección.
Sin él, un listado existe en una dirección de calle en tu esquema pero no es miembro de ninguna entidad geográfica nombrada. Un motor de IA no puede recuperarlo para "apartamentos en [nombre del barrio]" porque no hay un enlace estructurado entre el listado y ese barrio.
"containedInPlace": {
"@type": "Place",
"name": "Prenzlauer Berg",
"containedInPlace": {
"@type": "City",
"name": "Berlin"
}
}
Brecha 3: Sin datos de Place cercano
Consultas como "apartamentos cerca de la estación S-Bahn" o "casas cerca de buenas escuelas" requieren que el listado tenga relaciones estructuradas con características geográficas cercanas. Una oración en tu descripción de propiedad no es suficiente. La misma información como una entidad Place estructurada vinculada a través de amenityFeature, con coordenadas para la parada de tránsito y un atributo de distancia, es consultable.
Por qué las bases de datos de listados no llevan estos datos
La mayoría de los sistemas de administración de propiedades y bases de datos de listados almacenan lo que los operadores ingresan: dirección, precio, dormitorios, fotos. Fueron construidos para humanos navegando un portal. Coordenadas, límites de barrio y datos de POI cercanos no son campos estándar, porque el software de listado nunca fue diseñado para proporcionar contexto geográfico legible por máquina a sistemas de recuperación de IA.
La forma de cerrar esta brecha a escala es a través de una API de mapeo. Las APIs de geocodificación convierten direcciones a coordenadas precisas. Las APIs de puntos de interés devuelven paradas de tránsito, escuelas, parques e hitos dentro de un radio especificado. Las APIs de límite de barrio resuelven qué entidades geográficas contienen una coordenada dada. La salida se mapea directamente a tipos de schema.org y se puede incrustar en JSON-LD de página de listado a través de un proceso de construcción o servidor a escala. Cómo el IA actualmente usa este tipo de datos para encontrar y evaluar sitios web explica el modelo de recuperación más amplio.
La estructura completa del esquema para una página de listado
{
"@context": "https://schema.org",
"@type": "Apartment",
"name": "Apartamento de 3 habitaciones, Prenzlauer Berg",
"description": "Apartamento de 3 habitaciones luminoso, 78 sqm, cocina renovada, balcón orientado al sur.",
"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, aproximadamente 4 minutos a pie"
},
{
"@type": "LocationFeatureSpecification",
"name": "Grundschule am Kollwitzplatz",
"value": true,
"description": "600m, aproximadamente 7 minutos a pie"
}
],
"offers": {
"@type": "Offer",
"price": 1450,
"priceCurrency": "EUR",
"availability": "https://schema.org/InStock"
}
}
Este listado ahora es una entidad geográfica resoluble. Puede ser recuperado para consultas por área, por proximidad, por restricción de precio y por número de habitaciones. Un listado sin la capa de geodatos solo puede recuperarse si el IA hace coincidir su cadena de dirección con la ubicación consultada, lo cual es poco confiable.
La diferencia entre AEO de agente y AEO de portal
Los agentes individuales que hacen trabajo de AEO están resolviendo un problema diferente: visibilidad de marca y contenido, guías de vecindarios, contenido FAQ. Los operadores de portal están resolviendo un problema de inventario a escala. Cada página de listado necesita sus propios geodatos incrustados a nivel de página. Eso requiere un flujo de datos sistemático, no una estrategia de contenido.
El 82% de los consumidores ahora usan herramientas de IA para investigación local e inmobiliaria. Solo el 1,2% de los negocios locales aparecen en recomendaciones de búsqueda de IA. Los portales que cierren esa brecha serán los que hayan tratado cada listado como una entidad de datos con contexto geográfico legible por máquina, no solo una página de contenido con una dirección de calle.
El verificador AEO de MapAtlas identifica exactamente qué señales de geodatos faltan en tus páginas de listado: coordenadas, containedInPlace, datos de POI cercanos. Audita contra las señales que los motores de IA pesan para consultas inmobiliarias, no solo los campos que una prueba estándar de resultados enriquecidos verifica.
Preguntas frecuentes
¿Por qué mis páginas de listados inmobiliarios no aparecen en la búsqueda con IA aunque tengan marcado schema?
La mayoría de las implementaciones de schema en páginas de listados incluyen el tipo de propiedad y el precio, pero omiten la capa de datos geo: coordenadas precisas, relaciones containedInPlace y entidades Place cercanas. Los motores de IA usan estas señales para relacionar los listados con consultas que dependen de la ubicación. Sin ellas, ni siquiera una página de listado con schema completo puede aparecer en consultas como «piso de 2 habitaciones cerca del metro».
¿Cuál es el tipo de schema correcto para una página de listado inmobiliario?
Usa RealEstateListing como tipo base, anidado con GeoCoordinates para las coordenadas precisas, PostalAddress para la dirección completa, containedInPlace para vincular la propiedad con las entidades de su barrio y su ciudad, y Offer para el precio y la disponibilidad. Evita usar solo LocalBusiness o un schema genérico de Article en las páginas de listados.
¿En qué se diferencia el AEO de un portal de listados del AEO de un agente inmobiliario?
El AEO de un agente se centra en páginas de marca y de contenido: schema de FAQ, contenido conversacional en el blog y autoridad temática en un mercado local. El AEO de un portal es un problema de inventario a escala: cada página de listado debe ser una entidad geográfica identificable en datos estructurados. Las tácticas que funcionan para las páginas de marca de un agente no sirven para el inventario de listados.
¿Puede una API de mapas ayudar a que mis páginas de listados aparezcan en la búsqueda con IA?
Sí. Las bases de datos de listados suelen guardar la dirección, el precio y los dormitorios, pero no las coordenadas, el transporte cercano ni los límites del barrio. Una API de mapas aporta todo eso en formatos que se corresponden directamente con schema.org, lo que te permite incluir la capa de datos geo en el JSON-LD de las páginas de listados a escala y sin entrada manual.
