Schema.org JSON-LD SEO 실전 — 리치 스니펫 적용과 구조화 데이터 검증 가이드
검색 엔진에서 같은 키워드를 검색했을 때 어떤 글은 별점·평점·이미지·FAQ 토글까지 함께 노출되고, 다른 글은 단순 텍스트만 보이는 차이를 본 적이 있을 것이다. 이 차이를 만드는 것이 구조화 데이터(Structured Data) 이고, 그 표준 어휘가 Schema.org다. Schema.org는 Google·Microsoft·Yahoo·Yandex가 2011년 공동 출범시킨 웹 시맨틱 표준으로, 현재 800개 이상의 타입과 1,500개 이상의 속성을 정의하고 있다.
페이지 안에 JSON-LD 한 블록만 잘 넣어도 구글 검색 결과에 리치 스니펫이 노출되고, 그 결과 클릭률(CTR)이 30～80% 가까이 오르는 사례가 흔하다. 이 글은 Schema.org와 JSON-LD의 기본 구조, 가장 자주 쓰이는 6가지 타입(Article·Product·FAQ·Recipe·BreadcrumbList·Organization), 검증 방법, 그리고 적용 시 자주 만나는 함정까지 한 번에 정리한다.
이 글의 구성
01 Schema.org와 JSON-LD 개요
| 항목 | 내용 |
|---|---|
| Schema.org | 웹용 구조화 데이터 표준 어휘 (2011 Google·MS·Yahoo 공동 출범, 11월 Yandex 합류) |
| 규모 | 800+ Types · 1,500+ Properties |
| JSON-LD | JSON 기반 Linked Data 직렬화 (W3C 권고) |
| 권장 형식 | Google이 JSON-LD를 공식 권장 (Microdata·RDFa보다 우선) |
| 삽입 위치 | <head> 또는 <body>의 <script type="application/ld+json"> 블록 |
Schema.org는 웹 페이지가 무엇을 다루는지 검색 엔진에게 기계가 읽을 수 있는 형태로 알려 주는 어휘다. JSON-LD는 그 어휘를 JSON 형식으로 표현하는 직렬화 방식이고, 페이지 HTML에 <script> 태그 안에 삽입하면 끝이다. 본문 HTML 구조를 바꾸지 않아도 되고, 모바일·반응형에 영향을 주지 않는다는 점이 다른 구조화 방식(Microdata·RDFa) 대비 큰 장점이다.
02 JSON-LD 기본 구조
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Schema.org JSON-LD SEO 실전",
"datePublished": "2026-05-19",
"author": {
"@type": "Person",
"name": "홍길동"
}
}
</script>필수 키 세 가지가 있다. @context는 Schema.org URL로 고정, @type은 어떤 타입인지 지정, 그 외 속성은 타입별로 정해진 표준 속성을 채워 넣는다. 중첩이 가능해 작가·이미지·평점 같은 하위 구조도 자연스럽게 표현된다.
03 자주 쓰는 6가지 타입과 예시
Article · BlogPosting
블로그·뉴스 글. headline·datePublished·author·image·publisher 필수. 리치 스니펫 효과 가장 큼.
Product · Offer
상품 페이지. name·image·offers(price·availability)·aggregateRating 핵심. 별점·가격 노출.
FAQPage
자주 묻는 질문. mainEntity의 Question·acceptedAnswer 구조. 검색 결과에 토글 형식으로 노출.
Recipe
레시피. recipeIngredient·recipeInstructions·cookTime·nutrition 등. 요리 이미지·조리 시간·별점 노출.
BreadcrumbList
사이트 내비게이션 빵 부스러기. itemListElement 안에 ListItem 배열. 검색 결과 URL 위에 경로 노출.
Organization · LocalBusiness
조직·매장 정보. name·logo·address·sameAs(SNS 링크). 지식 패널·로고 노출 토대.
Article 예시 — 가장 많이 쓰는 형태
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "Schema.org JSON-LD SEO 실전 가이드",
"image": ["https://example.com/cover.jpg"],
"datePublished": "2026-05-19",
"dateModified": "2026-05-19",
"author": { "@type": "Person", "name": "홍길동" },
"publisher": {
"@type": "Organization",
"name": "내 블로그",
"logo": { "@type": "ImageObject", "url": "https://example.com/logo.png" }
},
"mainEntityOfPage": "https://example.com/article-url"
}
</script>FAQPage 예시 — 토글 노출
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "JSON-LD를 어디에 넣어야 하나요?",
"acceptedAnswer": {
"@type": "Answer",
"text": "head 또는 body 어디에 넣어도 됩니다."
}
}
]
}04 검증 도구 — Rich Results Test·Schema Markup Validator
Rich Results Test
search.google.com/test/rich-results
Google이 제공. 실제 리치 스니펫 미리보기까지 보여 줌. 적용 후 가장 먼저 확인할 도구.
Schema Markup Validator
validator.schema.org
Schema.org 공식. 모든 타입 문법 검증. Rich Results와 무관한 일반 시맨틱 마크업도 확인 가능.
운영 단계에서는 Google Search Console의 "향상 보고서(Enhancements)" 섹션도 함께 본다. 사이트 전체의 구조화 데이터 오류·경고를 일괄 모니터링할 수 있고, 색인 후 실제 노출 상태와 클릭률까지 추적된다.
05 자주 만나는 함정과 모범 사례
⚠️ 함정 5가지
본문에 없는 정보 마크업 — 페이지에 표시되지 않는 내용을 JSON-LD에만 넣으면 정책 위반으로 노출 차단.
이미지 누락 — Article·Product는 image 필수. 1×1·4×3·16×9 비율 권장.
publisher logo 가로 600px 이상 권장. 너무 작으면 노출 불가.
중복·중첩 오류 — 한 페이지에 동일 타입 중복 또는 닫는 괄호 누락.
가격 통화 누락 — Product Offer의 priceCurrency(ISO 4217) 필수.
모범 사례는 단순하다. 페이지에 실제로 표시된 정보만 마크업하고 본문에 없는 내용은 절대 넣지 않는다. 엔티티마다 @id로 식별자를 명확히 부여해 다른 마크업과 자연스럽게 연결되도록 두고, 이미지는 절대 URL과 권장 비율을 지킨 절대 경로로 작성한다. 적용 후에는 Rich Results Test로 1차 검증하고 Search Console에서 노출·오류 상태를 사후 모니터링하는 흐름이 안전하다.
06 SEO 효과·CTR과 측정 지표
리치 스니펫 적용 후 일반적으로 관찰되는 효과는 다음과 같다. 구글 공식 사례와 SEO 업계 보고를 종합하면 클릭률(CTR) 30～80% 증가, 검색 결과 노출 영역 확대, 음성 검색 답변 후보 진입 등이 핵심 변화다. 단, 구조화 데이터가 직접적인 순위 상승을 보장하지는 않는다. 어디까지나 동일 순위에서 더 눈에 띄게 노출되는 효과이며, 콘텐츠 품질이 결국 결정적 요인이다.
측정해야 할 KPI는 CTR(Search Console 노출 대비 클릭), 평균 게재 순위, 리치 결과 노출 횟수, 음성 검색 답변 포함 여부 네 가지다. 구조화 데이터 적용 전후 4～8주 데이터를 비교해 효과를 측정하는 것이 가장 정확하다.
07 자주 묻는 질문 5가지
Q1. JSON-LD를 head·body 중 어디에 넣어야 하나?
둘 다 가능하다. Google은 둘 다 인식하지만 head에 두는 것이 일반적이고 관리가 편하다. 동적 페이지라면 body에 두는 경우도 흔하다.
Q2. Microdata·RDFa 대신 JSON-LD를 권장하는 이유는?
HTML 구조를 바꾸지 않고 별도 스크립트 블록에만 작성하면 되므로 유지·관리가 훨씬 쉽다. Google이 공식적으로 JSON-LD를 권장하며, 동적 사이트에서도 자바스크립트로 동적 삽입이 자연스럽다. Microdata·RDFa는 HTML 속성을 채워야 해 유지가 번거롭다.
Q3. 모든 페이지에 마크업을 다 해야 하나?
아니다. 검색 노출이 중요한 핵심 페이지부터 시작해 점진적으로 확장한다. 블로그라면 글 페이지에 BlogPosting + BreadcrumbList, 쇼핑몰이라면 상품 페이지에 Product + Offer를 우선 적용한다.
Q4. 마크업했는데 리치 스니펫이 안 보인다.
색인까지 시간이 걸린다(보통 며칠～몇 주). Rich Results Test에서 적격 판정을 받았다면 Search Console "URL 검사"로 색인 재요청하고 기다린다. 노출 여부는 Google이 페이지 품질·신뢰도와 함께 종합 판단하므로 100% 보장되지는 않는다.
Q5. FAQ 마크업이 줄어들었다는데 사실인가?
맞다. Google이 2023년 8월부터 FAQ·HowTo 리치 스니펫을 신뢰도 높은 정부·의료 사이트 위주로 제한했다. 일반 블로그·쇼핑몰에서는 노출이 줄었지만, FAQ 마크업 자체는 여전히 페이지 의미를 전달하는 데 유효하다. 음성 검색·향후 정책 변화에 대비해 두는 의미는 있다.
마무리
Schema.org와 JSON-LD는 SEO에서 가장 진입 비용이 낮으면서 효과가 큰 영역 중 하나다. 페이지 안에 스크립트 블록 하나만 잘 넣어도 리치 스니펫·빵 부스러기·지식 패널 같은 부가 노출이 따라온다. 핵심은 페이지 본문에 실제로 표시된 정보만 정확하게 마크업하는 것, 그리고 Rich Results Test로 검증한 뒤 Search Console에서 사후 모니터링하는 흐름이다.
블로그라면 BlogPosting + BreadcrumbList부터, 쇼핑몰이라면 Product + Offer + AggregateRating부터, 비즈니스 페이지라면 Organization + LocalBusiness부터 시작하는 것이 가장 효율적이다. 모든 페이지를 한 번에 마크업하기보다 트래픽이 큰 핵심 페이지부터 점진적으로 적용하면서 KPI를 측정해 가는 흐름이 운영 측면에서 안전하다.
Schema.org JSON-LD 적용 체크리스트
본 글은 Schema.org와 JSON-LD를 활용한 구조화 데이터 SEO 실전 가이드다. Google·Schema.org 정책과 리치 스니펫 노출 기준은 변동될 수 있으므로 schema.org·Google Search Central 공식 문서의 최신 가이드를 직접 확인한다.
#SchemaOrg #JSONLD #StructuredData #RichResults #SEO #GoogleSearch #BlogPosting #Article #Product #FAQPage #BreadcrumbList #Organization #RichSnippet #SearchConsole #LinkedData
'IT' 카테고리의 다른 글
| Protégé 0부터 튜토리얼 — 가족 관계 온톨로지 만들고 HermiT·Pellet 추론기 돌리기 (0) | 2026.05.20 |
|---|---|
| OWL 2 프로파일 완전 비교 — EL·QL·RL 언제 무엇을 쓰는가 선택 가이드 (0) | 2026.05.20 |
| RDF·SPARQL 실전 입문 — Apache Jena Fuseki로 트리플 만들고 쿼리하기 완전 가이드 (0) | 2026.05.19 |
| 온톨로지가 뭐야 — RDF·OWL·SPARQL·지식 그래프·LLM RAG 완전 정리 (0) | 2026.05.19 |
| ORA-00918 column ambiguously defined — 조인 컬럼 모호 에러 원인·해결·예방 완전 정리 (0) | 2026.05.19 |
댓글