한 패션 자사몰의 상세 페이지를 연다. 사람의 눈에 보이는 정보는 충분하다. 이미지, 가격, 사이즈, 소재. 그 페이지의 HTML 소스를 열어 본다. 검색엔진과 AI가 보는 텍스트가 거의 비어 있다. 사람이 보는 페이지와 기계가 읽는 페이지가 따로 있다. 둘 사이의 격차가 AI 검색 시대의 매출을 가른다.
기계가 읽는 페이지의 표준 문법은 하나다. JSON-LD다.
1. 왜 JSON-LD인가
JSON-LD는 'JavaScript Object Notation for Linked Data'의 약자다. Google이 2015년부터 공식적으로 권장하는 단 하나의 구조화 데이터 포맷이고, OpenAI·Anthropic·Perplexity가 인용 우선 순위를 부여하는 형식이다. Microdata나 RDFa도 표준이지만, AI 시대에는 사실상 JSON-LD 외의 선택지가 없다.
JSON-LD는 페이지 본문과 분리된 별도 블록에 들어간다. 사람의 화면에는 보이지 않지만, 기계는 이 블록을 먼저 읽는다. 결과적으로 같은 페이지가 기계에게는 더 풍부한 페이지가 된다.
2. 패션 상세 페이지의 필수 8개 스키마
패션 자사몰 제품 상세 페이지에 들어가야 하는 schema.org 타입은 여덟 개다. Product(제품 본체), Offer(가격·재고), Brand(브랜드), AggregateRating(별점), BreadcrumbList(경로), ImageObject(이미지 메타), Organization(운영사), FAQPage(자주 묻는 질문). 이 여덟 개가 한 페이지 안에 함께 있어야 AI가 그 페이지를 '제품으로서 인용 가능한 단위'로 인식한다.
여덟 중 하나만 빠져도 인용 우선 순위에서 밀린다. 분포는 분명하다. Net-a-Porter·Mr Porter·Farfetch는 여덟 개 모두 채우고, 한국 자사몰은 평균 세 개에서 멈춘다.
- 스키마란 - 데이터베이스의 구조와 제약조건에 관해 전반적인 명세를 기술한 것
3. Product의 핵심 필드
Product 스키마에서 비워두면 안 되는 필드는 일곱 개다. name(제품명), image(이미지 URL 배열), brand(브랜드 객체 참조), sku(자사 식별자), gtin(글로벌 표준 식별자), description(200자 이상 본문), 그리고 색상·사이즈·소재를 담는 추가 속성. 가장 자주 빠지는 것은 description과 gtin이다. description은 200자 미만으로 형식적으로 채운 경우가 대부분이고, gtin은 도입조차 안 한 경우가 많다.
description의 두께는 AI가 그 제품을 '아는' 정도를 결정한다. 두 줄짜리 설명은 두 줄짜리 답을 만든다.
- GTIN(Global Trade Item Number, 국제거래단품식별코드)은 국제표준기구(GS1)에서 관리하는 상품 및 서비스의 글로벌 고유 식별자
4. Offer와 PriceSpecification
Offer 스키마는 가격, 통화, 재고 상태, 유효 기간을 담는다. priceCurrency는 ISO 4217 코드(KRW, USD, EUR), availability는 'InStock', 'OutOfStock', 'PreOrder' 같은 표준 enum 값. 여기서 한국 자사몰이 가장 자주 빠뜨리는 것은 priceValidUntil(가격 유효 기한)과 itemCondition(제품 상태)이다.
AI가 가격 비교를 대신하는 시대에, Offer가 비어 있는 페이지는 '가격이 없는 제품'으로 읽힌다. 가격이 없는 제품은 비교 대상에 들어가지 않는다.
5. Net-a-Porter·Mr Porter의 실제 마크업
Net-a-Porter 상세 페이지 소스를 열어 보면 Product 안에 Offer가 두세 개 들어가 있다. 정상가 Offer, 할인 Offer, 사이즈별 Offer. AggregateRating은 자체 리뷰가 없는 신상품도 카테고리 평균을 빌려 채워둔다. ImageObject는 룩북 사진까지 image 배열에 포함시킨다. FAQPage는 사이즈·관리·반품 정보를 별도 블록으로 마크업한다.
같은 페이지 안에서 메인 콘텐츠는 짧고 JSON-LD는 길다. 기계에게는 풍부한 페이지, 사람에게는 가벼운 페이지. 두 얼굴을 한 페이지에 담는 게 핵심 기술이다.
6. 한국 패션 자사몰의 누락 패턴
한국 패션 자사몰을 7개 점검해 보면 누락 패턴이 같다. Product는 있지만 brand가 텍스트로만 들어가 있고 객체 참조가 없는 경우. Offer는 있지만 priceCurrency가 빠져 있어 통화가 불분명한 경우. ImageObject 없이 image가 단순 URL 문자열인 경우. FAQPage·BreadcrumbList·Organization은 아예 도입조차 안 된 경우가 가장 많다.
대형 자사몰조차 평균 세 개에서 멈춘다. Cafe24·Imweb 같은 빌더 기반 스킨이 만든 구조적 천장이다.
7. 이번 분기 한 번에 잡는 8단계 체크리스트
여덟 개 스키마를 한 번에 도입하기 어렵다면 우선순위는 이렇다. 1단계 Product의 description 200자 이상으로 보강. 2단계 Offer의 priceCurrency·availability 정리. 3단계 brand를 객체 참조로 전환. 4단계 BreadcrumbList 추가. 5단계 ImageObject로 룩북 이미지 마크업. 6단계 FAQPage 도입. 7단계 Organization을 사이트 전역에 배치. 8단계 AggregateRating 도입. 1~3단계만 해도 Google Rich Results Test 통과 비율이 두 배가 된다.
다시 처음의 자사몰로 돌아간다. 사람의 눈에 보이는 페이지는 그대로다. 변한 것은 기계가 읽는 페이지의 두께다. 그 두께가 다음 분기 매출의 차이를 만든다.
사람이 보는 페이지가 단순히 매출을 만드는 것이 아니다. 기계가 읽는 페이지가 다음 매출을 만든다.
실제로 어디서 볼 수 있나
schema.org/Product — 전체 필드 목록 + 각 필드 설명
https://schema.org/Product
페이지 들어가면 name, brand, offers, sku... 다 정의돼 있음
schema.org/ItemAvailability — InStock 같은 enum 값들
https://schema.org/ItemAvailability
구글의 활용 가이드 (구글이 어떤 필드를 리치결과에 쓰는지)
https://developers.google.com/search/docs/appearance/structured-data/product
여기엔 '필수 필드' / '권장 필드'가 따로 표시됨. 예: offers.price는 리치결과에 필수.
검증 도구 — 입력한 JSON-LD가 제대로 작성됐는지 확인
https://validator.schema.org/ (schema.org 공식 검증)
https://search.google.com/test/rich-results (구글이 인식하는지 + 리치결과 미리보기)
NAP URL 그대로 붙여넣으면 위 JSON-LD가 어떻게 파싱되는지 보임.
한 줄 정리
schema.org가 사전을 만들고, 구글이 그 사전을 검색 결과에 어떻게 쓸지 결정하고, NAP은 그 사전의 어휘로 자기 상품을 기술한다.
구글 리치결과 — 두 단계로 갈림
A. Product snippet (기본 카드: 이름·이미지·가격 단순 표시)
필수 3개:
name — 상품명
image — 최소 1개 URL (고해상도 권장: 가로 1200px+)
그리고 다음 셋 중 최소 하나:
review
aggregateRating
offers
→ 사실상 name + image + offers 조합이 디폴트.
B. Merchant listing (가격·재고·배송이 카드에 직접 박히는 풀 리치결과)
필수:
name
image
offers — 안에 다음 필수:
price (또는 priceSpecification.price)
priceCurrency (ISO 4217: USD, KRW, EUR…)
availability — schema.org enum 중 하나 (InStock 등)
강력 권장 (이게 빠지면 카드 약해짐):
brand — 브랜드명
sku 또는 gtin8/gtin12/gtin13/gtin14/mpn — 식별자
description
review / aggregateRating — 별점 카드
offers.url — 구매 링크
offers.itemCondition — 신품/중고
offers.priceValidUntil — 가격 유효기한 (할인 표시에 필수)
offers.hasMerchantReturnPolicy — 반품 정책
offers.shippingDetails — 배송 정보
③ ProductGroup (사이즈·컬러 변형 묶음) — NAP이 쓴 방식
필수 3개:
productGroupID — 마스터 ID
variesBy — 무엇이 변형되는지 (size, color 등 schema.org enum)
hasVariant — 변형 Product 배열
→ 패션·신발처럼 사이즈/컬러 있는 카테고리는 이걸 안 쓰면 변형마다 별도 페이지로 인덱싱되어 SEO 분산.
우리가 본 NAP 페이지 채워진 상태 점검
체크리스트로 보면 NAP은 거의 만점:
항목 필수/권장 NAP 채움
name 필수 ✓
image 필수 ✓ (4컷)
offers.price 필수 ✓ (670.00)
offers.priceCurrency 필수 ✓ (USD)
offers.availability 필수 ✓ (InStock)
brand 강력권장 ✓ (AURALEE)
sku 강력권장 ✓
description 권장 ✓
itemCondition 권장 ✓ (NewCondition)
hasMerchantReturnPolicy 권장 ✓
productGroupID/variesBy/hasVariant 변형 필수 ✓
review/aggregateRating 권장 ✗ (이 페이지엔 없음)
priceValidUntil 할인 시 필수 해당없음
shippingDetails 권장 해당없음 (별도 페이지)
빠진 거 거의 없음. 딱 하나 비어있는 게 review/aggregateRating — NAP은 리뷰 시스템을 의도적으로 안 둠 (럭셔리 포지셔닝, '대중 리뷰가 가치를 깎는다'는 판단).
자사몰에 적용한다면
최소 이만큼은 깔아야 NAP과 같은 카드 형태로 구글 쇼핑에 잡힘:
{
"@context": "https://schema.org",
"@type": "Product",
"name": "...",
"image": ["https://.../1200.jpg"],
"brand": {"@type": "Brand", "name": "WOOYOUNGMI"},
"sku": "...",
"description": "...",
"offers": {
"@type": "Offer",
"url": "...",
"price": "...",
"priceCurrency": "KRW",
"availability": "https://schema.org/InStock",
"itemCondition": "https://schema.org/NewCondition"
}
}
이게 마지노선. 변형(사이즈)이 있으면 ProductGroup으로 감싸기. 여기서 brand·sku·itemCondition을 빼면 '카드'가 아니라 '텍스트 링크'로만 노출됨 — 클릭률 격차가 곧 매출 격차.