대만에서 LocalBusiness Schema를 적용했는데도 AI 엔진에 언급되지 않는다면 문제는 코드보다 데이터 불일치에 있을 가능성이 큽니다. 사용자가 Perplexity나 ChatGPT에 “타이베이시 신이구에서 추천할 만한 치과가 있나요?”라고 물으면 AI는 먼저 웹사이트에 기재된 상호, 주소, 전화번호를 Google 비즈니스 프로필, 지도, 업종 디렉터리의 정보와 교차 검증합니다. 이 과정에서 서로 다른 3가지 표기가 발견되면 어느 것이 맞는지 추측하기보다 해당 업체를 답변에서 제외하는 쪽을 택할 수 있습니다. 실제 인용 여부를 좌우하는 핵심은 NAP(Name, Address, Phone), 즉 상호·주소·전화번호의 일관성입니다. 스키마 문법은 이 사실을 기계가 읽을 수 있는 형식으로 포장하는 수단일 뿐입니다. 이 글에서는 유형 선택, 주소 입력, 영업시간 작성, 플랫폼별 NAP 통일 순서로 구축 방법을 살펴봅니다.
AI 엔진이 LocalBusiness 정보에 특히 민감한 이유
AI 엔진이 지역 기반 질문에 답하려면 매장의 위치, 현재 영업 여부, 전화번호처럼 명확하게 추출할 수 있는 사실이 필요합니다. 그러나 중문 주소는 기계가 처리하기 까다롭습니다. 사람이 보기에는 “타이베이시 신이로 5단 7호”와 “타이베이시 신이구 신이로 5단 7호”가 같은 장소지만, 정보 추출 모델은 서로 다른 2개 엔터티로 판단할 수 있습니다. LocalBusiness Schema는 이 정보를 고정 필드로 나누어 표시합니다. 엔진이 직접 추측하고 대조하는 수고를 덜도록 답을 정리해 건네는 셈입니다. 추측할 부분이 줄어들수록 AI 엔진이 해당 업체를 답변에 포함할 가능성도 커집니다.
1단계: 모든 업종을 LocalBusiness로 처리하지 말고 적합한 @type 선택하기
schema.org의 LocalBusiness 아래에는 수십 가지 하위 유형이 있습니다. 유형을 구체적으로 지정할수록 엔진이 해당 업체의 사업 내용을 정확히 이해할 수 있습니다. 예를 들어 회계사무소에 범용 LocalBusiness를 지정하는 것과 AccountingService를 지정하는 것은 AI가 “사용자가 찾는 전문 서비스인가”를 판단할 때 큰 차이를 만듭니다. 우선 사업과 가장 가까운 하위 유형을 찾고, 적합한 유형이 없을 때만 상위의 범용 유형을 사용합니다.
- 레스토랑·커피숍: Restaurant, CafeOrCoffeeShop
- 치과·클리닉: Dentist, MedicalClinic
- 변호사·토지사: Attorney, LegalService
- 회계·기장 사무소: AccountingService
- 소매점: Store. 업종에 따라 ClothingStore, HardwareStore 등으로 세분화할 수 있습니다.
- 미용실·헤어숍: BeautySalon, HairSalon
- 실제로 대응하는 하위 유형이 없을 때만 범용 LocalBusiness를 사용합니다.
주소 필드: 대만 행정구역을 PostalAddress에 매핑하는 방법
주소는 가장 자주 잘못 작성되는 항목입니다. PostalAddress에는 정해진 필드가 있으므로 대만의 행정구역 체계를 항목별로 정확히 맞춰야 합니다. 전체 주소를 streetAddress에 한꺼번에 넣으면 엔진이 현·시와 행정구를 구분해 추출할 수 없습니다.
- addressCountry: 국가명 “Taiwan”이 아니라 국가 코드 “TW”를 입력합니다.
- addressRegion: 직할시 또는 현을 입력합니다. 예: “Taipei City”, “New Taipei City”
- addressLocality: 구 또는 향·진을 입력합니다. 예: “Xinyi District”
- streetAddress: 도로명, 단, 골목, 번지를 입력합니다. 예: “No. 7, Section 5, Xinyi Road”
- postalCode: 3+3 우편번호를 입력합니다. 예: “110011”
- geo: 위도와 경도를 입력하며, 좌표는 Google Maps의 핀 위치와 일치해야 합니다.
영업시간: openingHoursSpecification을 정확히 작성하는 방법
영업시간은 openingHoursSpecification으로 설정합니다. dayOfWeek에 각 요일을 지정하고, opens와 closes에는 24시간제 HH:MM 형식으로 시간을 입력합니다. 점심시간에 문을 닫는 매장을 09:00~21:00로 연속 표기해서는 안 됩니다. 11:00–14:00와 17:00–21:00처럼 2개 구간으로 나누지 않으면 AI가 사용자에게 오후 3시에도 영업한다고 안내할 수 있습니다. 공휴일에 쉬는 경우 해당 날짜를 영업일로 기재하지 않습니다. 24시간 영업이라면 opens와 closes를 모두 00:00으로 입력합니다. 설이나 국경일 같은 기간의 임시 변경에는 기본 영업시간을 직접 수정하기보다 specialOpeningHoursSpecification으로 적용 날짜를 지정하는 편이 안전합니다. 변경 후에는 Google 비즈니스 프로필의 공휴일 영업시간에도 반드시 동기화해 양쪽 정보를 일치시켜야 합니다.
NAP 일관성: 스키마는 여러 정보 접점 중 하나일 뿐입니다
스키마를 아무리 완벽하게 작성해도 다른 접점의 정보와 맞지 않으면 효과를 기대하기 어렵습니다. 상호, 주소, 전화번호는 문장부호와 표기 형식까지 플랫폼마다 동일해야 합니다. 특히 전화번호에서 혼선이 자주 발생합니다. 공식 웹사이트에는 “02-1234-5678”, Google 비즈니스 프로필에는 “(02)12345678”, 스키마에는 “+886-2-1234-5678”로 적혀 있을 수 있습니다. 사람에게는 모두 같은 번호지만 기계에는 서로 다른 3개 정보로 보일 수 있습니다. 구조화 데이터의 전화번호는 E.164 형식인 “+886212345678”로 통일하는 것이 좋습니다. 사용자에게 보여 주는 번호는 별도로 읽기 좋게 편집하되, 스키마에는 한 가지 형식만 남깁니다.
- Google 비즈니스 프로필
- 공식 웹사이트의 스키마, 푸터, 문의 페이지
- Facebook, Instagram 비즈니스 페이지
- Apple Maps와 각종 내비게이션 플랫폼
- 업종 디렉터리와 지역 전화번호부
고객사의 현지 공식 웹사이트를 점검할 때 가장 자주 발견하는 문제는 스키마 누락이 아닙니다. 동일한 전화번호가 4개 플랫폼에서 4가지 방식으로 표기된 경우입니다. AI 엔진의 관점에서는 하나의 매장이 아니라 서로 매우 닮은 4개 매장처럼 보일 수 있습니다.— Tenten GEO audit notes
공개 전 검증 체크리스트
- Google Rich Results Test로 스키마가 오류 없이 파싱되는지 확인합니다.
- Schema Markup Validator로 각 필드의 문법을 점검합니다.
- 스키마의 NAP를 그대로 복사해 Google 비즈니스 프로필 옆에 놓고 비교하여 불일치를 찾습니다.
- AI 엔진에 지역 기반 질문을 직접 입력해 답변의 주소와 영업시간이 정확한지 확인합니다.
- 공개 후에도 정기적으로 재점검합니다. 주소나 전화번호가 바뀌면 모든 플랫폼을 함께 업데이트합니다.
LocalBusiness Schema의 진짜 난점은 JSON-LD 코드 자체가 아니라 수십 개 플랫폼에 흩어진 사실을 장기간 일관되게 유지하는 데 있습니다. AI 엔진이 NAP와 구조화 데이터를 몇 개의 매장으로 인식하는지 확신하기 어렵다면 Tenten GEO의 30일 GEO 감사로 이러한 간극을 한 번에 찾아낼 수 있습니다. 먼저 빠르게 방향을 확인하고 싶다면 30분 GEO 진단을 예약할 수도 있습니다. 실제 웹사이트 주소를 바탕으로 지역 검색 쿼리를 실행해 드립니다.
