F&B·외식업 로컬 AI 검색 공략

Google AI Overviews·Perplexity·ChatGPT Search가 "강남 파스타 맛집"·"근처 24시 분식집" 같은 로컬 의도 쿼리를 처리할 때, 인용 후보를 결정하는 신호는 전통적 로컬 SEO(GMB 별점·리뷰 수)와 구조적으로 다르다. AI 엔진은 크롤링한 페이지의 JSON-LD에서 영업시간·메뉴·가격대·위치 좌표를 직접 파싱하고, 이 데이터의 완전성(completeness)과 NAP(Name·Address·Phone) 일관성을 신뢰도 신호로 처리한다. 2024년 하반기 이후 Google AI Overviews가 로컬 팩 결과와 통합되면서, 구조화 데이터가 누락된 F&B 페이지는 AI 합성 답변에서 실질적으로 비가시권에 놓인다.

로컬 AI 검색 파이프라인의 작동 구조

Google AI Overviews는 쿼리 의도를 탐색(정보 수집)·비교(옵션 평가)·즉시 방문(현재 열려있는 곳)으로 분류한 뒤, Knowledge Graph에 등록된 로컬 엔티티를 1차 후보로 인출한다. schema.org/Restaurant JSON-LD의 @id와 sameAs가 Google Maps CID·Wikidata QID와 연결되면 엔티티 신뢰도가 올라가고 GMB 데이터와 웹 페이지 데이터가 병합 인용된다.

• "근처 OO" 즉시 방문 쿼리 — openingHoursSpecification의 현재 시각 일치 여부가 인용 트리거다. 왜: AI가 "지금 운영 중"을 확인할 수 없으면 인용을 회피한다. 어떻게: dayOfWeek·opens·closes를 요일별로 완전 기재하고, 임시 휴무는 specialOpeningHoursSpecification에 validFrom·validThrough를 ISO 8601 형식으로 별도 마크업.
• "OO 추천" 비교 쿼리 — aggregateRating이 네이버·카카오 등 third-party 플랫폼과 일치할 때 AI 답변 노출 가능성이 높아진다. 왜: 자체 markup 평점만으로는 Google이 AI 답변에 직접 표시하지 않는다(추정). 어떻게: ratingValue·reviewCount를 플랫폼 실측치와 주기적으로 동기화.
• "OO 메뉴 가격" 정보 쿼리 — hasMenu URL 또는 Menu→MenuItem→offers.price 인라인 스키마가 필요하다. 왜: PDF 메뉴는 파싱 불가이며, AI는 HTML 텍스트로 마크업된 메뉴에서만 가격 데이터를 추출한다. 어떻게: 주요 메뉴 5~10개 이상을 MenuItem 타입으로 페이지에 직접 마크업.

Restaurant JSON-LD 완전 구현

schema.org/Restaurant은 FoodEstablishment의 하위 타입이다. 최소 필수 속성(name·address·telephone)만으로는 AI 인용 후보가 되기 어려우므로, 아래 확장 속성까지 구현해야 한다.

{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "@id": "https://example-restaurant.kr/gangnam#restaurant",
  "name": "예시 파스타 강남점",
  "url": "https://example-restaurant.kr/gangnam",
  "telephone": "+82-2-1234-5678",
  "servesCuisine": ["이탈리안", "파스타", "Italian", "Pasta"],
  "priceRange": "₩₩",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "테헤란로 123",
    "addressLocality": "강남구",
    "addressRegion": "서울특별시",
    "postalCode": "06234",
    "addressCountry": "KR"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 37.498095,
    "longitude": 127.027610
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
      "opens": "11:30",
      "closes": "22:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Saturday","Sunday"],
      "opens": "12:00",
      "closes": "21:00"
    }
  ],
  "hasMenu": "https://example-restaurant.kr/gangnam/menu",
  "acceptsReservations": true,
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.3",
    "reviewCount": "287",
    "bestRating": "5"
  },
  "sameAs": [
    "https://map.naver.com/v5/entry/place/123456789",
    "https://place.map.kakao.com/123456789",
    "https://www.google.com/maps/place/?cid=1234567890123456789"
  ]
}

• @id: 엔티티 고유 URI에 #restaurant fragment 사용. 왜: 같은 식당의 위치·메뉴·예약 페이지가 Knowledge Graph에서 하나의 엔티티로 병합되려면 @id가 일관돼야 한다. 어떻게: 지점별 독립 URL에 동일 fragment를 붙여 전 페이지에서 통일.
• servesCuisine: 한국어·영어 병기 배열. 왜: LLM이 "Italian restaurant near Gangnam"처럼 영어 쿼리도 처리하므로 양 언어 매칭이 인용 범위를 넓힌다. 어떻게: 상위 카테고리(이탈리안)와 세부 메뉴 유형(파스타·리소토)을 함께 기재.
• sameAs: 네이버 플레이스·카카오맵·구글 맵 URL 배열. 왜: AI 엔진이 이 배열로 동일 엔티티임을 크로스 체크한다. 어떻게: Google Maps의 경우 CID가 포함된 형식(cid=숫자) 사용, 단축 URL 사용 금지.

NAP 일관성과 AI 크롤러 접근 제어

NAP 일관성 강제

Name·Address·Phone이 웹 사이트·GMB·네이버 플레이스·카카오맵·배달앱 간에 불일치하면 AI 엔진이 엔티티 동일성 판단에 실패해 신뢰도를 낮춘다. 도로명 주소 표기 차이("테헤란로 123" vs "테헤란로(역삼동) 123")나 전화번호 형식(02-1234-5678 vs +82-2-1234-5678)이 대표적인 불일치 원인이다. JSON-LD에는 ITU E.164 형식(+82-)을 사용하고, 외부 플랫폼 등록 문자열은 단일 마스터 시트로 관리한다.

robots.txt — AI 학습 크롤러와 검색 인덱서 분리

AI 학습 데이터 수집 크롤러와 AI 검색 인덱서는 다른 User-agent를 사용한다. 콘텐츠 무단 학습은 차단하면서 AI 답변 인용 채널은 유지하는 정책이 F&B 업종에서 실용적이다.

# 검색 인덱서 — AI 답변 인용을 위해 전체 허용
User-agent: Googlebot
Allow: /

User-agent: Bingbot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Applebot
Allow: /

# AI 학습 크롤러 — 무단 학습 방지 차단
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: CCBot
Disallow: /

Sitemap: https://example-restaurant.kr/sitemap.xml

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

흔한 오해와 올바른 처리법

오해: "구글 비즈니스 프로필(GBP)만 최적화하면 AI 검색 인용은 자동으로 된다."

GBP 데이터(영업시간·주소·카테고리)는 Google Knowledge Panel과 Maps에 반영되지만, AI Overviews가 웹 페이지를 인용할 때는 해당 랜딩 페이지의 JSON-LD를 독립적으로 파싱한다. GBP와 웹 페이지 JSON-LD가 불일치하면 AI 엔진은 두 소스를 병합하지 못하고 인용을 회피하거나 불완전한 정보만 출력한다. 올바른 처리: GBP 영업시간·주소 업데이트 후 웹 페이지 JSON-LD를 반드시 동기화하고, Google Search Console의 리치 결과 테스트로 파싱 오류를 주 1회 이상 점검한다. CMS를 사용한다면 GBP API와 JSON-LD 생성 로직을 단일 소스(DB 레코드)에서 구동하도록 연결하는 것이 근본 해결책이다.

검증 및 측정

• Google Rich Results Test: https://search.google.com/test/rich-results에서 Restaurant 스키마 파싱 오류·경고 확인. 왜: AI Overviews가 Rich Result 데이터를 1차 파싱 소스로 사용하기 때문. 어떻게: 배포 후 URL 직접 입력해 openingHoursSpecification·aggregateRating이 정상 파싱되는지 확인.
• Schema Markup Validator: https://validator.schema.org에서 JSON-LD 구조 오류 검출. 왜: JSON 문법 오류가 있어도 페이지는 정상 렌더되므로 별도 검증이 필수다. 어떻게: CI/CD 파이프라인에 python3 -c "import json,sys;json.load(sys.stdin)"으로 JSON 유효성 자동 체크 추가.
• AI 인용 수동 샘플링: "강남 파스타 맛집 추천"·"[식당명] 영업시간" 등 10개 쿼리를 Perplexity·ChatGPT Search에 2주 간격으로 입력해 인용 빈도를 기록. 왜: AI 인용을 직접 측정하는 공개 API가 현재 없으므로 수동 샘플링이 유일한 실측 수단이다.

기술 FAQ

참고 자료

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

• Google 검색 센터 — SEO 기본 가이드
• Google 검색의 AI 기능과 내 웹사이트
• Schema.org — 구조화 데이터 시작하기