LocalBusiness 스키마 설정 가이드 · 로컬 SEO에서 확인할 핵심 항목

지역명을 포함해 업체를 검색하는 사용자는 매장 위치, 전화번호, 영업시간, 서비스 지역처럼 바로 행동으로 이어질 수 있는 정보를 빠르게 확인하려는 경우가 많습니다. 이때 홈페이지에 표시된 사업자 정보를 검색엔진이 구조적으로 해석할 수 있도록 돕는 방법 중 하나가 LocalBusiness 구조화 데이터입니다.

LocalBusiness 스키마는 특정 지역에서 운영되는 실제 사업체나 지점을 구조화해 설명하는 Schema.org 유형입니다. 사업자명, 주소, 전화번호, 영업시간 같은 정보를 기계가 읽기 쉬운 형태로 전달할 수 있지만, 스키마를 추가했다고 검색 순위가 자동으로 오르거나 리치 결과가 반드시 노출되는 것은 아닙니다.

실무에서 더 중요한 것은 스키마 자체보다 홈페이지에 보이는 정보, Google Business Profile 등 외부 비즈니스 정보, 구조화 데이터가 서로 충돌하지 않도록 관리하는 것입니다. LocalBusiness 스키마는 로컬 SEO를 대신하는 장치가 아니라, 실제 사업 정보를 명확하게 정리하는 데이터 계층으로 보는 편이 정확합니다.

LocalBusiness 스키마는 로컬 SEO에서 어떤 역할을 할까?

Google은 구조화 데이터를 페이지의 내용을 분류하고 이해하기 위한 표준화된 형식으로 설명합니다. LocalBusiness 구조화 데이터를 사용하면 검색엔진에 사업체의 이름, 실제 위치, 전화번호, 영업시간 등과 같은 정보를 명시적으로 제공할 수 있습니다.

반면 로컬 검색 결과의 순위는 구조화 데이터 하나로 결정되지 않습니다. Google Business Profile 도움말에서는 로컬 결과가 주로 관련성, 거리, 인지도에 기반한다고 안내합니다. 따라서 스키마는 이 세 요소를 직접 조정하는 순위 버튼이 아니라, 사이트에 존재하는 사업 정보를 더 명료하게 전달하는 수단에 가깝습니다.

실무에서는 다음 세 가지를 구분해서 관리하는 것이 좋습니다.

• 홈페이지 콘텐츠: 사용자가 실제로 읽는 업체·지점·서비스 정보
• 비즈니스 프로필: 지도와 로컬 검색에서 활용되는 업체 정보
• 구조화 데이터: 페이지의 사업 정보를 검색엔진이 해석하기 쉬운 형태로 표현한 데이터

세 영역의 정보가 실제 운영 정보와 맞아야 합니다. 스키마만 최신이고 본문 주소가 예전 주소이거나, 홈페이지 전화번호와 비즈니스 프로필 전화번호가 서로 다르면 사용자의 신뢰도도 떨어질 수 있습니다.

설정 전에 먼저 정리해야 할 사업자 정보

LocalBusiness 스키마를 작성하기 전에 코드부터 만드는 것은 효율적이지 않습니다. 먼저 어떤 사업체 또는 지점을 표현할 것인지 정하고, 그 페이지에서 실제로 보여주는 정보를 기준으로 데이터 항목을 확정해야 합니다.

1. 사업자명

name에는 실제 고객에게 사용하는 업체명 또는 지점명을 입력합니다. 페이지 본문, 연락처 영역, 비즈니스 프로필 등에서 서로 다른 이름을 임의로 사용하기보다 하나의 기준 명칭을 정해 관리하는 편이 좋습니다.

키워드를 추가하려는 목적으로 실제 상호와 무관한 지역명이나 서비스명을 과도하게 덧붙이는 방식은 피해야 합니다.

2. 주소

Google의 LocalBusiness 리치 결과 문서에서 address는 필수 속성으로 안내됩니다. 주소는 PostalAddress 유형으로 구성하며, 실제 사업장 위치를 기준으로 세부 정보를 입력합니다.

예를 들어 다음과 같이 나눌 수 있습니다.

• streetAddress: 도로명과 상세 주소
• addressLocality: 시·군·구 또는 지역
• addressRegion: 시·도
• postalCode: 우편번호
• addressCountry: 국가 코드

표기 형식보다 중요한 것은 실제 정보와의 일치입니다. 존재하지 않는 주소나 검색 노출만을 위한 가상의 지점 정보를 넣어서는 안 됩니다.

3. 전화번호와 URL

telephone과 url은 Google의 LocalBusiness 문서에서 권장 속성으로 안내됩니다. 전화번호는 실제 고객 문의에 사용하는 대표 연락처를 기준으로 작성하고, URL은 해당 사업체 또는 지점을 설명하는 정상 작동 페이지를 연결하는 것이 좋습니다.

여러 지점을 운영한다면 모든 지점이 하나의 대표 페이지를 공유하는 방식보다, 지점별 정보가 충분히 다를 경우 각 지점을 설명하는 고유 페이지와 데이터를 연결하는 편이 관리하기 쉽습니다.

4. 영업시간

openingHoursSpecification을 이용하면 요일별 영업시간을 구조화할 수 있습니다. 홈페이지 본문에는 평일 09:00~18:00이라고 적혀 있는데 스키마에는 10:00~19:00으로 남아 있는 식의 불일치가 생기지 않도록 관리해야 합니다.

공휴일이나 계절별 운영시간이 자주 달라지는 업종이라면 구조화 데이터만 수정하고 끝내기보다 홈페이지의 실제 안내 정보도 함께 업데이트하는 것이 안전합니다.

어떤 @type을 선택해야 할까?

모든 업체가 단순히 LocalBusiness만 사용할 필요는 없습니다. Schema.org에는 LocalBusiness 아래에 다양한 세부 유형이 있으며, Google 역시 가능한 경우 가장 구체적인 LocalBusiness 하위 유형을 사용하는 방식을 안내합니다.

예를 들면 업종에 따라 다음과 같은 유형을 검토할 수 있습니다.

• 음식점: Restaurant
• 부동산 중개업: RealEstateAgent
• 법률 서비스: LegalService
• 치과: Dentist
• 매장형 소매업: Store
• 이사업체: MovingCompany

중요한 점은 검색 노출에 유리할 것 같은 유형을 임의로 선택하는 것이 아니라 실제 사업의 성격과 일치하는 유형을 사용하는 것입니다. 적절한 세부 유형이 명확하지 않다면 무리하게 잘못된 하위 유형을 적용하기보다 LocalBusiness를 기준으로 정확한 사업 정보를 구성하는 편이 낫습니다.

JSON-LD로 작성하는 LocalBusiness 기본 예시

Google은 구조화 데이터 형식으로 JSON-LD, Microdata, RDFa를 지원하며 그중 JSON-LD를 권장 형식으로 안내합니다. HTML 본문과 분리해 관리하기 쉽고, 워드프레스 플러그인이나 직접 삽입 방식에서도 비교적 수정이 편리합니다.

아래 코드는 구조를 설명하기 위한 예시입니다. 업체명, 주소, 전화번호, URL, 영업시간은 반드시 실제 운영 정보로 교체해야 합니다.

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "브랜드명 또는 지점명",
  "url": "https://www.example.com/location/",
  "telephone": "+82-2-1234-5678",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "실제 도로명 및 상세 주소",
    "addressLocality": "시·군·구",
    "addressRegion": "시·도",
    "postalCode": "우편번호",
    "addressCountry": "KR"
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": [
        "Monday",
        "Tuesday",
        "Wednesday",
        "Thursday",
        "Friday"
      ],
      "opens": "09:00",
      "closes": "18:00"
    }
  ]
}

Google의 현재 LocalBusiness 문서에서 리치 결과 적격성을 위한 필수 속성은 name과 address입니다. telephone, url, openingHoursSpecification, geo, priceRange 등은 상황에 맞게 추가할 수 있는 권장 항목입니다.

필수 항목만 채웠다고 좋은 구현이 완성되는 것은 아닙니다. 실제 페이지에서 사용자에게 제공하는 정보와 일치하면서 사업체를 설명하는 데 필요한 항목을 충분히 구성하는 것이 중요합니다.

NAP 일관성은 ‘한 글자 통일’보다 실제 정보 정합성이 먼저다

로컬 SEO에서 NAP는 보통 Name, Address, Phone을 뜻합니다. 실무에서는 홈페이지, 연락처 페이지, 지점 페이지, Google Business Profile 등 여러 위치에 동일한 사업 정보가 표시되기 때문에 관리 기준을 하나로 잡아두는 것이 편합니다.

다만 NAP를 모든 사이트에서 한 글자도 다르지 않게 만들어야만 검색 순위가 오른다는 식으로 이해할 필요는 없습니다. 핵심은 서로 다른 업체처럼 보일 정도의 충돌을 만들지 않고, 고객이 확인하는 사업자명·주소·전화번호가 실제 운영 정보와 일관되게 유지되도록 하는 것입니다.

예를 들어 아래와 같은 상태는 점검이 필요합니다.

• 홈페이지는 이전 주소인데 비즈니스 프로필은 새 주소인 경우
• 지점 페이지와 구조화 데이터의 대표 전화번호가 다른 경우
• 폐업한 지점의 주소가 사이트 푸터나 스키마에 남아 있는 경우
• 동일 업체를 페이지마다 서로 다른 상호명으로 표시하는 경우
• 영업시간 변경 후 본문만 수정하고 구조화 데이터는 그대로 둔 경우

스키마 작업을 시작하기 전에 이런 정보부터 정리하면 이후 유지보수도 훨씬 쉬워집니다.

홈페이지에 적용할 때 자주 놓치는 부분

LocalBusiness 스키마는 코드를 한 번 넣는 것으로 끝나는 작업이 아닙니다. 실제 사이트 구조와 플러그인 설정까지 함께 확인해야 합니다.

플러그인과 직접 삽입 코드가 중복되지 않는지 확인

워드프레스에서는 SEO 플러그인이나 스키마 플러그인이 이미 Organization 또는 LocalBusiness 데이터를 출력하고 있을 수 있습니다. 여기에 별도의 코드 스니펫이나 테마 코드로 비슷한 데이터를 다시 넣으면 동일한 사업체 정보가 여러 객체로 생성될 수 있습니다.

복수의 구조화 데이터가 존재하는 것 자체가 항상 오류를 의미하는 것은 아니지만, 동일한 사업체를 서로 다른 주소나 전화번호로 중복 정의하면 데이터가 불명확해집니다.

따라서 새 코드를 추가하기 전에 현재 페이지 소스에서 어떤 JSON-LD가 이미 출력되는지 먼저 확인하는 것이 좋습니다.

스키마 내용은 페이지에 보이는 정보와 맞춰야 한다

구조화 데이터에는 상세한 영업시간과 주소가 들어가 있는데 페이지 본문에서는 해당 정보를 전혀 확인할 수 없다면 좋은 구현이라고 보기 어렵습니다.

Google의 일반 구조화 데이터 가이드라인은 마크업이 페이지의 실제 내용을 대표해야 하고, 사용자에게 보이지 않는 내용을 부적절하게 마크업해서는 안 된다고 안내합니다.

따라서 지점 페이지라면 최소한 사용자가 사업체의 위치, 연락처, 운영 정보 등을 실제 페이지에서도 확인할 수 있도록 구성하는 것이 좋습니다.

리뷰와 평점을 임의로 추가하지 않는다

review나 aggregateRating은 별점이 검색 결과에 표시되기를 기대하고 무조건 넣는 항목이 아닙니다. Google의 LocalBusiness 문서는 다른 로컬 비즈니스에 대한 리뷰를 수집하는 사이트를 대상으로 해당 속성을 권장하고 있으며, 리뷰 스니펫에도 별도의 가이드라인이 적용됩니다.

실제 근거가 없는 평점이나 임의로 만든 리뷰 데이터를 구조화해서는 안 됩니다. 리뷰 데이터는 페이지의 실제 콘텐츠와 정책 요건을 함께 검토해야 합니다.

적용 후 검증은 두 단계로 진행한다

구조화 데이터는 문법 오류가 없어 보여도 실제 검색엔진이 페이지를 읽는 과정에서 문제가 발견될 수 있습니다. 적용 후에는 최소한 다음 두 단계를 확인하는 것이 좋습니다.

1. Rich Results Test

Google Rich Results Test에서 URL 또는 코드를 검사해 LocalBusiness 관련 구조화 데이터가 어떻게 인식되는지 확인합니다.

치명적인 오류가 있다면 먼저 수정하고, 권장 속성에 대한 경고는 해당 페이지와 업종에 필요한 항목인지 판단해 보완합니다.

테스트를 통과했다는 사실은 검색 결과 노출을 보장한다는 의미가 아닙니다. 구조화 데이터가 기술적으로 적격한 상태인지 확인하는 절차로 이해해야 합니다.

2. Search Console URL 검사

실제 페이지를 배포한 뒤에는 Search Console의 URL 검사 기능으로 Google이 해당 페이지에 접근하고 렌더링할 수 있는지 확인합니다.

robots.txt, noindex, 로그인 제한 등으로 페이지 접근이 막혀 있다면 구조화 데이터를 잘 작성해도 Google이 정상적으로 활용하기 어렵습니다. 수정 후에는 재크롤링과 재색인에 시간이 필요할 수 있으므로 즉시 노출 여부만으로 구현 성공 여부를 판단하지 않는 것이 좋습니다.

LocalBusiness 스키마와 함께 점검할 로컬 SEO 항목

LocalBusiness 스키마만 적용하고 로컬 SEO 작업이 끝났다고 판단해서는 안 됩니다. Google은 로컬 결과가 관련성, 거리, 인지도 등의 요소에 주로 기반한다고 설명합니다.

실무에서는 다음 항목을 함께 관리하는 편이 좋습니다.

• Google Business Profile의 업체명, 주소, 전화번호, 영업시간을 최신 상태로 유지
• 실제 제공 서비스와 업종 정보를 충분하고 정확하게 작성
• 지점별 페이지가 있다면 각 지역에서 필요한 정보와 차이를 명확히 제공
• 주소, 연락처, 영업시간 등 핵심 정보를 모바일에서도 쉽게 확인할 수 있도록 구성
• 단순 지역명 반복보다 실제 서비스 범위, 방문 방법, 지점 특성 등 사용자에게 필요한 정보를 제공
• 구조화 데이터와 화면에 보이는 사업 정보를 함께 업데이트
• 수정 후 Rich Results Test와 Search Console에서 다시 확인

지역명과 키워드를 많이 넣는 것보다 실제 고객이 해당 지점을 선택하거나 방문하는 데 필요한 정보를 정확하게 제공하는 것이 우선입니다.

실무 체크리스트

LocalBusiness 스키마를 적용하거나 수정할 때 아래 항목을 순서대로 확인하면 누락을 줄일 수 있습니다.

• 이 페이지가 어떤 실제 사업체 또는 지점을 설명하는지 명확한가?
• @type이 실제 업종과 일치하는가?
• name과 address가 실제 사업 정보와 일치하는가?
• 전화번호와 URL이 현재 사용하는 정보인가?
• 영업시간이 홈페이지와 구조화 데이터에서 일치하는가?
• 여러 지점이 있다면 지점별 정보가 섞이지 않았는가?
• SEO 플러그인과 직접 삽입 코드가 충돌하거나 중복되지 않는가?
• 스키마에 적은 정보가 페이지에서도 사용자에게 확인 가능한가?
• 근거 없는 리뷰나 평점을 구조화하지 않았는가?
• Rich Results Test에서 치명적인 오류를 확인했는가?
• Search Console에서 Google의 페이지 접근 상태를 확인했는가?
• 주소나 연락처 변경 시 스키마까지 함께 수정하는 운영 절차가 있는가?

자주 묻는 질문

LocalBusiness 스키마를 넣으면 지역 검색 순위가 올라가나요?

구조화 데이터 적용만으로 순위 상승이 보장되지는 않습니다. Google은 로컬 검색 결과가 주로 관련성, 거리, 인지도에 기반한다고 설명합니다. LocalBusiness 스키마는 사업 정보를 구조적으로 전달하는 데 활용할 수 있지만, 콘텐츠 품질과 비즈니스 프로필 관리 등 다른 로컬 SEO 요소를 대신하지 않습니다.

JSON-LD만 사용해야 하나요?

반드시 JSON-LD만 사용해야 하는 것은 아닙니다. Google은 JSON-LD, Microdata, RDFa를 지원하며 JSON-LD를 권장 형식으로 안내합니다. 새로 구축하거나 유지보수 편의성을 고려한다면 JSON-LD가 실무적으로 다루기 편한 경우가 많습니다.

여러 지점을 운영하면 LocalBusiness를 하나만 넣으면 되나요?

Google은 각 로컬 비즈니스 위치를 각각 LocalBusiness 유형으로 정의하도록 안내합니다. 지점별 주소, 전화번호, 영업시간 등이 다르다면 각 지점을 설명하는 페이지와 구조화 데이터를 구분해 관리하는 방식이 적합합니다.

NAP는 모든 사이트에서 한 글자까지 똑같아야 하나요?

핵심은 문자 단위의 기계적인 통일보다는 실제 사업 정보를 혼동 없이 일관되게 관리하는 것입니다. 오래된 주소, 다른 전화번호, 서로 다른 상호처럼 고객이나 플랫폼이 다른 사업체로 오해할 수 있는 충돌부터 우선 정리하는 것이 좋습니다.

Rich Results Test에 통과하면 검색 결과에 반드시 표시되나요?

아닙니다. Google은 구조화 데이터가 올바르게 작성되어도 검색 결과의 특정 기능 노출을 보장하지 않는다고 명시합니다. 테스트 통과는 기술적 요건을 확인하는 단계이며 실제 검색 결과 표현은 여러 조건에 따라 달라질 수 있습니다.

결론: 스키마보다 먼저 ‘실제 사업 정보’를 정리해야 한다

LocalBusiness 스키마의 목적은 검색 순위를 만드는 데 있지 않습니다. 실제 사업체와 지점 정보를 검색엔진이 이해하기 쉬운 형태로 명확하게 표현하는 것이 핵심입니다.

가장 먼저 사업자명, 주소, 전화번호, 영업시간, 지점 URL을 정리하고 홈페이지와 비즈니스 프로필의 정보를 맞춘 뒤, 그 내용을 JSON-LD로 구조화하는 순서가 효율적입니다.

구현 후에는 Rich Results Test와 Search Console을 통해 오류와 접근 상태를 확인하고, 사업 정보가 변경될 때 구조화 데이터도 함께 갱신해야 합니다. 이렇게 관리하면 LocalBusiness 스키마를 단발성 SEO 기법이 아니라 로컬 비즈니스 정보 관리 체계의 일부로 활용할 수 있습니다.