로컬 비즈니스 스키마: 완전한 JSON-LD 예시, Google 규칙, 피해야 할 실수

로컬 비즈니스 스키마는 매장, 음식점, 병원, 에이전시의 연락처 블록을 기계가 읽을 수 있는 데이터로 바꿔 주는 스키마 마크업 유형입니다. Google은 로컬 비즈니스 구조화 데이터 가이드에서 이를 설명하고 있으며, 어휘는 schema.org/LocalBusiness에서 가져옵니다. 이 가이드는 바로 응용할 수 있는 완전한 예시, 꼭 알아야 할 규칙, 마크업을 쓸모없게 만드는 실수를 정리합니다.

LocalBusiness 스키마란 무엇인가요?

LocalBusiness는 “특정한 오프라인 비즈니스 또는 조직의 지점”을 나타내는 schema.org 유형입니다. Organization과 Place라는 두 상위 유형을 상속하므로, 회사 속성(로고, 전화번호, 소셜 미디어 프로필)과 장소 속성(주소, 좌표, 지도, 영업시간)을 모두 사용할 수 있습니다.

schema.org에는 30개의 직접 하위 유형이 있으며, 그중 상당수는 다시 하위 유형을 가집니다. Google은 사용 가능한 가장 구체적인 하위 유형을 쓰라고 요구합니다. 치과는 Dentist, 빵집은 Bakery, 법률 사무소는 LegalService 또는 Attorney입니다. 가장 많이 쓰는 선택지는 다음과 같습니다.

비즈니스가 여러 유형에 해당하면 Google은 배열을 허용합니다. 예를 들면 ["Store", "AutoRepair"]입니다. 이 용도로 additionalType은 지원하지 않습니다.

Google이 요구하고 권장하는 속성은 무엇인가요?

Google 문서는 속성을 두 그룹으로 나눕니다. 필수 속성은 두 개뿐이고, 마크업을 유용하게 만드는 것은 권장 속성입니다.

마지막 행은 AI 가시성에 중요합니다. sameAs는 페이지를 비즈니스 프로필, 소셜 계정, 디렉터리 등록 정보와 연결해, 어떤 시스템이든 이 프로필들이 같은 엔티티를 설명한다는 것을 확인하도록 돕습니다.

JSON-LD로 작성한 로컬 비즈니스 스키마 전체 예시

JSON-LD는 Google이 권장하는 형식입니다. 유형이 application/ld+json인 script 태그를 지점 페이지의 head 또는 body에 넣습니다. 가상의 치과를 위한 전체 예시이니, 여러분의 데이터에 맞게 수정해 사용하세요.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Dentist",
  "@id": "https://www.example-dental.com/lyon/#business",
  "name": "Example Dental Lyon",
  "url": "https://www.example-dental.com/lyon/",
  "image": "https://www.example-dental.com/images/lyon-front.jpg",
  "logo": "https://www.example-dental.com/images/logo.png",
  "telephone": "+33 4 00 00 00 00",
  "priceRange": "$$",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "12 Rue de la République",
    "addressLocality": "Lyon",
    "postalCode": "69002",
    "addressRegion": "Auvergne-Rhône-Alpes",
    "addressCountry": "FR"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 45.76012,
    "longitude": 4.83584
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "08:30",
      "closes": "19:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": "Saturday",
      "opens": "09:00",
      "closes": "12:30"
    }
  ],
  "sameAs": [
    "https://www.facebook.com/exampledentallyon",
    "https://www.linkedin.com/company/example-dental"
  ]
}
</script>

이 예시를 견고하게 만드는 세부 사항은 세 가지입니다. @id는 비즈니스에 고정 식별자를 부여해 사이트의 다른 블록(Organization, Service, Review)이 참조할 수 있게 합니다. 좌표는 Google의 요구대로 소수점 이하 5자리입니다. 그리고 url은 홈페이지가 아니라 지점 페이지를 가리킵니다. 코드를 직접 작성하고 싶지 않다면 저희 무료 스키마 생성기로 양식을 채워 블록을 만들 수 있습니다.

영업시간, 휴일, 여러 지점은 어떻게 마크업하나요?

영업시간

영업시간이 같은 요일 묶음마다 OpeningHoursSpecification 객체를 하나씩 사용합니다. Google 문서는 다음과 같은 특수한 경우도 다룹니다.

• 늦게까지 영업: 객체 하나로 자정을 넘길 수 있습니다(토요일 18:00부터 03:00까지).
• 24시간 영업: opens는 "00:00", closes는 "23:59"로 설정합니다.
• 종일 휴무: opens와 closes를 모두 "00:00"으로 설정합니다.
• 계절별 영업시간 또는 휴일 휴무: 객체에 validFrom과 validThrough 날짜(YYYY-MM-DD)를 추가합니다.

영업시간이 바뀌면 비즈니스 프로필과 동시에 마크업도 업데이트하세요. 둘 사이의 영업시간 불일치는 Google과 AI 답변에서 잘못된 정보가 나오는 흔한 원인입니다.

여러 지점

각 지점에는 자체 LocalBusiness 블록, 주소, 전화번호, 영업시간을 갖춘 전용 페이지가 필요합니다. 홈페이지의 블록 하나에 주소 10개를 몰아넣지 마세요. 홈페이지에는 브랜드를 위한 Organization 블록을 두고, 각 지점 페이지는 parentOrganization으로 이를 참조합니다. 이런 페이지를 만드는 방법은 다지점 SEO와 지역 랜딩 페이지 가이드에서 설명합니다.

부서

슈퍼마켓 안의 약국이나 자동차 대리점 안의 서비스 센터는 department 배열에 넣고, 본 비즈니스와 다른 속성만 기재합니다. Google은 부서에 자체 브랜드가 없다면 “{매장 이름} {부서 이름}” 형식으로 이름을 붙이라고 권장합니다.

방문 서비스형 비즈니스

고객의 집을 방문해 일하는 배관공도 등록된 사무소 주소로 LocalBusiness를 사용하고, 서비스 지역은 areaServed로 설명할 수 있습니다. Google은 areaServed를 속성 목록에 포함하지 않지만 schema.org에서는 허용되며, 서비스 지역이 설정된 비즈니스 프로필과 페이지의 일관성을 유지해 줍니다.

로컬 비즈니스 스키마가 Google 비즈니스 프로필을 대체하나요?

아닙니다. Google 비즈니스 프로필은 여전히 로컬 팩과 Google 지도의 주요 정보원입니다. Google 고객센터에 따르면 지역 검색 결과는 주로 관련성, 거리, 인지도에 따라 결정되며, “완전하고 정확한 정보를 제공하는 비즈니스가 검색결과에 표시될 가능성이 높습니다”. 스키마 마크업은 다른 쪽에서 작동합니다. 기계가 추측 없이 읽는 형식으로, 웹사이트가 프로필과 같은 내용을 말하게 만듭니다.

둘을 잇는 고리는 NAP 일관성입니다. 상호(Name), 주소(Address), 전화번호(Phone)를 프로필, 사이트, 마크업, 디렉터리에 똑같이 표기하는 것입니다. 규칙은 NAP 정의에서 자세히 다루고, 로컬 SEO 페이지는 다른 지역 신호들 사이에서 스키마가 차지하는 위치를 설명합니다.

LocalBusiness 마크업은 어떻게 검증하고, 흔한 실수는 무엇인가요?

모든 지점 템플릿을 두 가지 도구로 테스트하세요. Google 기능의 적용 대상인지 확인하는 Google 리치 결과 테스트와, schema.org 기준으로 문법을 확인하는 Schema Markup Validator입니다. 저희 구조화 데이터 검사기는 어떤 URL이든 빠르게 점검합니다. 배포 후에는 Search Console의 개선사항 보고서가 대규모로 오류를 보여 줍니다.

Google의 구조화 데이터 정책이 기본 틀을 정합니다. “페이지 독자에게 표시되지 않는 콘텐츠는 마크업하지 마세요.” 위반하면 수동 조치를 받아 리치 결과 자격을 잃을 수 있습니다. 가장 자주 보는 실수는 다음과 같습니다.

리뷰 관련 실수는 특히 주의해야 합니다. 2019년부터 Google은 LocalBusiness나 Organization이 자기 자신에 대해 게시하는 “자기 홍보성” 리뷰에 별점을 표시하지 않습니다. 리뷰 스키마 가이드에서 자세히 다루며, 같은 논리가 FAQ 스키마에도 적용됩니다. 페이지에 보이는 내용만 마크업하세요.

로컬 비즈니스 스키마와 GEO: AI 어시스턴트는 이를 어떻게 활용하나

누군가 ChatGPT, Gemini, Perplexity에 “리옹에서 토요일에 문을 여는 치과”를 물으면, 답변은 어시스턴트가 읽고 교차 확인할 수 있는 출처로 구성됩니다. 비즈니스 프로필 데이터, 디렉터리, 리뷰 플랫폼, 그리고 각 비즈니스의 자체 웹사이트입니다. AI 답변 속 디렉터리에 관한 저희 연구는 이런 제3자 등록 정보가 얼마나 자주 인용되는지 보여 줍니다.

구조화 데이터는 두 가지 방식으로 도움이 됩니다. 푸터를 해석하는 데 의존하지 않는 명확한 사실(영업시간, 주소, 업종)을 크롤러에 제공하고, sameAs와 일관된 NAP를 통해 사이트를 다른 프로필과 같은 엔티티로 묶어 줍니다. 더 넓은 그림은 AI 검색을 위한 구조화 데이터 가이드에서 설명하며, LLM용 구조화 데이터 감사는 언어 모델이 여러분의 페이지에서 무엇을 추출하는지 보여 줍니다. 마크업만으로는 절대 충분하지 않습니다. 대부분의 어시스턴트는 JSON-LD만이 아니라 페이지 자체를 읽으므로, 사실은 보이는 텍스트에도 적혀 있어야 합니다.

노력이 성과로 이어지는지 확인하려면, Sorank의 AI 언급 추적이 고객이 묻는 지역 관련 질문을 따라가며 여러분의 비즈니스가 인용되는지 보여 주고, GEO 최적화는 어시스턴트가 인용하는 지점 및 서비스 콘텐츠를 발행하도록 돕습니다. 로컬 비즈니스를 위한 페이지에 이 접근법을 정리해 두었습니다.

기억할 규칙: 지점 하나에 페이지 하나, LocalBusiness 블록 하나, 그리고 비즈니스 프로필과 같은 상호, 주소, 전화번호, 영업시간. 추가하고, 검증하고, 비즈니스에 변화가 있을 때마다 업데이트하세요.