실무 구조화 데이터 가이드
실무 SEO를 위한 JSON-LD 스키마 마크업 가이드
JSON-LD는 검색엔진이 페이지 내용, 발행자, 사이트 내 위치, 검색 기능에 활용할 가치 있는 정보를 이해하도록 돕습니다.
모든 스키마 유형을 추가하는 것이 목표가 아니라, 보이는 페이지와 일치하고 검증이 용이하며 콘텐츠 변경 시 동기화되는 정확한 구조화 데이터가 목표입니다.
유용한 짧은 버전
제목, 설명, 저자, 게시일, 빵 부스러기, 제품 정보, 동영상 데이터, 명확한 Q&A 등 정직하고 보이는 사실로 페이지를 설명할 수 있을 때 JSON-LD를 사용하세요. Google이 더 이상 표시하지 않는 기능을 약속하거나 사용자가 볼 수 없는 콘텐츠를 마크업하지 마세요.
목차
JSON-LD가 실제로 하는 일
JSON-LD는 기계가 읽을 수 있는 구조화 데이터 블록으로, 보통 head나 body의 스크립트 태그에 위치하며 schema.org 어휘로 엔티티를 설명합니다. 검색엔진은 이를 가시 콘텐츠 위 명확성 계층으로 사용합니다.
파서 명확성
의미
페이지 사실을 Article, author, datePublished, BreadcrumbList, SoftwareApplication 같은 명명된 엔티티와 속성으로 변환합니다.
검색 기능
적합성
지원되는 리치 결과 자격을 부여할 수 있으나, Google은 품질, 정책, 쿼리, 기능 가용성에 따라 표시 여부를 결정합니다.
사이트 그래프
일관성
CMS나 Blazor 앱에 동일한 정규 URL, 언어, 제목, 날짜, 이미지, 발행자 데이터를 재사용할 수 있는 구조화된 공간을 제공합니다.
지름길 아님
제한
약한 콘텐츠, 가짜 리뷰, 숨겨진 FAQ 답변, 오래된 날짜, 구조화 데이터와 불일치하는 페이지를 개선하지는 않습니다.
페이지 역할에 맞는 스키마 선택
스팸성 또는 중복 구조화 데이터를 피하는 가장 쉬운 방법은 페이지 목적을 묻고, 그 역할을 정확히 설명하는 최소한의 스키마만 추가하는 것입니다.
콘텐츠
Article / BlogPosting
- 사용 용도
- 가이드, 튜토리얼, 리뷰, 뉴스형 게시물, 장문 설명글
- 추가 시점
- 페이지에 명확한 제목, 저자 또는 발행자, 게시일, 수정일, 정규 URL, 이미지가 있음
- 피해야 할 경우
- 페이지가 주로 도구 UI, 제품 목록, 카테고리 페이지, 또는 빈약한 랜딩 페이지임
내비게이션
BreadcrumbList
- 사용 용도
- 홈페이지 하위 거의 모든 페이지
- 추가 시점
- 사용자가 페이지가 사이트 계층 어디에 위치하는지 이해할 수 있음
- 피해야 할 경우
- 빵 부스러기 경로가 내부 링크, 정규 URL, 보이는 내비게이션과 일치하지 않음
사이트 정체성
WebPage / WebSite / Organization
- 사용 용도
- 홈페이지, 허브, 소개 페이지, 발행자 정보가 중요한 페이지
- 추가 시점
- 페이지, 사이트, 발행자, 언어를 연결하는 안정적인 엔티티 그래프가 필요합니다.
- 피해야 할 경우
- 오래된 사이트링크 검색 상자 표시를 위해 WebSite 마크업만 추가함
제품 또는 앱
Product / SoftwareApplication
- 사용 용도
- 도구, 앱, SaaS 페이지, 확장 기능, 다운로드 가능한 소프트웨어, 실제 제품 페이지
- 추가 시점
- 마크업 시 보이는 페이지 콘텐츠에는 이름, 설명, 운영체제 또는 카테고리, 가격, 제안, 평점이 포함됩니다.
- 피해야 할 경우
- 평점, 가격, 재고, 리뷰가 페이지에서 사용자에게 보이지 않음
질문
FAQPage
- 사용 용도
- 사용자가 주제를 이해하는 데 실제로 도움이 되는 가시적인 Q&A 섹션
- 추가 시점
- Google이 FAQ 리치 결과를 표시하지 않아도 Q&A 콘텐츠가 페이지에 유용함
- 피해야 할 경우
- 검색 공간 확보나 여러 페이지에 동일 답변 반복용으로 일반 Q&A를 추가함
미디어
VideoObject / ImageObject
- 사용 용도
- 중요한 임베디드 동영상, 튜토리얼 영상, 크롤링 가능한 이미지 자산이 있는 페이지
- 추가 시점
- 미디어가 페이지 중심에 있으며 제목, 설명, 썸네일, 업로드 날짜, 안정적인 URL을 포함함
- 피해야 할 경우
- 미디어가 장식용이거나 숨겨져 있거나 차단되었거나 주요 페이지 목적과 관련이 없음
대부분 실수를 방지하는 구현 체크리스트
좋은 JSON-LD는 일관되고 신뢰할 수 있는 필드에서 생성되며, 검증이 쉽고 페이지 변경 시 잊기 어려운 안정적인 데이터입니다.
주요 페이지 엔티티 하나 선택
페이지가 주로 기사, 제품, 앱, 동영상, FAQ, 컬렉션, 일반 웹페이지 중 무엇인지 결정하고, 보조 스키마는 주체를 지원해야 합니다.
보이는 콘텐츠와 일치
마크업된 모든 정보는 페이지에서 명확히 보이거나 추론 가능해야 합니다: 제목, 저자, 날짜, 가격, 평점, Q&A, 빵 부스러기, 이미지 등.
안정적인 @id 값 사용
중요 엔티티에 정규 URL과 #article, #webpage, #organization, #faq 같은 안정적인 ID를 부여해 파서가 그래프 조각을 연결하도록 돕습니다.
공유 메타데이터에서 생성
제목 태그, 메타 설명, 정규 URL, Open Graph 이미지, 언어 태그, 최종 수정 날짜를 생성하는 동일한 소스 필드를 재사용하세요.
날짜 정보를 정확하게 유지
실질적 콘텐츠 변경 시에만 dateModified를 변경하고, 검색 결과에서 최신처럼 보이려고 날짜를 자동 갱신하지 마세요.
이미지를 크롤링 가능하게 만드세요
절대 이미지 URL, 적절한 크기, 로봇 차단, 인증, 지연 로딩 전용 렌더링에 걸리지 않는 파일 사용
조기 렌더링
Blazor 및 기타 JavaScript 앱에서는 크롤러가 초기 HTML 응답에서 JSON-LD를 볼 수 있도록 사전 렌더링 또는 서버 렌더링을 권장합니다.
검증 및 모니터링
게시 전 리치 결과 테스트 실행, 스키마 마크업 검증기로 문법 확인, 인덱싱 후 Search Console 모니터링
Blazor 페이지용 깔끔한 JSON-LD 패턴
Blazor에서는 초기화나 사전 렌더링 시 페이지 메타데이터로 스키마를 생성하고 한 번 직렬화한 뒤, 크롤러가 초기 HTML에서 볼 수 있도록 application/ld+json 스크립트를 렌더링하는 방식이 가장 안전합니다.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"@id": "https://example.com/en/json-ld-schema-guide/#article",
"headline": "JSON-LD Schema Markup Guide for Practical SEO",
"description": "A practical guide to choosing, generating, and validating structured data.",
"image": "https://example.com/images/json-ld-guide.png",
"datePublished": "2026-03-28T10:00:00+00:00",
"dateModified": "2026-05-31T10:00:00+00:00",
"author": {
"@type": "Organization",
"name": "Example Publisher"
},
"publisher": {
"@type": "Organization",
"name": "Example Publisher",
"logo": {
"@type": "ImageObject",
"url": "https://example.com/logo.png"
}
},
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://example.com/en/json-ld-schema-guide/"
}
}
</script>private MarkupString BuildJsonLd(PageMetaData meta)
{
var pageUrl = BuildPageUrl(meta);
var schema = new Dictionary<string, object?>
{
["@context"] = "https://schema.org",
["@type"] = "Article",
["@id"] = $"{pageUrl}#article",
["headline"] = meta.Title,
["description"] = meta.Description,
["url"] = pageUrl,
["datePublished"] = meta.Published?.ToString("O"),
["dateModified"] = meta.Modified?.ToString("O"),
["inLanguage"] = CS.Culture
};
var json = JsonSerializer.Serialize(schema, new JsonSerializerOptions
{
DefaultIgnoreCondition = JsonIgnoreCondition.WhenWritingNull
});
return new MarkupString($"<script type=\"application/ld+json\">{json}</script>");
}JSON-LD 의존 전 검증
검증은 두 가지 역할이 있습니다. 스키마 마크업 검증기는 어휘와 JSON-LD 문법 이해 가능 여부를, Google 리치 결과 테스트는 페이지가 지원되는 리치 결과 유형에 적합한지 확인합니다.
Google 적합성
풍부한 결과 테스트
Google이 페이지를 읽을 수 있는지, 감지된 구조화 데이터가 지원되는 리치 결과 유형에 적합한지 확인합니다.
리치 결과 테스트 열기어휘
스키마 마크업 검증기
schema.org 구조와 JSON-LD 문법, 타입, 속성, 중첩 엔티티, 잘못된 JSON 등을 검사합니다.
스키마 마크업 검증기 열기게시 후
Search Console
Google이 페이지를 처리한 후 URL 검사 및 향상 보고서로 크롤링, 인덱싱, 구조화 데이터 문제를 확인하세요.
Google 구조화 데이터 문서 읽기신뢰를 떨어뜨리는 일반적인 JSON-LD 오류
대부분 스키마 문제는 복잡한 기술적 버그가 아니라, 마크업 내용과 사용자 또는 크롤러가 확인할 수 있는 페이지 내용 간 불일치입니다.
숨겨지거나 누락된 콘텐츠 마크업
사용자가 답변, 리뷰, 제안, 이미지, 저자 정보를 볼 수 없으면 구조화 데이터에 포함하지 마세요. 신뢰를 잃는 가장 빠른 방법입니다.
모든 페이지에 FAQPage 추가
FAQ 스키마는 보이는 Q&A를 설명할 수 있으나, 모든 기사에 복사 붙여넣기용으로 사용하지 말고 Q&A가 페이지 개선에 도움이 될 때만 사용하세요.
중복 충돌 스크립트
서로 다른 제목, 날짜, URL을 가진 여러 Article 블록은 페이지 해석을 어렵게 하므로, 하나의 명확한 그래프가 세 개의 부분 그래프보다 낫습니다.
잘못된 정규 URL 또는 @id
스키마 URL은 정규 페이지, 문화권 URL, hreflang 설정과 일치해야 하며, 혼합 언어 URL은 중복 콘텐츠와 엔티티 혼란을 유발합니다.
가짜 최신성
템플릿 수정, 추적 변경, 스키마만 변경 시 dateModified를 변경하지 말고 실제 콘텐츠 변경 시에만 사용하세요.
클라이언트 전용 지연 렌더링
JSON-LD가 클라이언트 렌더링 후에만 나타나면 크롤러가 놓칠 수 있으니, 중요한 페이지는 서버 렌더링이나 사전 렌더링을 권장합니다.
페이지 유형별 실용 스키마 레시피
거대한 그래프는 거의 필요 없으며, 이 조합들이 대부분 소규모 사이트, 블로그, 도구, 리뷰 프로젝트의 페이지를 커버합니다.
가이드 기사
Article + BreadcrumbList + WebPage
- 제목, 저자, 발행자, 이미지, 날짜, 섹션 이름에 Article 사용
- 보이는 사이트 경로에 BreadcrumbList 사용
- 페이지와 기사 엔티티를 연결하려면 WebPage 또는 @id 참조 사용
도구 페이지
SoftwareApplication + WebPage + BreadcrumbList
- 실제 앱이나 도구에 관한 페이지에만 SoftwareApplication 사용
- 운영체제, 카테고리, 가격 또는 제안 정보는 보일 때만 포함하세요.
- 실제 리뷰 데이터가 없으면 리뷰나 평점 마크업을 피하세요.
리뷰 페이지
페이지가 지원할 때만 리뷰/제품 사용
- 페이지에 명확히 표시된 항목, 저자, 날짜, 평점만 마크업하세요.
- 제휴 링크와 상업적 맥락을 투명하게 유지하세요.
- 스키마와 보이는 콘텐츠에 동일한 점수 사용
질문 페이지
유용한 가시 Q&A에만 FAQPage 사용
- 각 답변이 키워드 변형이 아닌 독립적으로 유용하도록 만드세요.
- 크롤러가 접근할 수 없는 차단된 UI 뒤에 답변을 숨기지 마세요.
- FAQ 리치 결과를 주요 SEO 이점으로 기대하지 마세요.
검토한 출처
이 가이드 참고 자료
위 지침은 공식 Google Search Central과 schema.org 문서를 기반으로 하며, 실용적인 JSON-LD 체크리스트로 변환되었습니다.
자주 묻는 질문
JSON-LD 스키마 마크업이 순위 요소인가요?
JSON-LD 자체가 순위 상승을 보장하지는 않으며, 검색엔진이 적합한 콘텐츠를 이해하고 리치 결과 자격을 지원하도록 돕지만, 순위는 콘텐츠 품질, 관련성, 크롤링 가능성, 링크 등 다양한 신호에 따라 결정됩니다.
JSON-LD는 페이지 어디에 위치해야 하나요?
head 내 스크립트 태그가 관리에 가장 편리하지만, Google은 body 내 JSON-LD도 인식합니다. 중요한 것은 렌더링된 페이지에 마크업이 존재하고 보이는 내용과 일치하는 것입니다.
여전히 FAQPage 스키마를 사용해야 하나요?
실제로 유용한 가시 Q&A가 있을 때만 FAQPage를 사용하세요. 대부분 일반 사이트에서 FAQ 리치 결과 표시가 크게 축소되어 추가 공간 확보용으로 의존하지 마세요.
한 페이지에 여러 JSON-LD 블록을 넣을 수 있나요?
네, 일반 기사 페이지는 Article, BreadcrumbList, WebPage 데이터를 가질 수 있습니다. 블록을 일관되게 유지하고 중복 충돌 엔티티를 피하며 안정적인 @id 값으로 관련 조각을 연결하세요.
JSON-LD가 Microdata보다 나은가요?
대부분 최신 사이트는 JSON-LD, Microdata, RDFa를 지원하지만, JSON-LD가 시각적 HTML 템플릿 내 스키마 속성이 필요 없어 유지 관리가 더 쉽습니다.
구조화 데이터를 얼마나 자주 검증해야 하나요?
템플릿, 메타데이터 필드, 스키마 헬퍼, URL, 언어 라우팅, 이미지 생성, 리뷰 데이터, FAQ 섹션 변경 시마다 검증하고, 주요 페이지 인덱싱 후 Search Console도 확인하세요.