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

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

화면에 적힌 “대표전화 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 관점에서 가성비가 가장 좋습니다. 질문과 답이 짝지어진 데이터라 답변엔진이 그대로 인용하기 좋은 형태입니다.

사실 갱신(2026-08-13 확인): 구글은 FAQ 리치 결과 표시를 2026년 5월부로 종료했고 관련 문서도 삭제했습니다(구글 검색 문서 업데이트 로그). 즉 FAQPage를 넣는 목적은 이제 구글 리치 결과가 아니라 답변엔진이 읽는 질문-답 데이터입니다. 이 글의 권장 순위는 그 목적 기준으로 유지합니다.

단, 화면에 실제로 보이는 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에서 계속 확인합니다

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