Citeon
로그인무료 진단
업종 심화

지역 비즈니스의 로컬 AI 검색 공략

김태오
김태오 · 그로스·퍼포먼스 리드

AI 검색 엔진이 "강남구 치과 추천"처럼 위치 의도를 포함한 쿼리를 처리할 때, 내부적으로는 세 가지 데이터 계층을 병합한다: (1) 크롤러가 수집한 웹 페이지의 구조화 데이터(JSON-LD·Microdata), (2) Google Business Profile(GBP)·네이버 플레이스·카카오맵 같은 플랫폼의 반구조화 프로필 데이터, (3) 리뷰·블로그·커뮤니티의 비구조화 텍스트 인용. Google AI Overviews는 세 계층을 모두 참조하지만, ChatGPT Search·Perplexity는 GBP에 직접 접근하지 않으므로 (1)과 (3)에 의존한다. GBP만 관리하면 Google 외 AI 채널에서는 사실상 인식되지 않는다는 뜻이다.

로컬 AI 검색 파이프라인 — 쿼리에서 인용까지

작동 원리: 위치 인텐트 분류와 지식 추출

LocalBusiness JSON-LD 전체 구현

아래는 치과의원 기준 완전한 LocalBusiness 스키마 예시다. @type에 schema.org 전문 하위 유형(Dentist, Restaurant, MedicalClinic 등)을 쓰면 일반 LocalBusiness보다 AI 엔진이 도메인을 더 명확히 분류한다. 이 블록은 <script type="application/ld+json">으로 사이트 전 페이지 <head>에 삽입한다. 홈 페이지에만 넣으면 크롤러가 하위 페이지에서 컨텍스트를 잃는다.

{
  "@context": "https://schema.org",
  "@type": "Dentist",
  "name": "밝은미소치과의원",
  "url": "https://example-dental.co.kr",
  "telephone": "+82-2-1234-5678",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "테헤란로 123",
    "addressLocality": "강남구",
    "addressRegion": "서울특별시",
    "postalCode": "06234",
    "addressCountry": "KR"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 37.5012,
    "longitude": 127.0396
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
      "opens": "09:00",
      "closes": "19:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Saturday"],
      "opens": "09:00",
      "closes": "14:00"
    }
  ],
  "hasMap": "https://maps.google.com/?cid=1234567890",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.7",
    "reviewCount": "312"
  },
  "priceRange": "₩₩",
  "sameAs": [
    "https://map.naver.com/v5/search/밝은미소치과",
    "https://place.map.kakao.com/12345678"
  ]
}

검증

NAP 일관성과 외부 인용 신호

AI 엔진은 여러 출처에서 같은 비즈니스를 언급할 때 이름·주소·전화번호 일치 여부로 동일 엔티티임을 판단한다. 불일치가 있으면 서로 다른 사업체로 분류되거나 답변에서 누락될 수 있다.

로컬 SEO vs 로컬 AEO vs 로컬 GEO — 신호 비교

항목 로컬 SEO (전통) 로컬 AEO (답변 엔진) 로컬 GEO (생성형 엔진)
주요 색인 소스 Google 크롤러, GBP GBP + 구조화 데이터 크롤러 + 외부 인용 텍스트
핵심 신호 백링크·리뷰 수·GBP 완성도 FAQ 마크업·openingHours LocalBusiness JSON-LD + NAP 일관성
위치 처리 방식 GBP 지오태그 geo 좌표 + 반경 필터 geo 좌표 + sameAs 엔티티 연결
결과 형태 로컬 팩 (지도 3개) AI Overviews 답변 상자 AI 답변 내 비즈니스명 인용
측정 지표 로컬 팩 노출수·CTR AI Overviews 노출 여부 ChatGPT/Perplexity 답변 내 언급 추적

흔한 오해: "GBP 최적화 = AI 검색 가시성 확보"

오해: Google Business Profile을 완성하고 리뷰를 많이 받으면 ChatGPT Search, Perplexity 등 AI 검색에서도 자동으로 상위 노출된다고 가정하는 경우가 많다.

실제 구조: ChatGPT Search(Bing Index 기반)와 Perplexity(자체 크롤러)는 GBP 데이터에 직접 접근하지 않는다. 이들이 로컬 비즈니스 정보를 수집하는 경로는 웹사이트의 구조화 데이터, 크롤된 외부 인용 텍스트, Bing Places(ChatGPT 한정)다. GBP를 아무리 정교하게 관리해도 웹사이트에 JSON-LD가 없고 외부 인용이 적으면 Google 외 AI 채널에서는 인식되지 않는다.

올바른 접근:

  1. 웹사이트 전 페이지에 LocalBusiness JSON-LD 삽입 — 크롤러가 직접 구조화 데이터를 수집한다.
  2. GBP 외 Bing Places, 네이버 플레이스, 카카오맵 동시 관리 — 플랫폼 다변화로 채널별 인용 신호를 확보한다.
  3. 지역 블로그·커뮤니티에 NAP 일치 인용이 생성되도록 콘텐츠 운영 — 비구조화 인용 신호를 지속적으로 축적한다.
Q. 아파트·오피스텔처럼 상세주소가 복잡한 경우 PostalAddress를 어떻게 써야 하나?

streetAddress에 동·호수까지 포함하되, 도로명주소 공식 표기(행정안전부 도로명주소 API 기준)를 그대로 사용한다. "테헤란로 123, 5층 501호"처럼 콤마로 건물 내 상세를 이어 붙이는 방식이 파서 친화적이다. addressLocality에 구(區)를, addressRegion에 시·도를 분리해 넣어야 지오코딩 오류 없이 처리된다. 세 필드를 정확히 나누지 않고 streetAddress 하나에 전체 주소를 넣는 패턴은 파서에 따라 좌표 추출에 실패한다.

Q. 여러 지점이 있는 프랜차이즈는 지점별 JSON-LD를 따로 만들어야 하나, 본사 페이지 하나로 통일해야 하나?

지점별로 별도 JSON-LD를 작성하는 것이 원칙이다. AI 엔진은 엔티티 단위로 위치를 인식하므로, 본사 페이지 하나에 여러 지점 주소를 나열하면 각 지점이 독립 엔티티로 색인되지 않는다. 각 지점에 고유 URL(예: /branches/gangnam)을 부여하고 해당 페이지에 그 지점의 geo·openingHoursSpecification·telephone을 포함한 LocalBusiness 블록을 삽입한다. 본사와의 관계는 parentOrganization 속성으로 연결한다.

참고 자료

이 글의 권고는 아래 공식 문서·연구를 근거로 합니다.

김태오
김태오 · 그로스·퍼포먼스 리드

AI 검색 유입을 전환·매출로 잇는 광고·어트리뷰션을 다룹니다. 숫자로 말하는 걸 좋아합니다.

내 사이트의 AI 검색 점수가 궁금하다면

30초 무료 진단으로 SEO·AEO·GEO 점수와 처방을 받아보세요.

무료 진단 시작
← 블로그 목록으로