구조·마크업 · 공식 문서

JSON-LD @graph와 @id, 여러 스키마 연결 순서

노드마다 고유한 @id 를 붙이고, 다른 노드를 가리킬 때는 그 @id 만 담은 참조를 값으로 넣은 뒤, @graph 배열 하나에 노드를 나란히 담습니다. 구글은 한 페이지의 여러 항목을 중첩해도 따로 적어도 읽고, 이어 줄 항목은 @id 로 연결하라고 적었습니다.

글 페이지 하나에도 회사 정보, 사이트 정보, 이동 경로, 글 정보가 함께 붙습니다. 따로따로 적으면 검색엔진은 이 넷이 서로 어떤 관계인지 모를 수 있습니다.

JSON-LD 에서는 @id 로 노드에 이름표를 붙이고 @graph 로 한데 담습니다. 구글·W3C·schema.org 공식 문서로 묶는 순서를 정리했습니다. 키워드의 뜻은 「JSON-LD 뜻」 편에 자세히 적었습니다.

발견 01

구글은 한 페이지의 여러 항목을 중첩해도 따로 적어도 읽고, 이어 줄 항목은 @id 로 연결하라고 적었습니다

If there are items that are more helpful when they are linked together (for example, a recipe and a video), use @id in both the recipe and the video items to specify that the video is about the recipe on the page.

레시피와 동영상처럼 이어 줄 때 더 쓸모 있는 항목은 두 항목 모두에 @id 를 써서 그 동영상이 이 페이지 레시피에 관한 것임을 밝힌다.

Google Search Central 「General structured data guidelines」
항목구글 원문
두 방식 모두 읽음Google Search understands multiple items on a page, whether you nest the items or specify each item individually:구글 검색은 항목을 중첩하든 각각 따로 지정하든 한 페이지의 여러 항목을 이해한다.
중첩Nesting: When there is one main item, and additional items are grouped under the main item.중첩: 주인공 항목이 하나 있고, 다른 항목을 그 아래에 묶는 방식이다.
개별 항목Individual items: When each item is a separate block on the same page.개별 항목: 같은 페이지에서 항목마다 따로 블록을 두는 방식이다.
연결하지 않으면If you didn't link the items together, Google Search may not know that it can show the video as a Recipe rich result.항목을 이어 주지 않으면 구글은 그 동영상을 레시피 리치 결과로 보여 줄 수 있다는 것을 모를 수 있다.
주인공 유형To make sure that Google Search understands what the main purpose of the page is, include the main type of structured data that reflects the main focus of the page.구글 검색이 페이지의 주된 목적을 이해하도록, 페이지의 중심 주제를 나타내는 대표 구조화 데이터 유형을 넣는다.
한국어판 표기는 「여러 항목이 있는 페이지」·「중첩」·「개별 항목」입니다.

중첩은 주인공 항목 안에 다른 항목을 넣는 방식이고, 개별 항목은 블록을 나란히 두는 방식입니다. @id 연결은 개별 항목끼리 관계를 알려 주는 방법입니다.

구글 문서의 개별 항목 예시는 맨 바깥에 배열을 썼습니다. @graph 는 W3C 표준이 정한 문법으로, 노드를 배열에 담으면서 @context 를 한 번만 적게 해 줍니다.

발견 02

@id 는 노드의 고유 이름표이고, 다른 노드를 가리킬 때는 @id 만 담은 참조를 씁니다

키워드W3C 원문
@idUsed to uniquely identify node objects that are being described in the document with IRIs or blank node identifiers.@id 는 문서가 설명하는 노드를 IRI 나 빈 노드 식별자로 고유하게 식별한다.
노드 참조A node reference is a node object containing only the @id property, which may represent a reference to a node object found elsewhere in the document.노드 참조는 @id 속성 하나만 담은 노드 객체로, 문서의 다른 곳에 있는 노드 객체를 가리킬 수 있다.
@graphThe @graph keyword collects such nodes in an array and allows the use of a shared context.@graph 키워드는 그런 노드들을 배열에 모으고, @context 를 함께 쓰게 해 준다.
@graph 가 쓸모 있는 때This mechanism can be useful when a number of nodes exist at the document's top level that share the same context, which is, e.g., the case when a document is flattened.같은 @context 를 쓰는 노드 여럿이 문서 맨 바깥 단계에 있을 때(예: 평탄화한 문서) 이 방식이 쓸모 있다.
W3C 「JSON-LD 1.1」의 키워드 정의와 4.9 절 원문입니다.

참조는 같은 문서 안의 노드를 가리킵니다. 그래서 글 페이지에서 회사를 author 로 가리키려면, 그 페이지의 @graph 에도 Organization 노드를 함께 둡니다.

@id 값은 URL 형식이면 됩니다. 페이지 URL 뒤에 #article 처럼 붙이면 페이지마다 겹치지 않는 이름이 만들어집니다.

발견 03

글 페이지 하나의 @graph 에는 노드 5개가 참조 5개로 이어집니다

노드(@type)@id 예가리키는 노드
Organizationhttps://example.com/#organization없음
WebSitehttps://example.com/#websitepublisher → #organization
BreadcrumbListhttps://example.com/blog/post-1#breadcrumb없음
WebPagehttps://example.com/blog/post-1#webpageisPartOf → #website, breadcrumb → #breadcrumb
Articlehttps://example.com/blog/post-1#articlemainEntityOfPage → #webpage, author → #organization
이해를 돕기 위한 예시입니다. 노드마다 필수 속성(name·url·headline 등)은 구글 기능 문서대로 따로 채웁니다.
참조 속성어느 노드에서공식 문서 원문
publisherWebSiteThe publisher of the article in question.그 글의 발행자.
isPartOfWebPageIndicates an item or CreativeWork that this item, or CreativeWork (in some sense), is part of.이 항목이 어떤 항목이나 저작물의 일부인지 나타낸다.
breadcrumbWebPageA set of links that can help a user understand and navigate a website hierarchy.사용자가 웹사이트 계층을 이해하고 이동하도록 돕는 링크 모음.
mainEntityOfPageArticleIndicates a page (or other CreativeWork) for which this thing is the main entity being described.이것이 주인공으로 설명되는 페이지(또는 다른 저작물)를 나타낸다.
authorArticleIf the author is an organization, you could link to the organization's home page.저자가 조직이라면 조직의 홈페이지로 연결할 수 있다.
isPartOf·mainEntityOfPage·publisher·breadcrumb 정의는 schema.org, author 는 구글 Article 문서 원문입니다.
어디에 두나구글 원문
회사 정보We recommend placing this information on your home page, or a single page that describes your organization, for example the about us page.조직 정보는 홈페이지나 조직을 설명하는 페이지 하나(예: 회사 소개)에 두기를 권한다.
저자 식별Google can understand both sameAs and url when disambiguating authors.구글은 저자를 구분할 때 sameAs 와 url 을 모두 이해한다.
사이트 이름 노드If you already have WebSite structured data on your site, make sure that you nest the site name properties in the same node.사이트에 이미 WebSite 구조화 데이터가 있다면, 사이트 이름 속성을 같은 노드 안에 넣으세요.
회사 정보는 홈페이지나 회사 소개 페이지에 속성을 가장 많이 채우고, 다른 페이지에서는 같은 @id 로 이어 줍니다.

발견 04

묶는 순서는 7단계이고, 사이트 이름을 담는 WebSite 노드는 하나만 둡니다

순서할 일
1페이지에 담을 노드를 정합니다. 주인공 유형(글이면 Article, 상품이면 Product)을 먼저 고릅니다.
2노드마다 @id 를 정합니다. 그 노드가 설명하는 URL 뒤에 #organization·#article 같은 이름을 붙이면 페이지마다 다른 이름이 됩니다.
3같은 회사·사이트 노드는 모든 페이지에서 같은 @id 를 씁니다.
4<script type="application/ld+json"> 하나에 @context 를 한 번 적고, @graph 배열에 노드를 나란히 넣습니다.
5노드끼리 가리킬 때는 { "@id": "…" } 만 담은 참조를 값으로 넣습니다.
6WebSite 노드는 하나만 둡니다. 사이트 이름 속성(name·alternateName)도 그 노드에 넣습니다.
7리치 결과 테스트로 주인공 유형이 감지되는지, 스키마 마크업 검사기로 문법 오류가 없는지 봅니다.
WebSite 노드를 하나로 두는 이유는 「구글 검색 사이트 이름 변경」 편에 자세히 적었습니다.

발견 05

B2B·B2C·B2G 사이트마다 주인공 노드가 다릅니다

예시 ① 기술 블로그를 운영하는 SaaS 회사(B2B)

글 페이지의 주인공은 Article 이고, author 는 글쓴이 Person 이나 회사 Organization 을 가리킵니다. 저자 소개 페이지 URL 을 url 로 넣으면 저자를 구분하기 쉽습니다.

예시 ② 상품 상세 페이지가 많은 쇼핑몰(B2C)

주인공은 Product 이고, WebPage 의 breadcrumb 이 카테고리 이동 경로를 가리킵니다. 판매자 정보는 Organization 노드 하나를 같은 @id 로 모든 상품 페이지에서 씁니다.

예시 ③ 보도자료를 싣는 공공기관 누리집(B2G)

보도자료 페이지의 주인공은 Article 계열이고, publisher 는 기관 Organization 노드를 가리킵니다. 기관 이름 표기를 모든 노드에서 하나로 맞춥니다.

그럼 지금 페이지의 JSON-LD 는 어떻게 정리하나요?

  1. 페이지 소스에서 application/ld+json 블록을 모두 찾아 몇 개인지, 블록마다 @type 이 무엇인지 적습니다.
  2. WebSite·Organization 블록이 두 번 이상 나오면 하나로 합칠 목록에 올립니다.
  3. 위 7단계대로 @id 를 정하고 @graph 하나로 옮깁니다.
  4. 템플릿에서 만드는 사이트라면 @id 규칙을 코드 한 곳에 두고 모든 페이지가 그것을 쓰게 합니다.
  5. 배포 뒤 리치 결과 테스트와 스키마 마크업 검사기로 확인합니다. 생성기로 만든 코드를 고치는 순서는 「JSON-LD 생성기」 편에 자세히 적었습니다.

조사 방법

  • Google Search Central 「General structured data guidelines」 (문서 수정일 2026-07-10) · 최종 확인일 2026-10-25 · https://developers.google.com/search/docs/appearance/structured-data/sd-policies
  • Google Search Central 「Organization (Organization) structured data」 (문서 수정일 2026-09-08) · 최종 확인일 2026-10-25 · https://developers.google.com/search/docs/appearance/structured-data/organization
  • Google Search Central 「Article (Article, NewsArticle, BlogPosting) structured data」 (문서 수정일 2026-09-08) · 최종 확인일 2026-10-25 · https://developers.google.com/search/docs/appearance/structured-data/article
  • Google Search Central 「Provide a site name to Google Search」 (문서 수정일 2025-12-10) · 최종 확인일 2026-10-25 · https://developers.google.com/search/docs/appearance/site-names
  • W3C Recommendation 「JSON-LD 1.1: A JSON-based Serialization for Linked Data」 (문서 수정일 2020-07-16) · 최종 확인일 2026-10-25 · https://www.w3.org/TR/json-ld11/
  • Schema.org 「isPartOf」 (문서 수정일 2026-09-16) · 최종 확인일 2026-10-25 · https://schema.org/isPartOf
  • Schema.org 「mainEntityOfPage」 (문서 수정일 2026-09-16) · 최종 확인일 2026-10-25 · https://schema.org/mainEntityOfPage
  • Schema.org 「publisher」 (문서 수정일 2026-09-16) · 최종 확인일 2026-10-25 · https://schema.org/publisher
  • Schema.org 「breadcrumb」 (문서 수정일 2026-09-16) · 최종 확인일 2026-10-25 · https://schema.org/breadcrumb
  • 노드 5개와 참조 5개, 순서 7단계는 위 문서들의 정의를 글 페이지 하나에 맞춰 묶은 것입니다. 묶는 방식과 @id 이름 규칙은 편집 판단입니다.
  • 구글 문서는 @graph 를 따로 다루지 않습니다. @graph 의 뜻은 W3C 표준 원문을 따랐습니다.
  • 예시 ①②③과 @graph 예시는 이해를 돕기 위해 만든 가상 상황이며, 실제 기업·기관의 사례가 아닙니다.
  • 구글 원문은 영어판(hl=en)이고, 도구·절 이름은 같은 문서 한국어판(hl=ko) 표기를 따랐습니다. W3C·schema.org 문서는 영어 원문만 있습니다.