검색결과가 더 풍부해지는 이유: Schema 실전 가이드

Schema.org와 리치 결과는 같은 말이 아닙니다

Schema.org는 웹페이지의 사람, 조직, 제품, 글, 이벤트 같은 대상을 기계가 읽을 수 있게 설명하는 공용 어휘입니다. 검색엔진은 그중 일부 유형과 속성을 특정 검색 기능에 사용합니다.

따라서 Schema.org에 타입이 존재한다고 Google 리치 결과가 생기는 것은 아닙니다. 먼저 페이지 유형에 맞는 지원 기능을 찾고, 기능별 문서의 필수·권장 속성과 콘텐츠 정책을 확인합니다.

구조화 데이터는 보이는 사실을 다시 설명합니다

본문에 없는 평점, 재고, 가격, 저자를 마크업에만 추가하면 안 됩니다. 구조화 데이터는 검색엔진만을 위한 숨은 홍보 문구가 아니라 사용자가 실제로 확인할 수 있는 주 콘텐츠의 명시적 표현입니다.

한 페이지의 주 대상을 가장 구체적인 타입으로 표현하고 URL, 이미지, 날짜, 작성 주체를 실제 페이지 메타데이터와 일치시킵니다. 사이트 전체 템플릿에서 값이 어디서 오는지 추적할 수 있어야 합니다.

• Article: 글 제목·작성 주체·게시 및 수정일·대표 이미지
• BreadcrumbList: 실제 탐색 계층
• Organization: 일관된 이름·URL·로고·공식 프로필

JSON-LD를 템플릿 데이터에서 생성합니다

Google은 JSON-LD를 권장합니다. 화면 컴포넌트와 별개 블록으로 관리할 수 있지만 제목과 날짜를 복사해 두 개의 진실 원천을 만들지 말고 같은 콘텐츠 객체에서 HTML과 JSON-LD를 함께 생성합니다.

절대 URL과 ISO 날짜를 사용하고, 언어별 페이지는 해당 언어의 제목과 URL을 제공합니다. 배포 후 서버 HTML에 스크립트가 실제로 있는지도 확인해야 클라이언트 상태와 빌드 누락을 구분할 수 있습니다.

유효성, 적격성, 실제 노출을 따로 검증합니다

Schema Markup Validator는 어휘와 문법을, Rich Results Test는 Google 지원 기능의 적격성을 확인하는 데 유용합니다. 배포 후에는 URL 검사와 Search Console의 리치 결과 보고서로 크롤링된 결과를 봅니다.

모든 검사를 통과해도 Google은 검색 맥락, 기기, 위치, 품질 신호에 따라 일반 텍스트 결과를 선택할 수 있습니다. ‘코드는 유효함’과 ‘노출됨’을 분리해 기록하면 불필요한 재작업을 줄일 수 있습니다.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "검색결과가 더 풍부해지는 이유",
  "datePublished": "2026-08-24",
  "dateModified": "2026-08-24",
  "mainEntityOfPage": "https://example.com/ko/insights/schema-guide"
}
</script>

배포 전 체크리스트

• ✓ 페이지 유형과 Google이 지원하는 검색 기능이 실제로 맞는가?
• ✓ 마크업의 모든 주요 값이 보이는 본문과 일치하는가?
• ✓ HTML과 JSON-LD가 같은 콘텐츠 데이터에서 생성되는가?
• ✓ Validator와 Rich Results Test의 역할을 구분해 검사했는가?
• ✓ 배포된 서버 HTML과 Search Console 결과를 확인했는가?

자주 묻는 질문