LocalBusiness 스키마 마크업 완벽 가이드

LocalBusiness 스키마는 매장·병원·사무실 같은 오프라인 사업장의 이름, 주소, 전화번호, 영업시간을 검색엔진이 이해하는 코드로 정리해주는 구조화 데이터다. 필수로 넣어야 하는 항목은 name(사업장명)과 address(주소) 딱 두 개뿐이지만, 실제로는 이 두 개만 넣고 끝내는 사이트가 대부분이라 손해를 보고 있다.

이 글은 무엇을 필수로 채우고 무엇을 추가로 넣어야 하는지, 업종마다 어떤 서브타입을 골라야 하는지, 리뷰 별점은 넣어도 되는지, 그리고 작성한 코드가 실제로 제대로 인식되는지 검증하는 법까지 예시 중심으로 정리한다.

이 글의 핵심은 다음과 같다.

• 구글이 요구하는 필수 속성은 name과 address 단 두 개다. 나머지는 전부 권장 속성이지만 채울수록 유리하다.
• 업종에 맞는 가장 구체적인 서브타입(Restaurant, Dentist, HairSalon 등)을 골라야 한다. 범용 LocalBusiness만 쓰면 정보 손실이 생긴다.
• aggregateRating(리뷰 평점)은 자기 사업장에 대한 리뷰를 자기 사이트에 직접 넣는 용도로는 권장되지 않는다.
• 코드를 넣는 것과 화면 정보(NAP: 이름·주소·전화번호)가 일치하는 것은 별개 문제다. 둘이 다르면 오히려 신뢰를 깎는다.
• 발행 전 리치 결과 테스트로 반드시 검증해야 한다.

LocalBusiness 스키마란 정확히 무엇인가

LocalBusiness는 스키마닷오알지(schema.org)가 정의한 데이터 타입 중 하나로, 오프라인 매장이나 사무실을 운영하는 사업자의 정보를 검색엔진이 읽을 수 있는 형태로 구조화한 코드다. HTML 안에 <script type="application/ld+json"> 태그로 넣는 JSON-LD 방식이 구글이 공식적으로 권장하는 형식이다.

이 마크업이 있다고 해서 화면에 특별한 디자인이 생기는 것은 아니다. 검색엔진과 AI가 "이 페이지는 이런 이름·주소·영업시간을 가진 사업장의 페이지다"라고 명확하게 파악하도록 돕는 역할이다. 구글 공식 문서는 이 정보가 검색 결과의 지식패널이나 관련 사업장 캐러셀에 활용될 수 있다고 설명한다. 다만 레스토랑 캐러셀처럼 화면에 직접 노출되는 형태는 현재 일부 데이터 제공업체에 한정돼 있어, 대부분의 일반 사업장 홈페이지에는 해당하지 않는다.

실무에서는 LocalBusiness 스키마를 "특정 리치 결과를 얻기 위한 코드"보다는 "내 사업장 정보를 검색엔진과 AI에게 명확한 사실로 전달하는 기초 작업"으로 이해하는 편이 정확하다.

왜 지역 사업자 홈페이지에 꼭 필요한가

검색엔진과 AI 검색 서비스는 화면에 보이는 글자만으로는 "이게 사업장 정보"라는 걸 확신하기 어렵다. 사람은 "영업시간: 평일 10시–19시"라는 문장을 보면 바로 이해하지만, 기계에게는 그저 텍스트 조각일 뿐이다. LocalBusiness 스키마는 이 문장을 openingHoursSpecification이라는 명확한 필드에 담아 오해의 여지를 없앤다.

두 번째 이유는 일관성 신호다. 구글 비즈니스 프로필(GBP)에 등록한 이름·주소·전화번호(NAP)와 홈페이지에 마크업된 정보가 서로 다르면, 어느 쪽이 정확한 정보인지 검색엔진 입장에서 판단하기 어려워진다. 실무자들 사이에서는 NAP 일관성이 로컬 검색 신뢰도의 기본 전제로 여겨진다. 이 부분은 지역 SEO 전략을 폭넓게 다룬 글에서 더 자세히 확인할 수 있다.

세 번째는 AI 검색이 사업장 정보를 인용할 때 구조화된 사실을 우선한다는 점이다. 챗GPT, 제미나이, 퍼플렉시티 같은 AI 검색 서비스가 "근처 이 업종 추천해줘" 같은 질문에 답할 때, 본문 어딘가에 흩어진 정보보다 명확하게 구조화된 이름·주소·영업시간을 더 안정적으로 활용한다. 아직 이 효과를 정량적으로 증명한 대규모 연구는 부족하지만, 구조화된 사실이 애매한 산문보다 기계가 파싱하기 쉽다는 점은 기술적으로 당연하다.

구글 비즈니스 프로필과 홈페이지 스키마는 어떤 관계인가

둘은 완전히 다른 시스템이다. 구글 비즈니스 프로필(GBP)은 구글이 직접 운영하는 별도의 등록 서비스이고, 홈페이지 안의 LocalBusiness 스키마는 내 사이트 코드일 뿐이다. GBP에 사업장을 등록하지 않았다고 해서 홈페이지 스키마가 자동으로 로컬팩에 반영되는 것은 아니다.

두 시스템은 서로 대체하는 관계가 아니라 보완하는 관계다. GBP는 지도·로컬팩 노출을 담당하고, 홈페이지 스키마는 내 사이트를 크롤링하는 검색엔진과 AI에게 같은 정보를 한 번 더 명확하게 전달하는 역할을 한다. 실무에서 가장 흔한 실수는 GBP에는 정성껏 정보를 채워놓고 홈페이지에는 스키마는커녕 화면에도 정확한 주소를 적어두지 않는 경우다.

GBP 등록과 홈페이지 스키마 작성은 순서가 정해져 있지 않다. 둘 다 하되, 두 곳의 정보가 글자 하나까지 일치하도록 유지하는 것이 핵심이다.

필수 속성과 권장 속성은 어디까지 채워야 하나

구글 공식 문서 기준으로 필수 속성은 name과 address 두 개뿐이다. 하지만 필수만 채우고 끝내면 절반짜리 마크업이 된다 — 권장 속성을 최대한 채워야 실제 효과가 난다. 표로 정리하면 다음과 같다.

구분	속성	설명
필수	name	사업장 이름
필수	address	PostalAddress 객체(도로명주소·시/군/구·우편번호·국가)
권장	telephone	대표 전화번호(국가번호 포함 권장)
권장	openingHoursSpecification	요일별 영업시간
권장	geo	위도·경도(소수점 다섯 자리 이상 권장)
권장	priceRange	가격대(예: "₩₩")
권장	url	대표 홈페이지 주소
권장	image	대표 이미지
업종별	servesCuisine	음식점의 취급 요리
업종별	menu	메뉴 페이지 URL
업종별	department	다부서 사업장의 하위 부서

address는 문자열로 대충 넣지 말고 반드시 PostalAddress 타입 객체로 세분화해야 한다. "서울시 강남구 테헤란로 123, 4층"처럼 통 문장으로 넣으면 검색엔진이 구성 요소를 다시 분리해서 해석해야 하므로 오류 가능성이 커진다. streetAddress, addressLocality, addressRegion, postalCode, addressCountry로 각각 나눠 넣는 것이 정확하다.

openingHoursSpecification도 자주 실수가 나오는 부분이다. "평일 10시–19시, 주말 휴무"라고 문장으로 쓰는 대신, 요일별 배열로 명확하게 나눠야 한다.

"openingHoursSpecification": [
  {
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
    "opens": "10:00",
    "closes": "19:00"
  }
]

내 업종에 맞는 서브타입은 어떻게 고르나

구글은 범용 LocalBusiness 타입 대신 가장 구체적인 서브타입을 쓰라고 명시적으로 권장한다. 서브타입이 세분화될수록 그 업종에만 있는 속성(예: 음식점의 servesCuisine)을 정확히 쓸 수 있고, 검색엔진이 사업 종류를 헷갈릴 여지도 줄어든다.

업종	권장 서브타입
일반 매장	Store
음식점·카페	Restaurant, CafeOrCoffeeShop
치과·병원	Dentist, MedicalClinic
미용실·네일샵	HairSalon, NailSalon
법률사무소	Attorney, LegalService
부동산 중개	RealEstateAgent
자동차 정비소	AutoRepair
헬스장·필라테스	HealthClub, SportsActivityLocation
학원·교습소	EducationalOrganization

딱 맞는 서브타입이 schema.org 목록에 없다면 범용 LocalBusiness를 쓰고 @type을 배열로 확장하는 방법도 있다. 예를 들어 애견 미용을 겸하는 동물병원이라면 ["VeterinaryCare", "LocalBusiness"]처럼 여러 타입을 함께 지정할 수 있다. 억지로 맞지 않는 서브타입을 고르는 것보다는 이렇게 범위를 넓히는 편이 안전하다.

서브타입을 고를 때 흔히 하는 실수는 실제로는 온라인 전용 사업인데도 물리적 매장이 있는 것처럼 LocalBusiness를 쓰는 경우다. 오프라인 주소와 영업시간이 없는 사업이라면 Organization 타입이 더 정확하다.

리뷰(aggregateRating)는 넣어도 되나

이 부분이 가장 많이 오해되는 지점이다. 구글 공식 문서는 aggregateRating과 review 속성을, "다른 지역 사업장에 대한 리뷰를 수집하는 사이트"에 권장한다고 명시한다. 즉 배달 플랫폼이나 지역 정보 사이트처럼 여러 매장의 리뷰를 모아 보여주는 서비스에 어울리는 속성이지, 내 매장 홈페이지에서 내 매장 리뷰를 스스로 마크업하는 용도는 아니다.

구글은 2019년 발표한 정책에서 이런 자기 참조형(self-serving) 리뷰 마크업에는 별점 리치 결과를 노출하지 않기로 했다. 코드를 넣는 것 자체가 정책 위반은 아니지만, 기대하는 별점 리치 결과가 뜨지 않을 가능성이 높다는 뜻이다. 실제 고객 후기를 홈페이지에 소개하고 싶다면 텍스트와 이미지로 자연스럽게 보여주는 편이 화면 신뢰도 측면에서도, 정책 측면에서도 더 안전하다.

반대로 여러 지역 사업장 정보를 모아 소개하는 플랫폼이나 매거진형 콘텐츠라면 aggregateRating을 적극 활용할 수 있다. 이 경우에는 실제로 수집한 리뷰 데이터를 기반으로 정확하게 마크업하면 리치 결과로 이어질 가능성이 있다.

실제 코드로 보는 좋은 예 나쁜 예

코드 하나를 보면 감이 훨씬 빨리 잡힌다. 아래는 미용실을 예로 든 나쁜 예와 좋은 예다.

나쁜 예(주소가 문자열, 영업시간이 자연어, 타입이 범용)

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "OO헤어살롱",
  "address": "서울 강남구 테헤란로 123",
  "hours": "평일 10시-20시"
}

좋은 예(구체적 서브타입, 주소 객체화, 영업시간 명세화)

{
  "@context": "https://schema.org",
  "@type": "HairSalon",
  "name": "OO헤어살롱",
  "telephone": "+82-2-1234-5678",
  "priceRange": "₩₩",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "테헤란로 123",
    "addressLocality": "강남구",
    "addressRegion": "서울",
    "postalCode": "06234",
    "addressCountry": "KR"
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "10:00",
      "closes": "20:00"
    }
  ]
}

나쁜 예의 문제는 세 가지다. hours는 schema.org가 정의한 속성명이 아니라서 아예 인식되지 않는다. 주소는 문자열이라 시/도, 시/군/구가 명확히 분리되지 않는다. 타입도 범용 LocalBusiness라 미용실이라는 업종 정보가 드러나지 않는다.

속성명을 스스로 만들어 쓰는 실수는 생각보다 자주 나온다. schema.org에 정의되지 않은 이름을 쓰면 JSON 문법상 오류가 나지 않더라도 검색엔진은 그 필드를 그냥 무시한다. 리치 결과 테스트를 돌리지 않으면 이런 실수를 눈으로 확인하기 어려운 이유가 여기에 있다. 속성명이 헷갈릴 때는 매번 새로 찾기보다 schema.org 공식 문서나 구글 개발자 문서의 예시 코드를 그대로 복사해 값만 바꾸는 방식이 실수를 줄이는 가장 확실한 방법이다.

워드프레스·카페24·아임웹 같은 플랫폼에서는 어떻게 넣나

직접 코드를 다룰 수 있는 워드프레스라면 Yoast SEO나 RankMath 같은 SEO 플러그인의 지역 사업장(Local Business) 설정 메뉴에서 항목을 입력하면 자동으로 JSON-LD가 생성된다. 워드프레스 홈페이지 제작과 SEO 세팅을 함께 다룬 글에서 관련 설정을 더 자세히 확인할 수 있다.

카페24·아임웹·식스샵 같은 국내 빌더는 플랫폼 자체에 사업장 정보 마크업 기능이 제한적인 경우가 많다. 이럴 때는 빌더가 제공하는 "직접 코드 삽입" 위젯이나 <head> 편집 기능을 활용해 JSON-LD를 수동으로 넣어야 한다. 국내 대표 빌더별 차이는 아임웹·카페24·식스샵 비교 글에서 확인할 수 있다.

빌더에서 코드를 직접 넣을 수 없는 요금제라면, 최소한 화면에 보이는 이름·주소·전화번호·영업시간이라도 명확한 텍스트로 정확히 표기해두는 것이 차선책이다.

작성한 스키마는 어떻게 검증하나

코드를 넣었다고 끝이 아니다. 문법이 맞아 보여도 실제로는 인식되지 않는 경우가 흔하다. 검증은 두 단계로 나뉜다.

• 발행 전: 구글의 리치 결과 테스트 도구에 페이지 URL을 입력하거나 코드를 직접 붙여넣어 오류·경고가 없는지 확인한다.
• 발행 후: 서치 콘솔의 URL 검사 도구로 실제 배포된 페이지를 조회하면 "감지된 구조화 데이터" 항목에서 구글이 실제로 어떤 타입과 속성을 읽었는지 확인할 수 있다.

체크리스트로 정리하면 다음과 같다.

• name, address가 빠짐없이 들어갔는가
• address가 문자열이 아니라 PostalAddress 객체인가
• 업종에 맞는 가장 구체적인 서브타입을 썼는가
• aggregateRating을 자기 사업장 리뷰 용도로 잘못 넣지는 않았는가
• 화면에 보이는 이름·주소·전화번호와 코드 속 정보가 정확히 일치하는가
• 리치 결과 테스트에서 오류·경고 없이 인식되는가

이 검증은 한 번으로 끝나지 않는다. 영업시간이 바뀌거나 지점을 이전할 때마다 화면 정보와 스키마를 함께 업데이트하고, 리치 결과 테스트로 다시 확인하는 습관이 필요하다.

자주 묻는 질문

LocalBusiness 스키마를 넣으면 로컬팩 순위가 바로 오르나

직접적인 순위 상승을 보장하지는 않는다. 구글 비즈니스 프로필의 관리 상태, 리뷰, 카테고리 설정이 로컬팩 노출에 더 큰 영향을 준다. LocalBusiness 스키마는 홈페이지가 전달하는 정보의 정확도를 높여 간접적으로 신뢰도를 뒷받침하는 역할로 이해하는 것이 맞다.

지점이 여러 개면 스키마를 어떻게 나눠야 하나

지점마다 별도 페이지가 있다면 각 페이지에 해당 지점의 정확한 주소와 영업시간을 담은 개별 LocalBusiness 스키마를 넣는 것이 정확하다. 본사 홈페이지 하나에만 스키마를 몰아넣으면 특정 지점을 찾는 검색과 잘 매칭되지 않는다.

geo 속성의 위도·경도는 어떻게 구하나

구글 지도에서 사업장 위치를 우클릭하면 좌표가 표시된다. 소수점 다섯 자리 이상까지 정확하게 입력하는 것이 권장 사항이다.

온라인 전용 쇼핑몰도 LocalBusiness를 써야 하나

물리적 매장이나 사무실이 없다면 LocalBusiness보다 Organization 타입이 더 정확하다. LocalBusiness는 오프라인 주소와 영업시간이 있는 사업자를 전제로 한 타입이다.

스키마 코드는 모든 페이지에 넣어야 하나

전체 페이지에 동일한 코드를 반복해서 넣기보다는 홈페이지나 매장 소개·오시는 길 페이지처럼 사업장 정보의 대표 페이지에 넣는 것으로 충분하다. 페이지마다 다른 사업장 정보를 담고 있다면(예: 지점별 페이지) 각각 넣는다.

스키마를 넣었는데도 구글 검색 결과 화면이 그대로다, 잘못된 건가

정상일 수 있다. LocalBusiness 스키마는 특정 리치 결과를 즉시 만들어내는 코드가 아니라, 검색엔진이 사업장 정보를 정확히 이해하도록 돕는 배경 정보에 가깝다. 지식패널이나 캐러셀 노출 여부는 스키마 외에도 사이트 전반의 신뢰도, GBP 상태 등 여러 요소가 함께 작용하므로, 코드를 넣었다고 화면이 바로 바뀌지 않는 것이 오히려 일반적이다.

리치 결과 테스트에서 "경고"가 뜨면 무시해도 되나

경고는 "필수는 아니지만 있으면 더 좋다"는 뜻으로, 즉시 고쳐야 하는 오류와는 다르다. 다만 경고가 많을수록 검색엔진이 활용할 수 있는 정보가 적다는 뜻이므로, 시간이 될 때 하나씩 채워 넣는 것이 좋다.

---

LocalBusiness 스키마는 코드 몇 줄처럼 보이지만, 실제로는 우리 사업장을 검색엔진과 AI에게 정확하게 설명하는 가장 기본적인 작업입니다. 필수 속성 두 개만 채우고 끝내지 마시고, 업종에 맞는 서브타입과 영업시간·위치 정보까지 꼼꼼히 채워 넣으시길 권해 드립니다. 스키마 마크업이 낯설게 느껴지신다면, 이루웹의 홈페이지 제작 서비스에서 JSON-LD 기초부터 업종별 구조화 데이터 설계까지 함께 도와드리고 있습니다. 지역 SEO 전반을 더 깊이 살펴보고 싶으시다면 지역 SEO 완벽 가이드도 참고해보시고, 이루웹의 다른 서비스도 함께 확인해보시기 바랍니다. 궁금한 점은 상담 신청으로 편하게 문의해 주시기 바랍니다.