DIRECT ANSWER
먼저 답부터
핵심 요약
- 구조화 데이터의 모든 핵심 값은 사용자가 화면에서도 확인할 수 있어야 합니다.
- 페이지 유형에 맞는 소수의 스키마를 정확하게 쓰는 편이 무분별한 중첩보다 낫습니다.
- 배포 전 구문 검증, 배포 후 실제 URL 검사, 변경 뒤 재검증을 운영 절차로 둡니다.
구조화 데이터는 의미를 보조하지만 품질을 대신하지 않습니다
JSON-LD는 회사, 제품, 문서, 이동 경로 같은 정보를 기계가 읽기 쉬운 형식으로 표현합니다. 다만 빈약한 본문을 좋은 콘텐츠로 바꾸거나 색인을 보장하지는 않습니다.
Google은 AI 검색 기능을 위한 특별한 스키마가 필요하지 않다고 안내합니다. 기존 검색 가이드에 맞춰 페이지 유형과 실제 본문에 맞는 구조화 데이터를 사용해야 합니다.
페이지 역할에 맞는 유형을 선택합니다
사이트 전체에는 Organization 또는 SoftwareApplication처럼 운영 주체와 서비스를 설명하는 정보가 필요할 수 있습니다. 가이드 문서에는 Article과 BreadcrumbList가 자연스럽고, 실제 상품 상세에는 Product와 Offer를 검토합니다.
| 페이지 | 검토할 유형 | 주의점 |
|---|---|---|
| 회사·서비스 홈 | Organization, WebSite, SoftwareApplication | 실제 운영사와 서비스 관계 명확화 |
| 가이드·기사 | Article, BreadcrumbList | 작성자·수정일·본문과 일치 |
| 상품 상세 | Product, Offer | 가격·재고·브랜드 최신 유지 |
| 질문 답변 | FAQPage | 화면에 보이는 질문과 답만 포함 |
@id로 같은 엔티티를 일관되게 연결합니다
회사나 서비스가 페이지마다 다른 객체로 흩어지지 않게 안정적인 @id를 사용할 수 있습니다. 예를 들어 서비스는 사이트의 `#software`, 운영사는 회사 사이트의 `#organization`처럼 구분하고 provider 관계로 연결합니다.
sameAs에는 실제로 관리하는 공식 프로필이나 신뢰할 수 있는 엔티티 URL만 넣습니다. 관련이 약한 사이트를 많이 추가하는 것은 명확성을 높이지 않습니다.
배포 전후 세 단계로 검증합니다
첫째, JSON 문법과 필수 속성을 검사합니다. 둘째, 구조화 데이터 값이 화면 본문과 같은지 사람이 확인합니다. 셋째, 배포된 URL을 검색 도구로 검사해 크롤러가 받은 HTML에도 마크업이 있는지 확인합니다.
- 화면에 없는 리뷰·평점·가격을 넣지 않기
- FAQ 질문과 답변을 마크업에만 숨기지 않기
- 잘못된 canonical URL을 @id와 url에 반복하지 않기
- 수정일만 자동으로 매일 바꾸지 않기
- 오류 보고서를 배포 후 운영 모니터링에 포함하기
AIBooster 무료 진단
우리 사이트는 어디부터 고쳐야 할까요?
URL 하나로 구조·권위·맥락·성능 준비 상태를 확인하세요.FAQ
자주 묻는 질문
- 구조화 데이터를 많이 넣을수록 좋은가요?
- 아닙니다. 페이지의 실제 역할과 본문에 맞는 유형을 정확히 유지하는 것이 중요합니다. 관련 없는 유형을 중첩하면 관리 오류와 정보 불일치가 늘어납니다.
- FAQPage를 넣으면 검색 결과에 FAQ가 항상 나오나요?
- 보장되지 않습니다. 구조화 데이터가 유효해도 검색 기능 노출 여부는 검색엔진이 결정합니다. 질문과 답변은 사용자에게도 실제로 보여야 합니다.
- AI 검색 전용 Schema가 있나요?
- Google은 AI 기능을 위한 특별한 schema.org 유형이 필요하지 않다고 안내합니다. 기존 페이지 의미를 정확히 표현하는 구조화 데이터를 사용합니다.
검토한 공식 자료
이 글은 일반적인 실무 가이드이며 특정 검색엔진의 노출이나 순위를 보장하지 않습니다.