LocalBusiness 구조화 데이터는 홈페이지에 보이는 상호·주소·전화번호·영업시간을 검색엔진이 일정한 형식으로 이해하도록 돕는 정보다. 코드를 넣었다고 검색 순위나 지식 패널 노출이 보장되지는 않지만, 실제 매장 정보와 일치하게 관리하면 검색로봇의 해석 오류를 줄일 수 있다. 이 글은 2026년 9월 4일 Google과 네이버 공식 문서를 확인해, 개발자가 없는 소상공인도 제작업체에 정확히 요청할 수 있는 순서로 정리했다.
핵심 요약: 코드를 쓰기 전에 매장 정보 원본표를 만든다
① 홈페이지에 보이는 정보를 한 장에 모은다 ② 실제 업종에 가장 가까운 유형을 고른다 ③ 필수값부터 넣고 권장값을 늘린다 ④ 지도·플레이스와 주소를 맞춘다 ⑤ 예외 영업시간을 구분한다 ⑥ 보이지 않는 정보와 가짜 평점을 넣지 않는다 ⑦ 테스트 후 일부 페이지부터 배포한다. 검색 노출을 꾸미는 코드가 아니라 공개된 사업정보를 설명하는 데이터로 접근해야 한다.
1. 홈페이지에 보이는 정보를 한 장으로 확정한다
상호, 도로명주소, 지역, 우편번호, 대표전화, 홈페이지 최종 주소, 평일·주말 영업시간, 대표 이미지를 표로 만든다. 홈페이지 본문, 네이버 플레이스, Google 비즈니스 프로필의 값이 다르면 코드부터 만들지 말고 실제 운영 기준을 먼저 확정한다. 예를 들어 간판은 ‘봄날카페’인데 구조화 데이터만 ‘광주 디저트 맛집 봄날카페’로 쓰면 검색어를 넣은 별도 상호가 되어 신뢰를 떨어뜨린다.
2. LocalBusiness보다 구체적인 업종 유형을 고른다
Google은 가능하면 Restaurant, Store, DaySpa처럼 실제 사업에 가까운 LocalBusiness 하위 유형을 사용하도록 안내한다. 여러 서비스를 제공한다고 관련 없는 유형을 나열하지 말고, 고객이 방문하는 주된 사업과 페이지 내용을 기준으로 고른다. 구조화 데이터는 업체 정보가 표시된 소개·매장안내 페이지에 두는 것이 관리하기 쉽다. 지점이 여러 곳이면 지점별 주소와 전화가 보이는 개별 페이지에 각각의 항목을 둔다.
3. 필수값 두 가지에서 권장값을 단계적으로 늘린다
Google의 LocalBusiness 문서에서 기본 필수 속성은 name과 실제 위치를 담는 address다. 처음에는 정확한 상호와 PostalAddress를 통과시키고, 이후 url·telephone·image·geo·openingHoursSpecification 등 운영에 필요한 권장 정보를 추가한다. 속성 개수를 늘리기 위해 확인되지 않은 위도·경도나 가격대를 추정하지 않는다. 주소가 없는 온라인 전용 사업이라면 지역 매장처럼 보이게 LocalBusiness를 억지로 쓰지 말고 Organization 등 실제 형태에 맞는 유형을 검토한다.
4. 주소·전화·URL은 고객이 도착하는 최종값으로 맞춘다
address에는 도로명주소, 지역, 우편번호, 국가 정보를 가능한 범위에서 분리해 적고, telephone은 고객이 실제 연결할 대표번호를 사용한다. url과 image는 로그인 없이 열리는 HTTPS 절대주소로 입력한다. www 주소가 루트 도메인으로 이동한다면 리디렉션 전 주소 대신 canonical이 가리키는 최종 주소를 쓴다. 지도 핀의 위도·경도는 건물 중앙이 아니라 실제 출입구와 지점 위치를 확인한 뒤 사용한다.
5. 영업시간은 정규·심야·임시휴무를 구분한다
요일별 opens와 closes를 실제 주문·방문 가능 시간으로 적는다. 자정을 넘는 영업은 한 영업 구간으로 표현할 수 있지만 날짜가 바뀌는 지점을 잘못 나누면 검색정보가 실제 운영과 달라진다. 계절 영업이나 연휴 휴점처럼 기간이 정해진 예외는 validFrom과 validThrough 적용 여부를 확인한다. 매주 바뀌는 예약 가능 시간까지 구조화 데이터에 억지로 넣지 말고, 안정적으로 관리할 수 있는 정규 영업시간부터 반영한다.
6. 화면에 없는 평점·서비스·제휴 정보는 넣지 않는다
구조화 데이터의 값은 방문자가 같은 페이지에서 확인할 수 있어야 한다. 다른 플랫폼의 리뷰 수를 복사하거나 자체 리뷰가 없는데 aggregateRating을 만들어 넣으면 안 된다. 실제 제공하지 않는 예약, 배달, 24시간 영업, 공식 제휴도 금지한다. Google은 숨겨진 정보, 가짜 리뷰, 관련 없는 데이터, 소유권이나 제휴를 왜곡하는 마크업을 품질 위반으로 본다. 오류가 없는 코드보다 사실과 일치하는 코드가 우선이다.
7. 테스트 통과 후 일부 페이지부터 배포한다
JSON-LD는 Google과 네이버가 지원하는 형식이며 기존 화면 디자인을 크게 바꾸지 않고 적용할 수 있다. 먼저 리치 검색결과 테스트와 schema.org 검사 도구로 문법을 확인하고, 오류는 배포 전에 해결한다. 경고는 실제로 제공할 수 있는 권장값인지 판단해 보완한다. 대표 지점 한 페이지에 먼저 적용한 뒤 URL 검사에서 Googlebot 접근, robots.txt, noindex, 이미지 접근을 확인하고 문제가 없을 때 다른 지점으로 넓힌다.
30분 실행표와 발행 중단 기준
첫 10분은 홈페이지·지도·플레이스의 상호·주소·전화·시간을 대조하고, 다음 5분은 업종 유형과 적용 페이지를 정한다. 이어 10분은 name·address부터 JSON-LD를 만들고 url·telephone·image·영업시간을 추가한다. 마지막 5분은 테스트 도구와 모바일 공개 화면을 함께 확인한다. 정보 원본이 서로 다르거나 가짜 평점을 요구받거나 수정 담당자가 정해지지 않았다면 발행을 중단하고 운영정보부터 바로잡는다. 정상 마크업도 검색 노출을 보장하지 않는다는 점을 기록한다.