식당·카페는 AI 검색·추천에 어떻게 대비하나요?
식당·카페의 AI 검색 대비는 상호·위치·영업시간·메뉴를 자기 웹페이지에 크롤링 가능한 텍스트와 Restaurant 스키마로 공개하는 데서 시작한다. 리뷰 플랫폼 안에만 있는 정보는 AI 크롤러가 읽기 어려워, 제3자 블로그가 내 가게를 대신 인용하게 될 수 있다.
최종 업데이트 2026-07-12
"강남역 근처에서 혼밥하기 좋은 국밥집 알려줘" — 이런 질문이 점점 포털 검색창 대신 ChatGPT·Perplexity·구글 AI 오버뷰로 들어간다. AI는 지도 앱을 열어주는 대신, 크롤링 가능한 웹페이지들을 조합해 추천 답 하나를 만든다. 이때 내 가게 정보가 어디에 어떤 형태로 존재하느냐가 그 답의 후보에 들어갈 확률을 가른다.
리뷰 플랫폼에만 있으면 생기는 구조적 문제
국내 식당·카페 정보의 대부분은 포털 지도와 리뷰 앱 안에 있다. 문제는 이 데이터 상당수가 로그인과 앱 안에 갇혀 있어 AI 크롤러가 접근하기 어렵다는 점이다. 그래서 AI는 지역+업종 질문의 답을 고를 때 가게 자신 대신, 접근 가능한 제3자 — 방문 후기를 쓴 블로그, 맛집 정리 글 — 를 인용하는 일이 생긴다.
인용의 주도권이 남에게 있으면 두 가지가 위험해진다. 바뀐 영업시간·사라진 메뉴 같은 낡은 정보가 계속 인용될 수 있고, 블로거의 글 하나나 플랫폼 정책 변화에 내 가게의 AI 노출이 좌우된다.
Restaurant 스키마: 기본 정보의 기계가독화
schema.org 어휘에는 LocalBusiness 아래 FoodEstablishment, 그 아래 Restaurant와 CafeOrCoffeeShop 타입이 있다. 요리 종류(servesCuisine), 예약 가능 여부(acceptsReservations), 메뉴(hasMenu) 같은 음식점 특화 속성을 쓸 수 있다. 구글 검색 공식 문서도 가능한 한 구체적인 하위 타입(예: Restaurant)을 쓰라고 안내하며, 주소(address)는 필수 속성으로, 전화·영업시간(openingHoursSpecification)·가격대(priceRange)는 권장 속성으로 제시하고, 음식점에는 메뉴 페이지 URL(menu)을 안내한다.
{
"@context": "https://schema.org",
"@type": "Restaurant",
"name": "OO국밥 강남점",
"servesCuisine": "한식",
"priceRange": "₩₩",
"address": {"@type": "PostalAddress", "streetAddress": "테헤란로 00", "addressLocality": "강남구", "addressRegion": "서울", "addressCountry": "KR"},
"telephone": "+82-2-000-0000",
"openingHoursSpecification": {"@type": "OpeningHoursSpecification", "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"], "opens": "10:00", "closes": "21:00"},
"hasMenu": "https://example.com/menu/"
}
교육용 예시이므로 값은 자기 가게 정보로 바꿔 넣으면 된다.
메뉴판 사진만으로는 크롤러가 읽기 어렵다
많은 가게가 메뉴를 이미지로만 올리지만, 크롤러에게 이미지 속 글자는 없는 정보에 가깝다. 메뉴는 HTML 텍스트로 먼저 적고, 여력이 되면 구조화한다. schema.org 정의상 메뉴는 Menu > MenuSection > MenuItem 구조로 표현하며, MenuItem에는 offers로 가격을, suitableForDiet로 채식·글루텐프리 같은 식이 정보를 담을 수 있다. "OO역 근처 비건 옵션 있는 카페" 같은 조건형 질문에서 이런 필드가 판단 근거가 된다.
현실적 우선순위
- 자기 도메인의 페이지 하나 — 상호·주소·영업시간·전화·메뉴를 크롤링 가능한 텍스트로 공개한다. 네이버 블로그냐 자기 도메인이냐 고민된다면, 원본 정보는 자기 도메인에 두는 쪽이 안전하다.
- Restaurant JSON-LD — 위 예시 수준의 기본 필드부터 심는다.
- 메뉴 구조화 — 텍스트 메뉴 먼저, 그다음 MenuItem까지.
- 정보 일관성 — 웹사이트·플랫폼·디렉토리의 상호·주소·영업시간이 일치해야 신뢰 근거가 쌓인다.
리뷰 플랫폼을 버리라는 얘기가 아니다. 플랫폼 관리는 계속하되, AI가 인용할 원본을 내 웹에 두는 것이 요지다.
다음 단계
자주 묻는 질문
- 식당·카페는 AI 검색·추천에 어떻게 대비하나요?
- 상호·위치·영업시간·메뉴를 자기 웹페이지에 크롤링 가능한 텍스트로 공개하고 Restaurant 스키마로 구조화하는 것이 출발점이다. 리뷰 플랫폼 안에만 있는 정보는 AI가 읽기 어려워, 제3자 블로그가 내 가게를 대신 인용하게 될 수 있다.
- 메뉴판 사진만 올려도 AI가 읽을 수 있나요?
- 이미지로만 올린 메뉴는 크롤러가 텍스트로 읽기 어렵다. 메뉴는 HTML 텍스트로 먼저 적고, 여력이 되면 schema.org의 Menu·MenuItem 구조화 데이터로 가격·식이 정보까지 담으면 조건형 질문에서 판단 근거가 된다.
- 포털 지도·리뷰 앱 관리만으로는 부족한가요?
- 부족할 수 있다. 로그인과 앱 안에 갇힌 데이터는 AI 크롤러가 접근하기 어려워, 접근 가능한 블로그·정리 글이 대신 인용되는 구조가 생긴다. 플랫폼은 계속 쓰되 AI가 인용할 원본 정보를 자기 도메인에 두는 편이 안전하다.