언어

JSON-LD 구조화된 데이터

JSON-LD와 schema.org의 차이, @context·@type·@id·@graph 문법, Google 권장 이유, 동적 삽입과 AI 크롤러 주의점 및 검증 방법을 설명합니다.

최초 게시: 2026년 6월 26일 · 최근 업데이트: 2026년 8월 22일 · Advanced
언어
AI작성자AI v2
이 페이지의 근거 신호 1개

JSON-LD는 schema.org 같은 어휘를 표현하는 연결 데이터 형식입니다. Google은 보이는 HTML과 분리돼 구현·유지 오류가 적다는 이유로 권장하지만 Microdata와 RDFa도 올바르면 동등하게 유효합니다. 보이는 콘텐츠만 마크업하고 JSON 문법·schema.org 어휘·Google 리치 결과 자격·라이브 파싱을 각각 검증하며, JavaScript 실행을 확인하지 못한 크롤러에는 서버 렌더링하세요.

요약 — JSON-LD(연결 데이터를 위한 JavaScript 객체 표기법)는 JSON을 기반으로 한 2014년 W3C 권고안이지만, 단순 JSON이 아니라 연결 데이터로 만드는 것은 @context입니다. Google은 보이는 HTML을 건드리지 않고 대규모 구현·유지가 가장 쉽다는 이유로 이 구조화된 데이터 형식을 권장합니다. 올바르게 구현했다면 Microdata와 RDFa도 동등하게 유효합니다. 핵심 문법은 @context(어휘, SEO에서는 주로 schema.org지만 사양은 다른 컨텍스트도 허용), @type(개체), @id(개체 상호 참조에 유용하지만 선택적인 안정적 URI)입니다. @id는 여러 유효한 패턴 중 하나인 @graph의 기반이지 필수 사항이 아닙니다. <head>나 <body> 어디에 두어도 Google이 허용합니다. Googlebot은 JS를 렌더링하므로 동적 JSON-LD도 Google에서는 작동합니다. 반면 테스트 당시 GPTBot과 ClaudeBot을 포함한 일부 AI 크롤러는 JS를 실행하지 않았습니다. 이는 공급자와 날짜에 따라 달라지므로 모든 AI 크롤러에 일반화하지 말고 직접 확인하며, 확인할 수 없다면 서버 렌더링하세요. 구조화된 데이터는 순위 신호가 아니며, 리치 결과 자격과 개체 이해를 지원하고 페이지에 보이는 콘텐츠를 설명해야 합니다.

JSON-LD는 어휘가 아니라 형식

혼동을 풀기 위한 첫 구분입니다. JSON-LD는 형식이고 schema.org는 어휘입니다. JSON-LD는 마크업을 어떻게 쓰는지, schema.org의 Article, Product, Organization 유형은 무엇을 말하는지 정합니다. 리치 결과는 그 둘 위에 놓인 기능 계층입니다. 이 문서는 형식을 다룹니다. AI용 어휘 관점은 AI용 스키마 마크업을 참고하세요.

JSON-LD는 2014년에 처음 발표된 W3C 권고안입니다. SEO 도입보다 먼저 등장했고 검색 전용이 아니라 웹 전체의 연결 데이터 상호운용성을 위해 설계됐습니다. 그래서 @id 같은 속성이 존재합니다. 많은 SEO 안내서가 놓치는 사양 수준의 핵심은 JSON-LD가 단순 JSON이 아니라는 것입니다. JSON 문법을 기반으로 하지만 데이터를 웹에서 식별하고 연결할 수 있게 하는 것은 @context 선언입니다. @context를 빼면 파서가 해석할 수 없는 데이터가 됩니다.

JSON-LD가 schema.org에만 종속된 것도 아닙니다. 사양은 @context가 공개된 어떤 어휘든 참조하도록 허용하며 자체 예시도 schema.org가 아닌 컨텍스트를 연결합니다. 따라서 ‘어떤 형식인가’의 답은 JSON-LD이고, ‘어떤 어휘인가’에는 검색·AI 검색 마크업에서 흔히 쓰는 schema.org가 답 하나입니다. 다른 어휘를 써도 유효한 JSON-LD일 수 있지만 더 이상 schema.org 마크업은 아닙니다.

JSON-LD와 Microdata, RDFa 비교

구조화된 데이터를 표현하는 방식은 세 가지이며 Google은 모두 지원합니다.

JSON-LDMicrodataRDFa
위치별도 <script> 블록HTML의 인라인 itemprop 속성HTML의 인라인 property 속성
보이는 HTML을 건드리나요?아니요예예
JS / 태그 관리자로 삽입 가능?예(깔끔함)번거로움번거로움
Google 입장권장지원지원
오류 가능성가장 낮음더 높음(마크업과 얽힘)더 높음(마크업과 얽힘)

Google의 권장은 명시적이지만 범위가 좁습니다. “In general, Google recommends using JSON-LD for structured data if your site’s setup allows it, as it’s the easiest solution for website owners to implement and maintain at scale (in other words, less prone to user errors).” (번역) 「사이트 설정에서 허용한다면 대규모 구현·유지가 가장 쉽고 사용자 오류가 적으므로 일반적으로 JSON-LD 사용을 권장합니다.」

같은 Google 페이지에는 경쟁 문서가 자주 생략하는 중요한 조건도 있습니다. “All 3 formats are equally fine for Google, as long as the markup is valid and properly implemented per the feature’s documentation.” (번역) 「마크업이 유효하고 기능 문서에 맞게 구현됐다면 세 형식 모두 Google에 똑같이 괜찮습니다.」 따라서 권장의 이유는 구현 편의성과 오류율이지 파싱 속도나 순위 우위가 아닙니다. Microdata를 사용해도 불이익은 없습니다. JSON-LD는 디자이너가 나중에 수정할 마크업과 구조화된 데이터가 얽히지 않아 실무에서 유리합니다.

문법: @context, @type, @id, 속성, 중첩

주석을 단 Article 블록은 다음과 같습니다.

<script type="application/ld+json">
{
  "@context": "https://schema.org",          // the vocabulary — the common value for SEO
  "@type": "Article",                          // the entity type
  "@id": "https://example.com/post#article",   // a stable URI for this entity
  "headline": "How JSON-LD Works",            // a property (key/value)
  "datePublished": "2026-06-26",
  "author": {                                  // a nested entity
    "@type": "Person",
    "name": "Patrick Stox",
    "url": "https://patrickstox.com/"
  }
}
</script>
  • @context — 의미 체계, 즉 어휘를 설정합니다. schema.org SEO 마크업에서는 보통 "https://schema.org"지만 규칙이 아니라 관례입니다. @context는 용어를 식별자에 매핑하며 사양은 다른 어휘도 가리키도록 허용합니다. 뒤따르는 모든 속성 이름을 파서가 해석하는 방법을 정하고 데이터를 연결 데이터로 만듭니다.
  • @type — Article, Product, Organization, BreadcrumbList 같은 개체를 선언하고 schema.org 유형에 매핑합니다. 적합한 유형 중 가장 구체적인 유형을 사용하세요. 맞는 경우 Article보다 NewsArticle을 택합니다.
  • @id — 리소스를 식별하는 고유 URI입니다. 한 개체에서 다른 개체를 참조하게 하며(아래 @graph 참조), 상호 참조할 대상에는 설정할 가치가 있지만 항상 필수는 아닙니다. JSON-LD 사양은 식별자가 없는 빈 노드를 허용하므로 다른 곳에서 참조하지 않는 개체는 @id 없이도 유효합니다.
  • 속성 — @context 어휘의 용어를 사용하는 일반 JSON 키/값 쌍입니다.
  • 중첩 — 하위 개체는 위의 author처럼 중첩 JSON 객체나 객체 배열로 표현합니다.

@graph 패턴(확장 가능한 방식)

대부분의 페이지에는 Organization, WebSite, BreadcrumbList, Article 또는 WebPage처럼 여러 개체가 필요합니다. 단순한 방식은 데이터를 반복하는 <script> 블록 네 개를 만드는 것입니다. 확장 가능한 대안은 단일 블록의 @graph 배열에 개체를 넣고 @id로 상호 참조하는 것입니다. JSON-LD 사양과 Google 모두 @graph를 유일한 패턴으로 요구하지 않습니다. 그래프를 표현하는 문법일 뿐이며 유형별 블록, 최상위 @graph 없는 중첩 객체, @id 없는 빈 노드 같은 다른 유효한 배치도 있습니다. 그러나 상호 참조할 개체가 여러 개인 사이트에서는 페이지마다 같은 Organization이나 WebSite 데이터를 반복하지 않게 해 줍니다.

Declare each entity once and connect the graph with stable `@id` references instead of repeating full objects. 출처: Nested Schema

One Organization is referenced as publisher by the WebSite and Article. The WebPage belongs to the WebSite and is connected to the Article. Each entity is declared once, and the same stable ID string is reused for every reference.

© Patrick Stox LLC · CC BY 4.0 · 

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#org",
      "name": "Example Co",
      "url": "https://example.com/"
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "publisher": { "@id": "https://example.com/#org" }   // reference, not a copy
    },
    {
      "@type": "WebPage",
      "@id": "https://example.com/post#webpage",
      "isPartOf": { "@id": "https://example.com/#website" },
      "breadcrumb": { "@id": "https://example.com/post#breadcrumb" }
    }
  ]
}
</script>

Organization을 한 번 정의한 뒤 다른 곳에서는 이름·로고·URL을 반복하지 말고 { "@id": "...#org" }로 가리키세요. 주요 CMS 스키마 플러그인이 출력을 만드는 방식이며 @id가 존재하는 이유입니다. Bing도 JSON-LD 중첩이 “makes defining links and relationships between data and entities… easy because it supports nested data.” (번역) 「중첩 데이터를 지원해 데이터와 개체 간 링크와 관계 정의를 쉽게 합니다.」라고 설명합니다.

위치: <head> 또는 <body>

Google은 둘 다 가능하다고 확인합니다. “You can put the JSON-LD data in the <head> or the <body> of the page.” (번역) 「JSON-LD 데이터는 페이지의 head나 body에 둘 수 있습니다.」 <head>가 관례지만 많은 CMS 플러그인이 <body> 끝에 삽입해도 문제없습니다. Bing도 “in the header, body or foot of the page.” (번역) 「페이지의 머리말·본문·꼬리말」에 둘 수 있다고 합니다. 유효한 블록을 body에서 head로 옮기는 데 시간을 쓰지 마세요. 아무것도 달라지지 않습니다. Evidence for this claim Google permits JSON-LD in either the head or body of an HTML document for supported structured-data features. Scope: Google Search JSON-LD guidance; markup must still match visible page content. Confidence: high · Verified: Google: Structured data introduction

JSON-LD 동적 생성과 AI 크롤러 함정

JavaScript로 JSON-LD를 동적으로 만들 수 있으며 Google은 두 방식을 문서화했습니다.

Evidence for this claim Dynamically generated structured data is acceptable to Google when it is rendered and complies with content and quality guidelines. Scope: Google Search JavaScript and structured-data guidance; crawlability and rendering remain prerequisites. Confidence: high · Verified: Google: Generate structured data with JavaScript
  1. Google Tag Manager — GTM 변수에서 값을 가져오는 JSON-LD가 들어 있는 Custom HTML 태그. 페이지와 태그 사이에 데이터를 중복하지 마세요.
  2. 맞춤 JavaScript — 스크립트 요소를 프로그래밍 방식으로 만듭니다. 
    const script = document.createElement('script');
script.setAttribute('type', 'application/ld+json');
script.textContent = structuredDataText;
document.head.appendChild(script);

Google이 페이지를 렌더링하므로 이는 Googlebot에서는 작동합니다. “Google Search can understand and process structured data that’s available in the DOM when it renders the page.” (번역) 「Google 검색은 페이지를 렌더링할 때 DOM에 있는 구조화된 데이터를 이해하고 처리할 수 있습니다.」

많은 안내서가 놓치는 함정이 있습니다. 일반적인 테스트에서 GPTBot과 ClaudeBot을 포함한 일부 AI 크롤러는 JavaScript를 실행하지 않았습니다. JSON-LD가 클라이언트 스크립트 실행 뒤에만 생기면 JS를 건너뛰는 크롤러는 이를 보지 못합니다. Google은 구조화된 데이터를 찾기 전에 DOM을 렌더링한다고 문서화했으므로 Googlebot에는 보여도 그 봇에는 보이지 않습니다.

AI 크롤러 동작에는 두 가지 정직한 단서가 필요합니다. Googlebot 쪽은 Google 문서에 근거하지만 AI 크롤러 쪽은 공개 사양이 아니라 개별 공급자 테스트와 보고에 근거합니다. 따라서 공급자·날짜에 따라 달라지며 JavaScript 지원은 바뀔 수 있고 모든 공급자를 직접 검증한 것도 아닙니다. ‘AI 크롤러는 JS를 건너뛴다’를 보편 규칙으로 삼지 말고 중요한 크롤러를 확인하세요. 확인할 수 없다면 서버 렌더링을 기본값으로 사용합니다. 서버 렌더링 HTML에 없고 해당 크롤러의 JS 실행을 확인하지 않았다면 보지 못한다고 가정하세요. AI 검색 노출을 위해서는 달리 검증하지 않은 JSON-LD를 정적 HTML에 서버 렌더링하세요. 구조화된 데이터 관점의 JavaScript 렌더링 문제는 JavaScript SEO를 참고하세요.

전자상거래에는 두 번째 주의점이 있습니다. Google은 동적으로 생성한 Product 마크업이 “can make Shopping crawls less frequent and less reliable,” (번역) 「쇼핑 크롤링 빈도와 신뢰성을 떨어뜨릴 수 있음」이라고 경고합니다. 가격과 재고가 빠르게 바뀌는 상품에는 실제 문제입니다. AI와 무관하게 상품은 서버 렌더링을 우선하세요.

정책(현재 실제 제재로 이어짐)

Google의 구조화된 데이터 가이드라인은 짧지만 핵심적입니다.

  • “Don’t mark up content that is not visible to readers of the page.” (번역) 「페이지 독자에게 보이지 않는 콘텐츠를 마크업하지 마세요.」
  • “Don’t mark up irrelevant or misleading content, such as fake reviews.” (번역) 「가짜 리뷰처럼 관련 없거나 오해를 부르는 콘텐츠를 마크업하지 마세요.」
  • “Put the structured data on the page that it describes.” (번역) 「구조화된 데이터는 그 데이터가 설명하는 페이지에 넣으세요.」
  • “Use the most specific applicable type and property names defined by schema.org.” (번역) 「schema.org가 정의한 가장 구체적인 적용 가능 유형과 속성 이름을 사용하세요.」
  • robots.txt나 noindex로 구조화된 데이터 페이지에 대한 Googlebot 접근을 막지 마세요.

보이는 콘텐츠 규칙을 꼭 기억하세요. 페이지에 나타나지 않는 콘텐츠를 설명하는 스키마는 원래부터 위반이었고 ‘보이지 않는’ 스키마에 대한 집행은 강화됐습니다. Bing은 “even though the markup is not visible on your page, it is still read by the search engines, and putting spam data in the markup can hamper your presence.” (번역) 「마크업이 페이지에 보이지 않아도 검색엔진은 읽으며, 스팸 데이터를 넣으면 검색 노출을 해칠 수 있습니다.」라고 직설적으로 경고합니다.

흔한 JSON-LD 실수

  • 보이는 페이지와 일치하지 않는 마크업 — #1 정책 문제입니다. 방문자에게 보이지 않는 평점을 JSON-LD에 넣는 경우입니다.
  • 잘못된 JSON — 끝 쉼표, 이스케이프하지 않은 따옴표, 또는 블록 전체를 조용히 깨뜨리는 워드 스마트 따옴표(" 대신 "). JSON-LD는 엄격합니다.
  • 잘못된 속성 이름 — schema.org에 없는 속성을 만들거나 실제 이름의 철자를 틀려 파서가 무시하게 됩니다.
  • 구체적 유형이 있는데 일반 유형 사용 — Recipe나 NewsArticle이 맞는데 Thing이나 Article을 씁니다.
  • 중복되고 불일치하는 Organization 블록 — 페이지마다 이름·로고가 충돌합니다.
  • 목표 리치 결과의 필수 속성 누락 — 기능별로 자체 필수 필드가 있습니다.
  • JS로 삽입한 마크업이 모든 크롤러에 보인다고 가정 — Google은 렌더링하지만 일부 AI 크롤러는 그렇지 않았으므로 크롤러별 확인이 필요합니다.

JSON-LD 검증

‘JSON-LD가 유효한가’라는 질문에는 서로 다른 네 가지 검사가 포함됩니다. 하나를 통과해도 나머지를 통과한 것은 아닙니다.

검사입증하는 것입증하지 못하는 것
JSON 파싱(모든 JSON 린터 또는 Rich Results Test의 파싱 단계)끝 쉼표·이스케이프하지 않은 따옴표·스마트 따옴표 오류가 없는 합법적인 JSON 문법속성 이름이 실제 schema.org 어휘인지, Google이 무엇인가 표시할지
Schema.org Validatorschema.org 어휘에 속성과 유형이 존재함Google이 그 유형을 리치 결과로 지원하는지, 특정 기능의 필수 필드가 있는지
Rich Results Test테스트한 렌더링 페이지의 마크업이 Google이 지원하는 특정 리치 결과 유형 요건을 충족함Google이 리치 결과를 실제로 표시할지(자격은 보장이 아님), 다른 검색·AI 시스템이 같은 방식으로 파싱할지
Google Search Console 개선사항 / 리치 결과 보고서실제 크롤링된 라이브 페이지에서 Google이 대규모로 파싱한 내용과 실제 오류실시간 상태. 보고서는 재크롤링보다 늦음
  • JS 렌더링 페이지는 붙여 넣은 코드가 아니라 URL로 테스트하세요. Rich Results Test의 코드 입력 모드는 라이브 URL 테스트처럼 스크립트를 실행하거나 상대 참조를 해석하지 않으므로 클라이언트 삽입 블록의 렌더링 후 모습을 알 수 없습니다.
  • Bing Webmaster Tools — Markup Validator — Bing은 2018년 8월부터 JSON-LD를 검증했습니다.
  • 이 검사들은 JavaScript를 렌더링하지 않는 크롤러를 대변하지 않습니다. 렌더링 URL 테스트는 Google이 보는 것을 확인할 뿐 JS를 건너뛰는 봇이 받는 것을 확인하지 않습니다.

JSON-LD가 SEO에 도움이 되나요?

기대치를 정직하게 설정하세요.

  • 순위 신호가 아닙니다. John Mueller는 구조화된 데이터가 사이트 순위를 높이지 않는다고 밝혔습니다.
  • 리치 결과 자격. 별점·가격·FAQ·이동 경로 같은 향상된 SERP 기능에 참여할 자격을 줍니다. 표시를 보장하지는 않습니다.
  • 간접적인 CTR. 더 풍부한 검색 결과가 클릭을 늘릴 수 있으며 대부분의 사이트에 실질적인 보상입니다.
  • 개체 이해. 검색엔진이 페이지를 알려진 개체와 Knowledge Graph에 연결하도록 돕습니다.
  • AI 검색. Bing의 Fabrice Canel은 2025년 스키마 마크업이 Microsoft LLM의 콘텐츠 이해를 돕는다고 확인했습니다. 다만 AI용 스키마 마크업의 통제 연구 단서처럼 이는 의미 구분을 위한 인프라이지 직접 인용을 얻는 수단은 아닙니다.

결론적으로 JSON-LD는 순위 편법이 아니라 리치 결과 자격, 명확한 개체 정보, AI/LLM 이해를 위해 구현하세요.

이 문서는 구조화된 데이터 허브에 속합니다. schema.org 어휘의 AI 관점은 AI용 스키마 마크업, 동적 삽입의 렌더링 원리는 JavaScript SEO를 참고하세요.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.