이 페이지에서 다루는 검색 주제
JSON-LD는 검색 결과를 “예쁘게” 만들기 위한 장식이 아니라, **페이지에 이미 있는 정보를 기계가 읽기 쉽게 옮기는 레이어**입니다. 페이지에 없는 전화번호·가격·평점·리뷰를 넣는 순간 정책 위반이 될 수 있습니다.
타입 선택: 욕심을 줄이기
WebPage, FAQPage, Article, Service 등 **실제 블록과 대응**되는 타입만 고릅니다. “타입이 많으면 리치가 많이 뜬다”는 식의 접근은 경고 누적과 실격 리스크로 이어집니다.
필드 최소화
필수 필드를 채우고, 불확실한 옵션 필드는 **빼는 편이 낫습니다**. “일단 채워 넣자”가 나중에 팀 기억에서 사라지면 유지보수 지뢰가 됩니다.
FAQPage는 본문 FAQ와 1:1
구조화만 FAQ로 채우고 본문에는 없는 질문을 넣는 패턴은 위험합니다. 사용자가 실제로 보는 Q/A와 JSON-LD가 **동일해야** 합니다.
QA: 출시 전이 아니라 ‘출시 전’
Rich Results Test로 샘플 URL을 검증하고, 경고는 “나중에”가 아니라 배포 전에 줄입니다. 경고를 쌓아 두면 다음 배포에서 무엇이 깨졌는지 추적이 어렵습니다.
모니터링
Search Console의 리치 결과·스키마 관련 보고서에서 급격한 증가·감소를 보면 배포 회귀나 템플릿 버그 신호일 수 있습니다. 알림을 걸어두면 대응이 빨라집니다.
한 페이지에 여러 타입을 쓸 때
여러 타입이 **같은 주제·같은 본문 블록**을 설명할 때만 자연스럽습니다. 서로 다른 주제를 한 페이지에 억지로 겹쳐 스키마를 늘리면 검색 결과에서 메시지가 혼선을 줄 수 있습니다.
개발팀·마케팅·법무가 같이 봐야 하는 이유
스키마는 코드로 들어가지만 내용은 카피와 같습니다. 승인 프로세스 없이 마케터만 추가하거나, 개발만 관리하면 **정책·사실 불일치**가 반복됩니다. 허용 타입 목록을 레포 문서로 고정해 두세요.
최소주의가 장기적으로 이기는 이유
스키마는 “한 번 넣고 끝”이 아니라 릴리즈마다 따라가야 합니다. 단순할수록 회귀가 적고, 경고가 적으며, 팀 전체가 이해하기 쉽습니다.