구조화 데이터는 SEO에서 원인과 결과가 가장 분명한 영역입니다. 페이지를 기계가 읽을 수 있는 어휘로 설명하면, 검색엔진과 AI 답변 엔진이 그 설명을 사용해 페이지를 더 풍부하게 표시하고 인용합니다. 적용 여부를 두고 추측할 일도 없습니다. 마크업은 검증을 통과하거나 통과하지 못하거나 둘 중 하나입니다.
판단이 필요한 부분은 무엇을 마크업할지와 어떻게 일관성을 유지할지입니다.
포맷: JSON-LD, 그 외에는 없음
문법은 JSON-LD, Microdata, RDFa 세 가지가 있습니다. JSON-LD를 쓰세요. <script> 태그 안에 마크업과 분리되어 존재하므로, 템플릿을 바꿔도 스키마가 조용히 깨지지 않고 디자이너가 섹션 순서를 바꿔도 무효화되지 않습니다. 검색엔진이 권장하는 형식이기도 합니다.
<script type="application/ld+json">
{ "@context": "https://schema.org", "@type": "Article", "headline": "..." }
</script>
성과를 내는 타입들
타입은 수십 개지만 실제로 눈에 보이는 결과를 만드는 건 소수입니다.
| 타입 | 기대 결과 | 적용 위치 |
|---|---|---|
Organization |
지식 패널, 로고, 사이트링크 | 전 사이트, 1회 |
WebSite |
사이트링크 검색창 | 전 사이트, 1회 |
BreadcrumbList |
결과 내 경로 표시 | 루트 하위 모든 페이지 |
Product + Offer |
가격, 재고, 리뷰 별점 | 상품 상세 |
Article / BlogPosting |
아티클 리치 결과, 뉴스 | 에디토리얼 콘텐츠 |
FAQPage |
펼침형 Q&A | 실제 Q&A가 있는 페이지 |
HowTo |
단계별 결과 | 설명형 콘텐츠 |
LocalBusiness |
지도, 영업시간, 길찾기 | 오프라인 매장 |
VideoObject |
동영상 썸네일 | 영상 포함 페이지 |
Event |
일정, 장소, 티켓 | 행사 페이지 |
Organization, WebSite, BreadcrumbList부터 시작하세요. 모든 사이트에 해당하고, 반나절이면 되며, 나머지가 붙을 토대가 됩니다.
스니펫 다섯 개가 아니라 그래프 하나
흔한 실수는 독립된 블록을 템플릿 여기저기에 흩뿌리는 것입니다. 헤더 파셜에 Organization, 콘텐츠 파셜에 Article, 또 다른 곳에 Breadcrumb. 서로를 모르고, publisher가 조금씩 다른 값으로 두 번 정의되며, 아무것도 연결되지 않습니다.
@graph와 @id로 페이지당 하나의 그래프를 내보내세요.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Example",
"url": "https://example.com/",
"logo": { "@type": "ImageObject", "url": "https://example.com/logo.png" }
},
{
"@type": "WebSite",
"@id": "https://example.com/#website",
"url": "https://example.com/",
"publisher": { "@id": "https://example.com/#organization" }
},
{
"@type": "BlogPosting",
"@id": "https://example.com/blog/post#article",
"headline": "게시글 제목",
"datePublished": "2026-09-09",
"dateModified": "2026-09-09",
"inLanguage": "ko",
"isPartOf": { "@id": "https://example.com/#website" },
"publisher": { "@id": "https://example.com/#organization" },
"author": { "@id": "https://example.com/#organization" }
}
]
}
</script>
각 엔티티는 한 번만 선언하고 나머지는 @id로 참조합니다. publisher 정의는 하나, 수정 지점도 하나, 그리고 기계가 실제로 순회할 수 있는 그래프가 됩니다.
노출 여부를 결정하는 규칙
마크업은 화면에 보이는 내용과 일치해야 합니다. 사이트가 제재받는 지점이 바로 여기입니다. 페이지에 없는 가격을 담은 Product, 보이는 리뷰가 없는 aggregateRating, 페이지에 없는 질문을 담은 FAQPage는 정책 위반이며, 결과는 해당 페이지가 아니라 사이트 전체의 리치 결과 상실입니다.
페이지의 주 엔티티를 마크업합니다. 상품 상세는 Product, 아티클은 Article입니다. 관련 아이템을 전부 완전한 엔티티로 마크업하지 마세요.
필수 속성부터 채우고 권장 속성을 더합니다. name과 offers가 없는 Product는 아무것도 만들지 못합니다. brand, sku, image, description을 더하면 결과가 풍부해집니다.
날짜는 ISO 8601로. 2026-09-09T10:00:00+09:00이지 2026년 9월 9일이 아닙니다.
모든 URL은 절대 경로로. JSON-LD 내 상대 경로는 신뢰할 수 없습니다.
리치 결과는 보장되지 않습니다. 유효한 마크업은 '자격'을 만들 뿐입니다. 실제 노출은 쿼리와 페이지 품질을 근거로 검색엔진이 결정합니다.
구조화 데이터와 AI 답변 엔진
이제 두 번째 독자가 생겼습니다. 생성형 검색 시스템은 답변을 구성하려고 페이지를 파싱하고, 명시적인 구조는 정확한 추출과 인용을 훨씬 쉽게 만듭니다.
가장 분명한 예가 FAQPage입니다. 질문과 답변이 명시적으로 짝지어진 형태는 답변 엔진이 원하는 바로 그 구조입니다. datePublished와 author가 있는 Article은 출처 표기를 돕고, BreadcrumbList는 페이지의 위치를 알려 출처를 설명하기 쉽게 합니다. 순위 트릭이 아니라, 정확히 인용되느냐, 하지 않은 말로 바꿔 인용되느냐의 차이입니다. 자세한 내용은 AI 검색 최적화(GEO/AEO)에서 다룹니다.
검증과 유지관리
순서대로 세 가지를 점검합니다.
- Schema.org 검증기 — 어휘 자체가 올바른가
- Google 리치 결과 테스트 — 이 페이지가 리치 결과 자격이 있는가
- Search Console 향상 보고서 — 사이트 전체에서 시간에 따라 무슨 일이 일어나는가
유지관리의 진짜 문제는 드리프트입니다. CMS에서 가격은 바뀌었는데 하드코딩된 JSON-LD는 그대로인 경우, 템플릿 리팩터링으로 author 필드가 사라진 경우 같은 것들입니다. 두 가지 규칙이 이를 막습니다. 구조화 데이터는 손으로 쓰지 말고 페이지를 렌더링하는 것과 같은 데이터 소스에서 생성할 것, 그리고 자사 사이트를 주기적으로 크롤링해 모든 템플릿이 기대한 값을 내보내는지 확인할 것. AttractiveWebAI의 크롤러는 페이지별 JSON-LD 타입을 수집하므로, "이번 릴리즈 후 Product 마크업이 사라진 템플릿은 어디인가"가 수작업 점검이 아니라 한 줄 diff가 됩니다.
자주 묻는 질문
구조화 데이터가 순위를 올려주나요?
직접적으로는 아닙니다. 더 풍부한 표시의 자격을 만들어 클릭률을 높입니다. 트래픽 증가는 실재하지만 순위 상승 주장은 근거가 없습니다.
탭 뒤에 숨겨진 콘텐츠도 마크업할 수 있나요?
페이지에 존재하고 인터랙션으로 접근 가능하면 대체로 가능합니다. 페이지에 아예 없는 내용이라면 안 됩니다. 그것이 콘텐츠 불일치 위반입니다.
마크업은 얼마나 많아야 과한가요?
주 엔티티와 그것의 실제 구성요소까지입니다. 한 페이지에 연결되지 않은 타입 10개는 풍부함이 아니라 혼란의 신호이고, 이 페이지가 무엇에 관한 것인지를 희석합니다.
FAQ 리치 결과는 아직 노출되나요?
상당수 쿼리 유형에서 노출이 축소됐습니다. 그래도 Q&A가 실제로 존재하는 페이지라면 FAQPage 마크업은 여전히 가치가 있습니다. AI 답변 엔진에 페이지를 명확히 설명해 주고 비용은 거의 없습니다. 다만 이를 위해 가짜 질문을 만들지는 마세요.
CMS가 Microdata를 생성하는데 그대로 둬도 되나요?
기존 Microdata는 남겨둘 수 있지만 둘을 함께 관리하지는 마세요. 진실의 원천이 둘이면 어긋나고, 둘이 충돌하는 상태는 어느 한쪽만 있는 것보다 나쁩니다.