부동산 매물 포털은 표준 AEO 플레이북을 충실히 따르고 있습니다. 랜딩 페이지에는 FAQ schema가 있고, 홈페이지에는 LocalBusiness 마크업이 있습니다. 롱테일 쿼리를 겨냥한 대화형 콘텐츠도 작성했습니다. 그런데도 누군가 AI 엔진에 "[도시] 대학교 근처 방 2개 아파트"를 물으면 대부분의 포털은 여전히 답변에 나타나지 않습니다.
원인은 겉모습이 아니라 구조에 있습니다. 매물 페이지는 콘텐츠 페이지가 아닙니다. 편집형 콘텐츠를 위해 만들어진 AEO 전술은 매물 인벤토리에 그대로 적용되지 않습니다. 이 가이드는 부동산 포털, 휴가용 숙소 사이트, 아파트 마켓플레이스 같은 매물 플랫폼 운영자를 위해 작성했습니다. 개별 중개인을 위한 글은 아닙니다. 호텔 가시성 문제와는 성격이 다르지만, 근본 원인은 똑같이 geo data 레이어의 부재입니다.
표준 AEO 조언이 매물 페이지에 통하지 않는 이유
표준 AEO 조언은 대체로 이렇습니다. 대화형 콘텐츠를 쓰고, FAQ schema를 추가하고, 롱테일 질문을 겨냥하고, 주제 권위를 쌓으라는 것입니다. 블로그 게시물, 가이드, 랜딩 페이지 같은 편집형 콘텐츠에는 맞는 조언입니다. 로컬 비즈니스를 위한 AEO 완벽 가이드에서 이 전술을 자세히 다룹니다.
매물 페이지는 카테고리 수준의 질문에 답하는 페이지가 아닙니다. 특정 엔티티를 나타냅니다. 특정 위치에 있고, 특정 속성을 갖추고, 특정 가격에 나온 방 3개 아파트 같은 것입니다. AI 엔진이 찾는 것은 에세이가 아니라 엔티티입니다.
사용자가 Perplexity에 "Parc de la Villette 근처 1500유로 이하 임대"를 물으면 AI는 지리적 엔티티 매칭을 수행합니다. 식별 가능한 지리적 영역 안에 위치가 확인된 매물, 구조화된 속성으로 표시된 가격이 요청 범위 안에 있는 매물, 질문에 나온 랜드마크나 동네와 기계가 읽을 수 있는 관계로 연결된 매물을 찾습니다.
매물 페이지의 FAQ 블록은 이 매칭에 도움이 되지 않습니다. 홈페이지의 LocalBusiness schema도 URL 구조에서 두 단계 아래에 있는 개별 매물을 찾는 데는 쓸모가 없습니다. 기계가 읽을 수 있어야 하는 엔티티는 매물 페이지 자체입니다.
AI 엔진이 매물 페이지에서 실제로 필요로 하는 것
구체적인 schema 유형. Schema.org에는 매물 인벤토리를 위한 유형이 따로 있습니다. RealEstateListing, Apartment, SingleFamilyResidence, House, LodgingBusiness, VacationRental입니다. 매물 페이지에 범용 LocalBusiness나 Article을 쓰면 부동산 쿼리 기준으로 잘못된 엔티티 카테고리에 분류됩니다.
구조화된 데이터로 표현한 가격과 공급 상태. 매물 유형 안에 Offer를 중첩하면 AI 엔진이 가격 조건이 들어간 쿼리와 매물을 매칭하는 데 필요한 가격 및 공급 상태 속성을 구조화된 형태로 얻습니다. 페이지의 보이는 텍스트에만 있는 가격은 쿼리할 수 있는 속성이 아닙니다.
Geo data. 거의 모든 구현에서 빠져 있는 레이어이며, 다음 섹션에서 자세히 다룹니다.
세 가지 geo data 공백
공백 1: 매물 페이지 자체에 좌표가 없음
소수점 네 자리 이상의 latitude와 longitude를 담은 정확한 GeoCoordinates가 매물 페이지 자체의 JSON-LD에 있어야 합니다. 주소 문자열로는 대신할 수 없습니다. 흔한 실수는 홈페이지의 사이트 단위 LocalBusiness schema에만 geo를 넣는 것입니다. 개별 매물 페이지마다 고유한 좌표가 필요합니다. 매물 하나하나가 별개의 지리적 엔티티이기 때문입니다. 매물 유형별로 이를 올바르게 구현하는 방법은 JSON-LD schema 가이드에서 다룹니다.
공백 2: containedInPlace 관계가 없음
containedInPlace는 매물을 지리적으로 포함하는 동네, 구, 도시 엔티티와 연결합니다. 이 속성이 있어야 매물이 주소 단위 쿼리뿐 아니라 지역 단위 쿼리에서도 검색됩니다.
이 속성이 없으면 매물은 schema상 특정 도로명 주소에만 존재할 뿐, 이름 있는 어떤 지리적 엔티티에도 속하지 않습니다. 매물과 동네 사이에 구조화된 연결이 없으므로 AI 엔진은 "[동네 이름]의 아파트" 같은 쿼리에서 이 매물을 찾아내지 못합니다.
"containedInPlace": {
"@type": "Place",
"name": "Prenzlauer Berg",
"containedInPlace": {
"@type": "City",
"name": "Berlin"
}
}
공백 3: 주변 장소 데이터가 없음
"S-Bahn 근처 원룸"이나 "좋은 학교와 가까운 주택" 같은 쿼리에 답하려면 매물이 주변 지리적 요소와 구조화된 관계를 가져야 합니다. 매물 설명에 문장 하나를 넣는 것으로는 부족합니다. 같은 정보를 amenityFeature로 연결된 구조화된 Place 엔티티로 표현하고, 역의 좌표와 거리 속성을 함께 넣어야 쿼리할 수 있습니다.
매물 데이터베이스에 이런 데이터가 없는 이유
대부분의 부동산 관리 시스템과 매물 데이터베이스는 운영자가 입력한 값, 즉 주소, 가격, 방 개수, 사진을 저장합니다. 사람이 포털을 둘러보는 용도로 만들어졌기 때문입니다. 좌표, 동네 경계, 주변 POI 데이터는 표준 필드가 아닙니다. 매물 소프트웨어는 AI 검색 시스템에 기계가 읽을 수 있는 지리적 맥락을 제공하도록 설계된 적이 없습니다.
이 공백을 대규모로 메우는 방법은 지도 API입니다. Geocoding API는 주소를 정확한 좌표로 변환합니다. POI API는 지정한 반경 안의 대중교통 정류장, 학교, 공원, 랜드마크를 반환합니다. 동네 경계 API는 특정 좌표를 포함하는 지리적 엔티티를 판별합니다. 이 결과는 schema.org 유형에 그대로 대응하므로, 빌드 시점이나 서버 측 처리 과정에서 매물 페이지 JSON-LD에 대규모로 삽입할 수 있습니다. AI가 현재 이런 데이터로 웹사이트를 찾고 평가하는 방식에서 더 넓은 검색 모델을 설명합니다.
매물 페이지를 위한 전체 schema 구조
{
"@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"
}
}
이제 이 매물은 식별 가능한 지리적 엔티티입니다. 지역, 근접성, 가격 조건, 방 개수 기준의 쿼리에서 모두 검색될 수 있습니다. geo 레이어가 없는 매물은 AI가 우연히 주소 문자열을 질문 속 위치와 매칭할 때만 검색되며, 이는 신뢰할 수 없는 방식입니다.
중개인 AEO와 포털 AEO의 차이
AEO에 힘쓰는 개별 중개인은 다른 문제를 풀고 있습니다. 브랜드와 콘텐츠 가시성, 동네 가이드, FAQ 콘텐츠입니다. 포털 운영자가 풀어야 하는 것은 대규모 인벤토리 문제입니다. 매물 페이지마다 페이지 단위로 고유한 geo data가 들어가야 합니다. 여기에 필요한 것은 콘텐츠 전략이 아니라 체계적인 데이터 파이프라인입니다.
소비자의 82%가 이제 지역 및 부동산 정보를 찾을 때 AI 도구를 사용합니다. AI 검색 추천에 나타나는 로컬 비즈니스는 1.2%에 불과합니다. 이 격차를 좁히는 포털은 매물을 도로명 주소가 적힌 콘텐츠 페이지가 아니라, 기계가 읽을 수 있는 지리적 맥락을 갖춘 데이터 엔티티로 다룬 곳일 것입니다.
MapAtlas AEO Checker는 매물 페이지에 빠진 geo 신호, 즉 좌표, containedInPlace, 주변 POI 데이터를 정확히 짚어냅니다. 표준 리치 결과 테스트가 확인하는 필드만이 아니라, AI 엔진이 부동산 쿼리에서 중요하게 보는 신호를 기준으로 감사합니다.
자주 묻는 질문
schema 마크업을 넣었는데도 부동산 매물 페이지가 AI 검색에 나타나지 않는 이유는 무엇인가요?
대부분의 매물 페이지 schema 구현에는 매물 유형과 가격은 들어가지만 geo data 레이어가 빠져 있습니다. 정밀한 좌표, containedInPlace 관계, 주변 Place 엔티티가 그것입니다. AI 엔진은 이런 신호로 매물을 위치 기반 쿼리와 매칭합니다. 이 신호가 없으면 schema를 완전히 적용한 매물 페이지라도 '지하철역 근처 방 2개' 같은 쿼리에서 검색되지 않습니다.
부동산 매물 페이지에 맞는 schema 타입은 무엇인가요?
RealEstateListing을 기본 타입으로 쓰고, 정밀한 좌표는 GeoCoordinates, 전체 주소는 PostalAddress, 매물과 동네 및 도시 엔티티의 연결은 containedInPlace, 가격과 거래 가능 여부는 Offer로 중첩하세요. 매물 페이지에 LocalBusiness나 범용 Article schema만 쓰는 것은 피하세요.
매물 포털의 AEO는 부동산 중개인의 AEO와 어떻게 다른가요?
중개인 AEO는 브랜드와 콘텐츠 페이지에 집중합니다. FAQ schema, 대화형 블로그 콘텐츠, 지역 시장에서의 주제 권위가 핵심입니다. 포털 AEO는 대규모 인벤토리의 문제입니다. 모든 매물 페이지가 구조화 데이터 안에서 식별 가능한 지리 엔티티여야 합니다. 중개인 브랜드 페이지에 통하는 전략은 매물 인벤토리에 그대로 적용되지 않습니다.
지도 API가 매물 페이지의 AI 검색 노출에 도움이 되나요?
네. 매물 데이터베이스에는 보통 주소, 가격, 침실 수는 있지만 좌표, 주변 대중교통, 동네 경계는 없습니다. 지도 API는 이 데이터를 schema.org에 바로 대응하는 형식으로 제공하므로, 수작업 입력 없이 대규모로 매물 페이지 JSON-LD에 geo data 레이어를 넣을 수 있습니다.
