Product 스키마 vs Article 스키마 — 언제 뭘 쓰나

한 줄 결론

사는 거면 Product, 읽는 거면 Article.

이 한 줄이 90% 케이스를 결정합니다. 페이지의 핵심 의도(transactional vs informational)가 어느 쪽인지로 판단하세요.

1. Product 스키마 — 언제 쓰나

페이지에서 직접 구매·예약·문의가 가능한 단일 상품을 다룰 때 사용합니다.

{
  "@type": "Product",
  "name": "iPhone 17 Pro",
  "image": "https://example.com/iphone17.jpg",
  "description": "...",
  "brand": { "@type": "Brand", "name": "Apple" },
  "offers": {
    "@type": "Offer",
    "price": "1490000",
    "priceCurrency": "KRW",
    "availability": "https://schema.org/InStock",
    "url": "https://example.com/iphone17"
  }
}

핵심은 offers입니다. 가격·통화·재고 상태가 있어야 진짜 Product입니다. 가격이 없는 페이지에 Product 마크업만 하면 의미가 없습니다.

전형적인 Product 페이지:

• 쇼핑몰 상품 상세
• SaaS 가격 페이지의 단일 플랜
• 부동산 매물 (RealEstateListing이 더 정확하지만 Product도 가능)
• 디지털 다운로드 상품

2. Article 스키마 — 언제 쓰나

읽기 위해 만들어진 콘텐츠에 사용합니다. 블로그 글·뉴스 기사·튜토리얼·리뷰 글 등.

{
  "@type": "Article",
  "headline": "iPhone 17 Pro 한 달 사용기 — 카메라 비교 위주",
  "description": "...",
  "author": { "@type": "Person", "name": "양경찬" },
  "datePublished": "2026-05-04",
  "image": "https://example.com/review-cover.jpg",
  "publisher": {
    "@type": "Organization",
    "name": "Schema:LAB"
  }
}

핵심은 headline, author, datePublished, publisher. 저자와 발행일이 있어야 진짜 Article입니다. AI 검색이 인용할 때 "양경찬이 2026년 5월 4일에 쓴 글에 따르면..."처럼 사용합니다.

전형적인 Article 페이지:

• 블로그 글
• 뉴스 기사
• 사용 후기·리뷰
• 가이드·튜토리얼
• 인터뷰

3. 결정 트리

헷갈리는 케이스에서는 다음 순서로 자문하세요.

1. 이 페이지의 1차 액션이 "구매·예약"인가, "읽기"인가?
   → 구매: Product
   → 읽기: Article로 가서 2번 질문

2. (Article로 갔다면) 페이지에 가격·재고가 노출되어 있고
   사용자가 그 자리에서 살 수 있는가?
   → 그렇다: Article + Product 둘 다 (Article이 메인)
   → 아니다: Article만

3. 한 페이지에서 여러 상품을 비교·소개하는가?
   → 그렇다: Article + `ItemList<Product>`
   → 단일 상품: 1번에서 결정한 대로

4. 헷갈리는 4가지 케이스

A. 어필리에이트/리뷰 블로그

Article(BlogPosting)이 메인. 그 안에 리뷰하는 제품들을 ItemList로 묶고, 각 항목을 Product로 마크업.

{
  "@type": "BlogPosting",
  "headline": "2026 무선이어폰 베스트 5",
  "author": {...},
  "datePublished": "...",
  "mainEntity": {
    "@type": "ItemList",
    "itemListElement": [
      {
        "@type": "ListItem",
        "position": 1,
        "item": {
          "@type": "Product",
          "name": "AirPods Pro 3",
          "offers": { "@type": "Offer", "price": "...", "url": "..." }
        }
      },
      ...
    ]
  }
}

이러면 검색엔진은 "이 글은 양경찬이 쓴 리뷰이고, 5개 제품을 비교한다"는 정확한 컨텍스트를 받습니다. 페이지를 Product로만 마크업하면 "이 페이지에서 AirPods를 직접 산다"고 잘못 이해해 어필리에이트 링크의 외부 이동이 spam으로 분류될 수 있습니다.

B. 쇼핑몰 상품 상세 + 블로그형 본문

Product가 메인. "제품 소개 글"이 본문에 길게 있어도 페이지의 1차 의도가 구매라면 Product를 메인 엔티티로. Article은 보조로 추가하지 말고 본문 마크업(description)을 풍부하게 쓰는 쪽이 안전합니다.

C. SaaS 가격 페이지

플랜이 1개면 Product 가능. 여러 플랜이라면 Product를 각각 마크업하지 말고 페이지를 WebPage로 두고 각 플랜은 Offer(또는 OfferCatalog)로 처리. 일반적으로 SaaS 가격 페이지는 마크업 없이 Organization + WebPage만으로도 충분합니다.

D. 뉴스 사이트의 상품 추천 기사

NewsArticle이 메인 + 추천 제품들은 Product 또는 ItemList<Product>. NewsArticle의 신뢰도와 Product의 풍부한 정보를 모두 활용.

5. 잘못 쓴 사례 3가지

6. 정확히 적용하면 노출이 어떻게 달라지나

페이지 종류	잘못된 마크업	정확한 마크업 결과
어필리에이트 리뷰	Product만	Article + ItemList → AI 답변에 "양경찬의 비교 리뷰에 따르면..." 형식으로 인용
쇼핑몰 상세	Article만	Product + Offer → 검색 결과에 가격·별점·재고 직접 노출
블로그 글	Product만	Article → 저자·발행일과 함께 인용, 신뢰도↑
뉴스 기사	Article (일반)	NewsArticle → 구글 뉴스 노출 자격 획득

직접 적용하기

판단이 어렵다면 진단부터 받으세요. 페이지 종류를 자동 분석해 적합한 스키마를 추천합니다.