JSON-LD 필수 vs 권장 필드, 없어도 되는데 왜 넣으라 하나
"schema.org 문서를 보면 대부분 속성이 optional이라는데, 왜 이 필드 없으면 리치 스니펫이 안 뜬다고 하지?" 구조화 데이터를 처음 다루는 사람이 반드시 한 번은 부딪히는 혼란입니다. 원인은 간단합니다. 여러분이 실제로 지켜야 하는 규칙은 두 개의 서로 다른 기관이 각자 정한 기준이고, 이 둘은 겹치지 않습니다. 이 가이드는 그 두 기준이 무엇이고 왜 갈라지는지, 실무에서 어떻게 대응해야 하는지 정리합니다.
1. schema.org 스펙과 구글 요구사항은 서로 다른 문서다
schema.org는 W3C 커뮤니티 그룹과 Google·Microsoft·Yahoo·Yandex가 함께 만든 "어휘 사전"입니다. 이 사전 자체는 대부분의 속성을 선택사항으로 정의합니다 — "Article에는 image가 있을 수도 있다" 정도의 느슨한 정의입니다. 반면 구글 검색은 이 어휘 사전을 어떻게 리치 스니펫(별점, 가격, FAQ 아코디언 등)으로 변환할지 자체적으로 정한 별도의 요구사항 문서(Google Search Central의 구조화 데이터 가이드라인)를 운영합니다. 이 문서에는 "이 필드가 없으면 우리는 이 리치 스니펫을 아예 표시하지 않는다"는 구글만의 필수 조건이 명시되어 있습니다. 즉 스키마 유효성(schema.org 기준)과 리치 스니펫 자격(구글 기준)은 완전히 다른 두 개의 검사입니다.
2. "유효한 스키마인데 스니펫이 안 뜨는" 이유
이 두 기준이 다르기 때문에, JSON-LD 문법이 완벽하고 @context·@type도 정확한 "유효한" 스키마인데도 검색 결과에서 리치 스니펫은 전혀 안 뜨는 상황이 생깁니다. 예를 들어 Article 타입은 schema.org 스펙상 headline 하나만 있어도 문법적으로는 문제없지만, 구글이 Article 리치 결과(상단 뉴스 캐러셀 등)를 보여주려면 author, datePublished 같은 필드가 실질적으로 필요합니다. 스키마 검증기는 이 구분을 명시적으로 구현하고 있어서, 코드 내부에 REQUIRED_FIELDS(없으면 "필수 필드 누락"으로 무효 판정)와 RECOMMENDED_FIELDS(없어도 유효 판정은 유지하되 경고만 표시)를 별도 목록으로 관리합니다.
| @type | 필수 필드(누락 시 무효) | 권장 필드(누락 시 경고만) |
|---|---|---|
| Article | headline, author, datePublished | description, image, publisher |
| Product | name | description, image, offers, aggregateRating |
| Event | name, startDate, location | endDate, description, organizer, image |
| Recipe | name, recipeIngredient, recipeInstructions | description, cookTime, prepTime, recipeYield, image |
여기서 중요한 점은 이 표의 "필수 필드"가 schema.org 자체의 필수 규정이 아니라, 리치 스니펫이 실제로 뜨기 위해 구글 등 검색엔진이 요구하는 최소 조건을 도구가 반영해놓은 것이라는 점입니다.
3. 권장 필드를 넣어야 하는 실질적 이유
권장 필드는 "없어도 스니펫은 뜬다"는 게 정확한 설명이지만, 있으면 더 풍부한 형태의 스니펫으로 표시될 가능성이 커집니다. 예를 들어 Product에서 image가 있으면 검색 결과에 상품 이미지가 함께 표시되고, aggregateRating이 있으면 별점이 노출됩니다. 클릭률(CTR)에 직접 영향을 주는 요소이므로, "규칙을 지키기 위해서"가 아니라 "검색 결과에서 더 눈에 띄기 위해서" 채워 넣는 것이 정확한 동기입니다.
name만 있으면 스키마 검증기는 "유효한 스키마"로 판정합니다. 그러나 offers(가격)와 aggregateRating(평점)이 없으면 구글은 가격/별점이 함께 나오는 리치 스니펫을 보여주지 않고 일반 링크로만 표시할 가능성이 높습니다. 즉 "검증 통과"와 "검색결과에서 눈에 띔"은 별개의 목표입니다.
4. 최종 확인은 도구가 아니라 구글의 실제 판정으로
사이트 자체 검증 도구(스키마 검증기 포함)는 스펙과 구글 가이드라인을 기반으로 필드 존재 여부를 빠르게 점검해주지만, 실제로 리치 스니펫이 뜨는지 여부의 최종 판정자는 구글 자체입니다. 구글은 필드가 다 있어도 페이지 품질, 스팸 여부, 크롤링 빈도 등 다른 요소까지 종합해서 표시 여부를 결정하기 때문에, 배포 전 자체 도구로 1차 점검을 마친 뒤에는 반드시 Google 리치 결과 테스트로 실제 판정 결과까지 확인하는 2단계 검증이 필요합니다.
5. 실전 체크리스트
- 먼저 스키마 검증기로 문법 오류와 필수 필드 누락 여부부터 확인합니다.
- 필수 필드가 모두 채워졌다면, 권장 필드 목록을 훑어보고 채울 수 있는 것부터 추가합니다(특히 image, aggregateRating은 CTR 영향이 큽니다).
- 새 스키마를 직접 작성하기보다 Article 스키마 생성기, Product 스키마 생성기 같은 타입별 생성기를 쓰면 필수/권장 필드를 빠뜨릴 확률이 줄어듭니다.
- 배포 후에는 Google Search Console의 "향상 기능" 리포트에서 실제로 리치 결과 자격을 인정받았는지 주기적으로 확인합니다.
자주 묻는 질문
Q. 필수 필드를 다 채웠는데도 리치 스니펫이 안 보여요.
필수 필드 충족은 "자격 조건"일 뿐 "보장"이 아닙니다. 구글은 페이지 품질, 콘텐츠와 마크업의 일치 여부, 사이트 신뢰도 등을 함께 고려해 표시 여부를 최종 결정하며, 반영까지 며칠에서 몇 주가 걸릴 수도 있습니다.
Q. schema.org에는 있는데 구글 가이드라인에는 없는 타입도 있나요?
네, 많습니다. schema.org는 수백 개의 타입을 정의하지만 구글이 리치 스니펫으로 지원하는 타입은 그중 일부(Article, Product, Recipe, FAQPage, Event 등)뿐입니다. 지원되지 않는 타입은 아무리 필드를 채워도 특수한 스니펫 형태로는 표시되지 않습니다.
Q. 필수 필드 기준은 자주 바뀌나요?
네. 구글은 구조화 데이터 가이드라인을 주기적으로 업데이트하며, 특히 FAQPage나 HowTo처럼 남용이 많았던 타입은 표시 자격 요건이 강화된 사례가 있습니다. 반기에 한 번 정도는 Google Search Central 문서를 다시 확인하는 것이 안전합니다.
Q. 필드를 사실과 다르게 채워도 되나요?
안 됩니다. 실제 콘텐츠와 일치하지 않는 스키마(예: 실제로 없는 평점을 표시)는 구글의 구조화 데이터 정책 위반으로 수동 조치(리치 결과 자격 박탈 또는 그 이상의 페널티) 대상이 될 수 있습니다. 항상 페이지에 실제로 표시되는 정보와 스키마 값을 일치시켜야 합니다.