구조화 데이터 검증 도구 사용법

Q: 하나의 페이지에 JSON-LD 블록을 여러 개 넣어도 되나요?

가능하다. Google은 한 페이지의 여러 <script type="application/ld+json"> 블록을 각각 독립적으로 파싱한다. Article과 BreadcrumbList처럼 타입이 다른 경우 별도 블록으로 분리하는 것이 관리 편의상 권장된다. 단, 동일 @type을 두 블록에 중복 선언하면 Google 파서의 우선순위가 정의되지 않으므로, 같은 타입은 단일 블록에 통합해야 한다. Schema Markup Validator는 블록을 독립적으로 검증하므로 중복 타입 문제를 검출하지 못한다는 점에 주의한다.

구조화 데이터(JSON-LD·Microdata·RDFa)는 검색 엔진과 AI 크롤러가 페이지 콘텐츠를 기계 판독할 수 있도록 명시적 시맨틱 신호를 제공한다. 스키마가 잘못 구현되면 리치 결과(Rich Results) 자격을 잃고, Google AI Overviews·Perplexity·ChatGPT Browse 등 생성형 엔진의 인용 풀에서도 배제될 수 있다. 검증 도구는 파서가 실제로 읽는 DOM 상태를 기준으로 오류·경고를 반환하기 때문에, 코드 에디터에서 JSON을 육안으로 확인하는 것과는 근본적으로 다른 진단 경로다.

검증 도구의 작동 원리

Google의 두 공식 도구는 서로 다른 검증 레이어를 담당한다.

Schema Markup Validator (validator.schema.org) — Schema.org RDF 어휘 명세에 대해 속성 유형·필수 항목·값 범위를 검사한다. Google 전용 확장(speakable 등)은 포함하지 않는다. 왜: 표준 어휘 준수가 Google 외 Bing·야후·AI 크롤러 호환성의 공통 기반이기 때문. 어떻게: URL 또는 HTML 코드를 붙여넣으면 속성별 오류를 항목 트리로 반환한다.
Google Rich Results Test (search.google.com/test/rich-results) — Schema.org 검증 외에 Google 리치 결과 가이드라인 적합성을 추가 평가한다. 지원 타입(Article·Product·FAQ·HowTo·Recipe 등)에 한해 "적격/부적격" 판정을 반환한다. 왜: 어휘 적합성과 Google 렌더링 적격성은 별개 기준이라 둘 다 통과해야 한다. 어떻게: "발견된 항목" 패널에서 파싱된 속성값과 오류를 타입별로 확인한다.
Search Console 리치 결과 보고서 — 실제 Googlebot이 크롤한 전체 사이트 URL의 적격·오류·경고 수를 집계한다. 단일 URL 스냅샷인 위 두 도구와 달리, 사이트 전체의 추세 및 회귀(regression) 감지에 적합하다. 왜: 배포 직후 템플릿 레벨 스키마 깨짐을 수백 URL 단위로 조기 감지할 수 있다. 어떻게: Search Console → 검색 모양새 → 리치 결과 메뉴에서 타입별로 드릴다운한다.

세 도구 모두 <script type="application/ld+json"> 블록을 HTML 파싱 단계에서 추출한다. JavaScript로 동적 삽입된 JSON-LD는 Googlebot의 렌더링 큐를 통과해야 반영되므로 지연이 발생한다. 정적 HTML에 JSON-LD를 포함하는 것이 검증 일관성과 인덱싱 신뢰도 모두에서 우위다.

주요 도구 비교

도구	검증 기준	리치 결과 판정	커버리지	접근 조건
Schema Markup Validator	Schema.org 명세	없음	단일 URL / HTML 붙여넣기	공개 URL 불필요(HTML 직접 입력 가능)
Google Rich Results Test	Schema.org + Google 가이드라인	있음	단일 URL / 코드 스니펫	공개 URL 또는 HTML 스니펫
Search Console 리치 결과 보고서	실제 Googlebot 크롤 데이터	있음(집계)	사이트 전체	Search Console 소유권 인증 필수
Structured Data Linter (third-party)	Schema.org + JSON-LD 문법	없음	단일 URL / HTML	공개 URL 또는 HTML

JSON-LD 구현 예시 및 단계별 검증 절차

아래는 기술 블로그 포스트에 적용 가능한 최소 유효 TechArticle 스키마다. Google 리치 결과 가이드라인이 요구하는 필수 속성(headline, author, datePublished, image)을 모두 포함하며, Rich Results Test 통과 기준을 충족한다.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "TechArticle",
  "headline": "구조화 데이터 검증 도구 사용법",
  "author": {
    "@type": "Person",
    "name": "박도현",
    "url": "https://citeon.co.kr/authors/park-dohyeon"
  },
  "datePublished": "2026-06-18",
  "dateModified": "2026-06-18",
  "image": {
    "@type": "ImageObject",
    "url": "https://citeon.co.kr/images/structured-data-guide.jpg",
    "width": 1200,
    "height": 630
  },
  "publisher": {
    "@type": "Organization",
    "name": "Citeon",
    "logo": {
      "@type": "ImageObject",
      "url": "https://citeon.co.kr/logo.png",
      "width": 600,
      "height": 60
    }
  },
  "description": "Google Rich Results Test와 Schema Markup Validator를 활용해 JSON-LD 구조화 데이터 오류를 진단하고 수정하는 실무 절차.",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://citeon.co.kr/blog/structured-data-validation"
  }
}
</script>

검증 절차 (순서 중요)

Schema Markup Validator 먼저 실행 — Schema.org 문법 오류(잘못된 속성명, 타입 불일치)를 선제 제거한다. 왜: 이 단계를 건너뛰면 Rich Results Test 오류가 어휘 문제인지 Google 정책 문제인지 구분이 불가능해진다. 어떻게: URL 또는 위 JSON-LD 코드를 붙여넣어 "오류(errors)" 항목이 0개가 될 때까지 수정한다.
Google Rich Results Test 실행 — "발견된 항목" 패널에서 의도한 타입이 파싱됐는지 확인하고 경고·오류 항목을 제거한다. 왜: "경고(warnings)"는 리치 결과 자격을 박탈하지 않지만, Google이 추천 속성을 누락으로 간주해 노출 빈도를 제한할 수 있다. 어떻게: 경고 항목을 클릭하면 해당 속성의 Schema.org 정의 링크가 함께 제공된다.
Search Console 리치 결과 보고서 모니터링 — 스키마 배포 후 1~2주 크롤 사이클이 지나면 "유효한 항목" 수 변화를 추적한다. 왜: 도구 검증과 실제 크롤 결과는 렌더링 환경 차이로 갈릴 수 있으며, 보고서가 최종 판정 기준이다. 어떻게: 오류 URL을 클릭하면 Googlebot이 실제 파싱한 구조화 데이터 상태를 확인할 수 있다.
실제 검색 결과 육안 확인 — site:도메인 키워드 쿼리로 리치 스니펫 노출 여부를 직접 확인한다. 왜: Search Console 인상 데이터와 실제 SERP 표시 여부는 시차가 있어 직접 확인이 더 빠르다. 어떻게: 브랜드 검색 또는 목표 키워드 검색 후 URL 옆 스니펫 형식(별점·날짜·FAQ 아코디언 등)을 확인한다.

흔한 오해: "오류 0개 = 리치 결과 보장"

Rich Results Test에서 오류가 전혀 없어도 실제 검색 결과에 리치 스니펫이 표시되지 않는 경우가 있다. Google은 스키마 적격성 외에 페이지 품질 신호(E-E-A-T), 쿼리-콘텐츠 연관성, 크롤 예산 가용성을 추가로 평가한다.

스키마가 정확해도 해당 @type이 노출 쿼리와 연관성이 없으면 리치 결과가 나타나지 않는다.
datePublished 값이 실제 게시 날짜와 불일치하면 Google이 해당 스키마를 스팸 신호로 간주해 무시할 수 있다.
동일 @type을 복수 블록에 중복 선언하면 Google 파서가 어느 블록을 우선할지 보장하지 않는다.

올바른 처리법: 검증 도구 통과는 전제 조건일 뿐이다. 리치 결과 노출은 Search Console 리치 결과 보고서의 인상(impression) 수 추이로 판단하고, 오류 0개임에도 인상 0이면 해당 페이지의 E-E-A-T 점검과 콘텐츠-쿼리 정렬을 선행한다.

Rich Results Test는 통과했는데 Search Console 보고서에 경고가 뜹니다. 왜 다른 결과가 나오나요?

Rich Results Test는 도구 실행 시점의 HTML 스냅샷을 파싱하고, Search Console은 Googlebot이 실제 크롤한 시점의 렌더링 결과를 기준으로 집계한다. JavaScript 렌더링 지연, A/B 테스트로 인한 응답 분기, CDN 캐시 불일치 등이 두 결과를 갈라놓는 주요 원인이다. Search Console 보고서에서 특정 URL의 "오류 세부정보"를 클릭하면 Googlebot이 실제로 파싱한 구조화 데이터 상태와 파싱 시각을 확인할 수 있으며, 이것이 최종 진단 기준이다.

하나의 페이지에 JSON-LD 블록을 여러 개 넣어도 되나요?

가능하다. Google은 한 페이지의 여러 <script type="application/ld+json"> 블록을 각각 독립적으로 파싱한다. Article과 BreadcrumbList처럼 타입이 다른 경우 별도 블록으로 분리하는 것이 관리 편의상 권장된다. 단, 동일 @type을 두 블록에 중복 선언하면 Google 파서의 우선순위가 정의되지 않으므로, 같은 타입은 단일 블록에 통합해야 한다. Schema Markup Validator는 블록을 독립적으로 검증하므로 중복 타입 문제를 검출하지 못한다는 점에 주의한다.

참고 자료

이 글의 권고는 아래 공식 문서·연구를 근거로 합니다.