JSON-LD @graph 사용법 — 한 페이지에 스키마 여러 개 쌓는 올바른 방법

스키마 마크업을 여러 개 추가했는데 리치 스니펫이 제대로 안 뜬다면, 태그를 분리해서 넣은 게 원인일 수 있다. @graph를 쓰지 않으면 구글이 스키마 간 관계를 파악하지 못하고, 그 결과 리치 결과 적용이 누락된다. 이 글은 그 구조적 차이를 정확히 설명한다.

제품 상세 페이지에 Product 스키마, FAQ 스키마, Organization 스키마를 각각 <script> 태그로 넣었다. 유효성 검사도 통과했다. 그런데 리치 스니펫은 일부만 뜨거나 아예 안 뜬다.

문제: 분리된 스키마 태그가 왜 불완전한가

한 이커머스 클라이언트의 상품 페이지를 분석했을 때 이런 구조였다:

<script type="application/ld+json">{ "@type": "Organization", ... }</script>
<script type="application/ld+json">{ "@type": "Product", ... }</script>
<script type="application/ld+json">{ "@type": "FAQPage", ... }</script>

각각의 JSON-LD는 유효하다. 하지만 구글 크롤러 입장에서는 이 셋이 서로 어떤 관계인지 알 수 없다. "이 Product를 판매하는 Organization이 누구인가?" — 크롤러가 추론해야 한다. 명시된 게 아니니 신뢰도가 낮아진다.

구글의 스트럭처드 데이터 파서는 @graph 배열 안에 있는 엔티티들을 하나의 지식 그래프 문서로 처리한다. 관계가 명시되면 크롤러가 엔티티 간 연결을 추론 없이 파악할 수 있어 파싱 효율이 높아진다. @graph 자체가 리치 결과를 보장하지는 않지만, 스키마 간 관계가 명확할수록 구글이 올바른 리치 결과 타입을 선택하는 데 도움이 된다.

핵심: @graph로 스키마 묶는 방법

올바른 구조는 <script> 태그를 하나만 쓰고, 그 안에 @graph 배열로 엔티티를 열거하는 것이다:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Corp",
      "url": "https://example.com"
    },
    {
      "@type": "Product",
      "@id": "https://example.com/product-a#product",
      "name": "제품명",
      "brand": { "@id": "https://example.com/#organization" },
      "offers": {
        "@type": "Offer",
        "price": "39000",
        "priceCurrency": "KRW",
        "availability": "https://schema.org/InStock"
      }
    },
    {
      "@type": "FAQPage",
      "@id": "https://example.com/product-a#faq",
      "mainEntity": [
        {
          "@type": "Question",
          "name": "배송은 얼마나 걸리나요?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "주문 후 평균 2~3 영업일 내 도착합니다."
          }
        }
      ]
    }
  ]
}

핵심은 @id다. "brand": { "@id": "..." } 한 줄이 Product와 Organization을 연결한다. 크롤러가 추론할 필요 없이 관계가 명시되어 있다.

자주 하는 실수

1. @context를 각 엔티티 안에 중복 선언 @graph를 쓰면 @context는 최상단에 한 번만. 안쪽 노드에 넣으면 파서가 혼선을 빚는다.

2. @id 없이 그냥 묶기 @graph 안에 넣었지만 @id가 없으면 엔티티 간 참조가 불가능하다. 그래프의 의미가 사라진다.

3. 페이지마다 다른 @id 형식 사용 @id는 사이트 전체에서 일관된 패턴을 써야 한다. /#organization, /#webpage 등 suffix를 규칙화해 두면 유지 관리가 쉽다.

4. 유효성만 확인하고 관계 검증 생략 Google Rich Results Test는 개별 스키마 유효성만 보여준다. Schema.org 관계 정합성은 직접 확인해야 한다.

실전 체크리스트

• <script type="application/ld+json"> 태그를 가급적 하나로 통합했는가 (여러 개도 기술적으로 유효하나, @graph 단일 태그가 관계 명시에 유리)
• @context는 최상단에만, @graph 배열 안 각 노드에는 없는가
• 모든 주요 엔티티에 @id가 부여되어 있는가 (URL + #suffix 형식 권장)
• 연관 엔티티는 "brand": { "@id": "..." } 형식으로 참조 연결했는가
• Google Rich Results Test + Schema Markup Validator 양쪽 모두 검증했는가

Wrap-up

@graph는 단순히 스키마를 모아 넣는 컨테이너가 아니다. 엔티티 간 관계를 구글이 읽을 수 있게 선언하는 구조다. 같은 유효성 점수라도 관계가 명시된 스키마와 분리된 스키마의 리치 결과 자격은 다르다.

---

실제 마케팅 실무 경험을 기반으로 작성했습니다.

---

이 주제와 관련해 SEO 또는 마케팅 자동화 프로젝트를 진행 중이시라면, 아래 버튼을 통해 문의를 남겨주세요. 검토 후 이메일로 답변드립니다.

문의하기 →