Microdata나 RDFa 말고 JSON-LD를 써야 하나요?

JSON-LD를 권합니다. HTML 마크업에 속성을 섞어 넣는 방식과 달리 블록 하나로 분리돼 있어 관리가 쉽고, 구글도 JSON-LD를 권장합니다. 화면 구조를 바꿔도 스키마가 깨지지 않는다는 점이 실무에서 가장 큰 장점입니다.

스키마를 많이 넣을수록 좋은가요?

아닙니다. 종류를 늘리는 것보다 정확성이 중요합니다. 화면에 없는 내용을 스키마에만 적거나, 실제와 다른 값을 넣으면 스팸으로 판단될 수 있고 리치 결과 자격을 잃습니다. 페이지 성격에 맞는 것만 정확하게 넣는 편이 낫습니다.

리뷰 별점 스키마를 넣으면 검색 결과에 별이 뜨나요?

실제로 사이트에 표시되는 리뷰여야 합니다. 화면에 없는 별점을 스키마로만 넣는 것은 정책 위반이고, 자체 서비스에 대한 자기 리뷰(self-serving review)는 구글이 리치 결과로 표시하지 않습니다.

구조화 데이터, 어디부터 넣어야 하나요?

구조화 데이터가 왜 필요한가

화면에 적힌 “대표전화 062-714-1911”은 사람에게만 명확합니다. 기계에게는 그냥 문자열입니다. 그게 전화번호인지, 사업자번호인지, 우편번호인지 추측해야 합니다.

JSON-LD는 그 추측을 없앱니다.

{ "@type": "Organization", "telephone": "062-714-1911" }

이렇게 적으면 추측이 아니라 확정된 값이 됩니다. AEO 관점에서 이게 중요한 이유는, 답변엔진이 사실을 인용할 때 추측한 값보다 명시된 값을 신뢰하기 때문입니다.

우선순위

전부 한 번에 넣을 필요는 없습니다. 효과 대비 비용 순서로 정리하면 이렇습니다.

1순위 — Organization (또는 LocalBusiness)

전 페이지 공통으로 한 번만 넣으면 됩니다. 브랜드를 하나의 엔티티로 인식시키는 기반이라 가장 먼저 해야 합니다.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "정확한 상호",
  "url": "https://example.com",
  "description": "한 문장 정의",
  "email": "hello@example.com",
  "telephone": "02-0000-0000",
  "sameAs": [
    "https://blog.naver.com/우리계정",
    "https://www.instagram.com/우리계정"
  ]
}

@id를 정해 두면 다른 스키마에서 이 조직을 참조할 수 있습니다. 매번 조직 정보를 반복해 적을 필요가 없어집니다.

sameAs는 공식 채널 목록입니다. 확인된 채널만 넣으세요. 없는 URL이나 남의 계정을 넣으면 엔티티 병합이 오히려 깨집니다.

오프라인 매장이 있다면 LocalBusiness 계열(예: ProfessionalService)을 쓰고 주소·영업시간을 함께 넣는 편이 지역 질의에 유리합니다.

2순위 — BreadcrumbList

페이지 계층을 알려줍니다. 넣기 쉽고, 검색 결과에 탐색 경로가 표시되는 효과도 있습니다.

{
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "홈", "item": "https://example.com/" },
    { "@type": "ListItem", "position": 2, "name": "서비스", "item": "https://example.com/services/" }
  ]
}

item의 주소는 canonical과 글자 단위로 같아야 합니다. 끝 슬래시 유무가 다르면 다른 URL로 취급됩니다.

3순위 — FAQPage

AEO 관점에서 가성비가 가장 좋습니다. 질문과 답이 짝지어진 데이터라 답변엔진이 그대로 인용하기 좋은 형태입니다.

단, 화면에 실제로 보이는 FAQ여야 합니다. 스키마에만 있고 페이지에는 없는 FAQ는 정책 위반입니다.

접히는 아코디언으로 만들어도 됩니다. 다만 자바스크립트로 나중에 그려 넣는 방식은 피하세요. HTML 원문에 답 전문이 들어 있어야 크롤러가 읽습니다. <details> 요소를 쓰면 접힌 상태로도 원문에 답이 남습니다.

그다음 — 페이지 성격에 따라

페이지	스키마
블로그·아티클	`Article` / `BlogPosting`
절차 안내	`HowTo`
상품	`Product` + `Offer`
서비스 목록	`Service` + `OfferCatalog`
회사소개	`AboutPage`
문의	`ContactPage`
용어 정의	`DefinedTerm`

자주 나오는 실수

화면과 값이 다르다

가장 흔하고 가장 위험합니다. 가격을 바꿨는데 스키마는 그대로인 경우, 영업시간을 고쳤는데 JSON-LD는 예전 값인 경우.

화면과 스키마가 다르면 안 넣느니만 못합니다. AI에게 서로 다른 두 사실을 주는 셈이라 신뢰를 잃습니다.

이걸 막는 가장 확실한 방법은 같은 데이터를 화면과 스키마가 함께 읽게 만드는 것입니다. 설정 파일이나 CMS에서 값을 한 번만 정의하고, 화면 렌더링과 JSON-LD 생성이 그 값을 같이 참조하게 하면 어긋날 수가 없습니다.

URL 형식이 섞여 있다

https://example.com/services 와 https://example.com/services/ 는 다른 URL입니다. canonical, 사이트맵, 스키마의 item, 내부 링크가 서로 다른 형식을 쓰면 색인이 갈립니다.

호스팅 환경이 실제로 어느 쪽을 서빙하는지 확인한 뒤 거기에 전부 맞추세요.

있지도 않은 리치 결과를 노린다

별점, 가격, 재고 같은 항목은 실제 데이터가 있을 때만 의미가 있습니다. 자기 서비스에 대한 자체 리뷰는 구글이 리치 결과로 표시하지 않습니다.

검증하는 법

넣었으면 반드시 확인합니다.

리치 결과 테스트 — 구글이 무엇을 인식했는지 확인
스키마 마크업 검증기 — 문법 오류 확인
Search Console → 향상된 기능 — 실제 색인된 페이지에서 유효/오류 집계

배포 후에도 Search Console 쪽은 주기적으로 봐야 합니다. 사이트를 고치다가 스키마가 조용히 깨지는 일이 흔합니다.

정리

Organization → BreadcrumbList → FAQPage 순으로 시작하면 충분합니다
종류를 늘리는 것보다 화면과 값이 일치하는 것이 훨씬 중요합니다
화면과 스키마가 같은 데이터를 읽게 만들면 어긋남을 원천 차단할 수 있습니다
URL 형식(끝 슬래시)을 사이트 전체에서 통일하세요
넣은 뒤에는 리치 결과 테스트로 검증하고, Search Console에서 계속 확인합니다

스키마 설계와 검증은 나비랑의 구조화 데이터 서비스에서 다룹니다.