웹사이트의 모든 페이지에 schema가 있어도 AI 엔진은 이 WebPage가 어느 사이트에 속하는지, 그 사이트를 누가 운영하는지 파악하지 못할 수 있습니다. 문제는 태그 수가 아니라 태그끼리 서로 연결되어 있지 않다는 데 있습니다. Organization, WebSite, WebPage를 각각 독립된 JSON-LD로 작성하는 것은 기계에 서로 연관이 없는 명함 세 장을 건네는 것과 같습니다. @graph는 이 명함들을 명확한 관계로 연결해 AI가 사이트 전체의 엔터티 구조를 한 번에 이해하도록 합니다.
분산된 schema로는 AI가 사이트 구조를 완성할 수 없는 이유
대부분의 웹사이트는 플러그인이나 CMS 템플릿으로 schema를 자동 생성합니다. 홈페이지에는 Organization, 콘텐츠 페이지에는 Article, 요금 페이지에는 Product가 각각 별도의 schema로 출력됩니다. 개별 마크업만 보면 유효하고 Rich Results Test도 통과할 수 있습니다. 하지만 기계가 “이 글의 발행 주체는 누구이며 신뢰할 수 있는가?”를 판단하려 하면 문제가 생깁니다. Article의 publisher가 홈페이지의 Organization과 동일하다는 사실을 알려 주는 필드가 없어, 서로 무관한 객체만 떠다니기 때문입니다. 특히 AI 요약 및 답변 엔진은 콘텐츠를 실제로 확인할 수 있는 조직과 연결할 수 있는지를 인용 판단의 중요한 기준으로 삼습니다. 이 관계가 없으면 기업의 공식 정보도 출처를 알 수 없는 텍스트로 취급될 수 있습니다.
@graph는 정확히 무엇을 하는가
@graph는 JSON-LD의 최상위 필드이며, 값으로 여러 엔터티 객체를 담는 배열을 사용합니다. 원래 여러 script 태그로 나눌 엔터티를 하나의 파일과 네임스페이스 안에 구성하는 방식입니다. 핵심은 단순히 “한곳에 모으는 것”이 아닙니다. 각 객체가 @id로 서로를 지칭할 수 있다는 점이 중요합니다. Organization에 @id를 선언하고 WebSite의 publisher에 같은 @id를 입력하면, 기계는 두 값이 동일한 엔터티를 가리킨다는 사실을 이해합니다. Organization 전체를 다시 복사할 필요도 없습니다. 한 번 정의하고 어디서나 참조하는 방식은 지식 그래프의 기본 원리입니다. schema.org가 @graph를 지원하는 이유도 페이지가 속성만 나열하는 데 그치지 않고 엔터티 간 관계를 표현할 수 있게 하기 위해서입니다.
페이지 하나의 @graph는 script 태그 하나로 충분합니다. 이 방식은 여러 플러그인이 동일한 Organization을 제각각 생성해 속성이 충돌하는 고질적인 문제도 해결합니다. @graph에서는 회사 엔터티가 한 번만 등장하므로 사이트 전체의 단일 기준 정보가 됩니다. 유지보수할 때도 한 곳만 수정하면 됩니다.
@id: 각 엔터티에 변하지 않는 주소 부여하기
@id는 이 작성 방식의 기반입니다. 도메인 전체에서 고유한 식별 문자열이며, 일반적으로 https://example.com/#organization처럼 URL 뒤에 해시 조각을 붙여 사용합니다. 이 주소는 실제로 열리지 않아도 됩니다. 링크가 아니라 식별자 역할을 하기 때문입니다. 사이트 어디에서든 같은 엔터티에 동일한 @id를 사용하면 AI는 여러 페이지에 흩어진 정보를 하나의 주제로 묶을 수 있습니다. 홈페이지, 콘텐츠 페이지, 요금 페이지에 같은 @id가 등장하면 기계는 각 페이지의 회사 설명을 합쳐 더 완전하고 위조하기 어려운 엔터티 정보를 구성합니다.
- Organization에는 https://example.com/#organization처럼 도메인 루트와 조각 식별자를 조합합니다. 사이트 전체에서 고유하며 항상 같은 회사를 가리켜야 합니다.
- WebSite에는 도메인 루트와 #website를 조합해 웹사이트 전체를 하나의 엔터티로 나타냅니다.
- 각 페이지의 WebPage에는 “페이지 URL + #webpage”를 사용합니다. 페이지에 따라 값이 달라집니다.
- 조각 식별자의 명명 규칙은 팀 내에서 #organization, #website, #webpage처럼 통일합니다. 오늘은 #org, 내일은 #company로 바꾸면 안 됩니다.
- 운영 환경에 적용한 @id는 임의로 변경하지 마세요. 값을 바꾸면 새 엔터티를 만드는 것과 같아 지금까지 축적한 연결 관계가 모두 끊어집니다.
세 엔터티는 어떻게 서로를 참조하는가
연결 방향은 작은 단위에서 큰 단위로, 즉 페이지에서 운영 주체로 이어집니다. WebSite는 publisher로 Organization을 가리켜 이 회사가 사이트를 운영한다는 사실을 알립니다. 각 WebPage는 isPartOf로 WebSite를 가리켜 자신이 해당 사이트의 일부임을 선언합니다. 회사 자체를 다루는 페이지라면 회사 소개나 요금 안내처럼 about 또는 mainEntity로 Organization을 다시 참조합니다. 콘텐츠 페이지에서는 Article의 publisher도 같은 Organization의 @id를 가리키게 하면 발행 주체 관계가 완성됩니다.
바로 적용할 수 있는 완성형 예제
아래 @graph를 페이지의 <head>에 넣으면 하나의 script 태그로 세 엔터티를 구성할 수 있습니다. 각 엔터티는 @id를 한 번만 선언하고, Organization을 다시 복사하는 대신 @id로 서로를 참조합니다. 실무에서는 Organization과 WebSite를 사이트 전체가 공유하는 템플릿으로 분리해 한 번만 작성합니다. WebPage에는 각 페이지의 url, name, @id를 동적으로 삽입할 수 있습니다. { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://example.com/#organization", "name": "Example company", "url": "https://example.com/", "logo": { "@type": "ImageObject", "url": "https://example.com/logo.png" }, "sameAs": [ "https://www.linkedin.com/company/example", "https://x.com/example" ] }, { "@type": "WebSite", "@id": "https://example.com/#website", "url": "https://example.com/", "name": "Example", "publisher": { "@id": "https://example.com/#organization" } }, { "@type": "WebPage", "@id": "https://example.com/pricing#webpage", "url": "https://example.com/pricing", "name": "Pricing plan", "isPartOf": { "@id": "https://example.com/#website" }, "about": { "@id": "https://example.com/#organization" } } ] }
가장 자주 발생하는 네 가지 오류
- @id가 일치하지 않습니다. 홈페이지에는 #organization을 쓰고 콘텐츠 페이지의 publisher에는 다른 전체 URL을 넣거나 해시 조각을 빠뜨리면, 기계는 이를 서로 다른 두 회사로 인식합니다.
- 참조만 넣어야 할 자리에 전체 객체를 삽입합니다. publisher 안에 Organization 전체를 다시 작성하면 동일한 엔터티가 두 개 생기며 속성끼리 충돌할 수 있습니다.
- 엔터티가 연결되지 않은 채 떠 있습니다. WebPage에 isPartOf가 없고 Article에 publisher가 없으면 객체 자체는 유효하더라도 상위 엔터티와 분리됩니다.
- 변동되는 URL을 @id로 사용합니다. 추적 매개변수나 세션에 따라 URL이 바뀔 때마다 새 엔터티가 생성되고 모든 연결 관계를 처음부터 다시 쌓게 됩니다.
AI의 신뢰를 얻는 데 필요한 것은 많은 태그가 아니라 엔터티를 충분히 명확하게 연결하는 일입니다.
운영 환경에 적용하기 전 반드시 확인할 세 가지
마크업을 넣었다고 해서 구현이 끝난 것은 아닙니다. 먼저 Rich Results Test 또는 Schema Markup Validator에 전체 @graph를 붙여 넣고 구문 오류가 없는지 확인합니다. 다음으로 많은 팀이 놓치는 검증을 진행해야 합니다. 참조된 @id를 하나씩 찾아 같은 그래프 안에 실제로 정의되어 있는지 대조하세요. 존재하지 않는 식별자를 가리켜서는 안 됩니다. 마지막으로 브라우저에서 페이지를 불러와 렌더링된 HTML을 살펴보고 script가 실제로 출력되었는지 확인합니다. 많은 SSR 또는 CMS 환경에서 이 단계에 마크업이 조용히 누락됩니다. 엔터티 연결은 적은 작업 시간으로 큰 효과를 기대할 수 있는 테크니컬 GEO 영역이며, AI가 사이트를 신뢰할 수 있는 출처로 판단하는 데 직접적인 영향을 줍니다. Organization, WebSite, WebPage가 제대로 연결되었는지, publisher 관계가 끊기지는 않았는지 확신하기 어렵다면 30분 GEO 진단을 예약할 수 있습니다. 실제 렌더링된 HTML을 수집해 누락된 연결을 하나씩 짚어 드립니다.
