숙소⁠·가게 구조화 데이터,
무엇을 어떻게 넣을까

왜 필요한가요

사람은 “15:00”이 체크인 시간이라는 걸 앞뒤 문맥으로 압니다. 기계는 그 문맥을 놓칠 수 있습니다. 구조화 데이터는 같은 정보를 정해진 형식으로 한 번 더 적어, 검색엔진과 AI가 헷갈리지 않게 해 줍니다.

다만 과장하면 안 됩니다. 구글은 AI 개요와 AI 모드에 나오기 위해 특별한 구조화 데이터가 필요하지 않다고 안내합니다. 구조화 데이터는 정확한 화면 글을 돕는 도구입니다.

어떤 형식을 쓰나요

숙소 예시

아래는 가상의 숙소입니다. 우리 정보로 바꿔 홈페이지 <head> 안에 넣으면 됩니다.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Hotel",
  "name": "○○호텔",
  "alternateName": "Hotel ○○",
  "url": "https://example.com/",
  "telephone": "+82-2-000-0000",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "○○로 00",
    "addressLocality": "서울특별시 ○○구",
    "postalCode": "00000",
    "addressCountry": "KR"
  },
  "checkinTime": "15:00",
  "checkoutTime": "11:00",
  "numberOfRooms": 30,
  "petsAllowed": false,
  "amenityFeature": [
    { "@type": "LocationFeatureSpecification", "name": "주차", "value": true },
    { "@type": "LocationFeatureSpecification", "name": "조식", "value": true }
  ],
  "sameAs": [
    "https://www.instagram.com/○○",
    "https://map.naver.com/○○"
  ]
}
</script>

sameAs에는 공식 인스타그램, 지도 페이지처럼 같은 숙소를 가리키는 공식 주소를 넣습니다. 여러 곳에 흩어진 정보가 한 숙소라는 걸 알려 주는 연결 고리입니다.

식당 예시

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "name": "○○식당",
  "url": "https://example.com/",
  "telephone": "+82-2-000-0000",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "○○로 00",
    "addressLocality": "서울특별시 ○○구",
    "addressCountry": "KR"
  },
  "servesCuisine": "베트남 음식",
  "priceRange": "₩₩",
  "acceptsReservations": true,
  "menu": "https://example.com/menu/",
  "openingHoursSpecification": [
    { "@type": "OpeningHoursSpecification", "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"], "opens": "11:00", "closes": "21:00" },
    { "@type": "OpeningHoursSpecification", "dayOfWeek": ["Saturday","Sunday"], "opens": "10:00", "closes": "22:00" }
  ]
}
</script>

자주 하는 실수

1. 화면과 다른 내용. 화면에는 “주차 불가”인데 코드에는 주차 가능으로 남아 있는 경우입니다. 구글은 구조화 데이터가 화면 글과 맞아야 한다고 안내합니다.
2. 바뀐 정보를 코드에만 안 고침. 영업시간을 바꿀 때 화면 글만 고치고 코드는 그대로 두는 일이 많습니다. 관리자 화면에서 한 번 고치면 둘 다 바뀌게 만들어 두는 게 가장 안전합니다.
3. 스스로 단 별점. 가게가 직접 매긴 평점이나 골라 넣은 후기를 리뷰 형식으로 표시하는 건 구글 리치 결과 대상이 아닙니다.
4. 여러 개가 서로 다름. 플러그인 두 개가 각각 다른 주소를 넣어 두는 경우가 있습니다. 한 페이지에 같은 대상을 다르게 설명하는 코드가 없는지 봅니다.

검사 도구

• Google 리치 결과 테스트: 구글이 읽을 수 있는지, 오류가 없는지 확인합니다.
• Schema Markup Validator: schema.org 형식에 맞는지 확인합니다.

넣은 뒤에는 두 도구로 한 번씩 검사하고, 정보를 바꿀 때마다 다시 확인하세요.

자주 묻는 질문

참고한 자료

• Google 검색 센터 · 구조화 데이터 소개
• Google 검색 센터 · 지역 비즈니스 구조화 데이터
• Google 검색 센터 · AI 기능과 웹사이트
• schema.org · Hotel
• schema.org · Restaurant
• Google 리치 결과 테스트
• Schema Markup Validator

사례와 의견은 아웃픽이 직접 진행한 숙소⁠·가게 프로젝트에서 나왔습니다. 마지막 확인 2026년 11월 6일.