JSON-LD란? 구조화 데이터 포맷 완벽 가이드

구조화 데이터, schema.org, JSON-LD는 층이 다르다 구글이 세 포맷 중 JSON-LD를 권하는 이유 최소 문법 네 가지면 읽고 쓴다 구조화 데이터를 넣으면 AI가 더 인용해줄까 검증에서 반복해서 걸리는 세 지점 자주 묻는 질문

JSON-LD란 무엇인가 썸네일. JSON-LD는 구조화 데이터를 JSON 문법으로 적는 W3C 표준 포맷이며 2020년 7월 16일 1.1 권고안이 나왔다. 구글은 세 지원 포맷 중 JSON-LD를 권장한다. 서치폴라리스 2026.07

한줄 요약: JSON-LD는 구조화 데이터를 JSON 문법으로 적어 페이지에 심는 표준 포맷입니다. schema.org가 어휘라면 JSON-LD는 그 어휘를 적는 문법이에요. 구글은 세 가지 지원 포맷 중 JSON-LD를 권장합니다.

JSON-LD(JavaScript Object Notation for Linked Data)는 연결 데이터를 JSON 문법으로 표현하는 표준 포맷입니다. 웹페이지에서는 application/ld+json 타입의 스크립트 태그 안에 검색엔진이 읽을 정보를 적는 용도로 쓰여요.

두 가지만 정리하면 헷갈릴 일이 없습니다. JSON-LD는 문법이고 schema.org는 어휘라서 층이 다르고, 구글은 지원하는 세 포맷 중 JSON-LD를 권장하지만 구조화 데이터 자체를 필수로 요구하지는 않습니다.

서치폴라리스가 W3C 표준 문서와 구글 검색 센트럴 문서를 직접 확인해 정리했습니다.

이 글에서 다루는 내용 - 자주 섞이는 세 단어의 층위 구분 - 구글이 JSON-LD를 권하는 이유 - 최소 문법 네 가지와 실제 코드 - 구조화 데이터가 AI 인용을 늘려주지 않는 이유 - 검증에서 반복해서 걸리는 지점

구조화 데이터, schema.org, JSON-LD는 층이 다르다

세 단어가 한 문장에 같이 등장하는 탓에 같은 말의 다른 이름처럼 읽힙니다. 셋은 서로 다른 층이에요.

구조화 데이터와 schema.org, JSON-LD의 4단계 층위 흐름도. 구조화 데이터는 기계가 읽을 정보를 페이지에 심는다는 개념이고, schema.org는 Article이나 FAQPage처럼 무엇을 부를지 정한 어휘 사전이며, JSON-LD는 그 어휘를 JSON 문법으로 적는 표기 방식이고, 마지막으로 검색엔진이 이 표기를 읽어 리치 결과를 만든다. 층을 구분하면 검증 오류가 문법 문제인지 어휘 문제인지 특정할 수 있다. 서치폴라리스 2026.07

구조화 데이터는 개념입니다. 사람이 읽는 본문과 별도로 기계가 읽을 정보를 페이지에 심는다는 발상 자체예요. 목적을 가리키는 말이지 형식이 아닙니다.

schema.org는 어휘입니다. 무엇을 무엇이라고 부를지 정해둔 사전이에요. Article, FAQPage, Organization 같은 타입 이름과 headline, datePublished 같은 속성 이름이 여기서 나옵니다.

JSON-LD는 문법입니다. 그 어휘를 어떤 표기로 적을지 정한 규칙이에요. JSON-LD 1.1은 W3C 권고안으로 2020년 7월 16일 발행됐고, 문서는 스스로를 연결 데이터를 직렬화하는 JSON 기반 포맷이라고 정의합니다.

층을 구분하면 문제 해결이 빨라집니다.

검증 도구에서 오류가 났을 때 원인이 두 갈래로 갈리거든요. 괄호나 쉼표가 깨졌으면 JSON-LD 층 문제고, 타입 이름이나 속성 이름이 틀렸으면 schema.org 층 문제입니다. 층을 안 나누면 두 오류를 같은 방식으로 고치려다 시간을 씁니다.

어휘 쪽을 더 보려면 스키마 마크업 뜻과 종류, 개념 쪽은 구조화 데이터란에 정리해뒀어요.

구글이 세 포맷 중 JSON-LD를 권하는 이유

같은 정보를 적는 방법이 하나가 아닙니다. 구글은 세 가지를 지원해요.

구글 구조화 데이터 소개 문서는 JSON-LD, 마이크로데이터(Microdata), RDFa 셋을 지원한다고 밝히면서, 사이트 구성이 허용한다면 JSON-LD 사용을 권장한다고 적었습니다. 이유도 함께 적혀 있어요. 대규모로 구현하고 유지하기에 가장 쉬운 방법이라는 겁니다.

핵심은 분리입니다.

포맷	적는 위치	본문과의 관계	구글 권장
JSON-LD	`<script>` 블록 한 곳	본문과 분리됨	권장
Microdata	HTML 태그 속성에 분산	본문 마크업에 섞임	지원
RDFa	HTML 태그 속성에 분산	본문 마크업에 섞임	지원

마이크로데이터와 RDFa는 본문 태그마다 속성을 붙입니다. 디자인을 고치다가 마크업이 깨지는 일이 생겨요. JSON-LD는 스크립트 블록 하나에 모여 있어서 본문을 건드려도 영향을 받지 않습니다.

같은 문서는 JSON-LD를 head와 body 어느 쪽 스크립트 태그에도 넣을 수 있고, 자바스크립트나 위젯으로 동적으로 삽입한 JSON-LD도 구글이 읽을 수 있다고 밝혔습니다. CMS 플러그인이 대부분 JSON-LD를 쓰는 이유가 여기 있어요.

한 가지 주의할 점이 있습니다.

구글은 대부분의 검색 구조화 데이터가 schema.org 어휘를 쓰지만, 구글 검색의 동작에 대해서는 schema.org 문서가 아니라 구글 검색 센트럴 문서를 정본으로 삼으라고 명시했습니다. schema.org에 존재하는 속성이라고 해서 구글이 전부 쓰는 것은 아니라는 뜻이에요.

우리는 새 타입을 넣기 전에 구글 문서에 해당 기능 페이지가 있는지부터 확인하는 쪽을 선택합니다. 문서에 없는 타입은 검증은 통과해도 검색 결과에서 아무 일도 일어나지 않으니까요.

최소 문법 네 가지면 읽고 쓴다

JSON-LD 문법을 전부 외울 필요는 없습니다. 실무에서 반복해서 쓰는 키는 네 개예요.

@context가 어휘의 출처를 지정합니다. 거의 항상 https://schema.org가 들어가요. 이 줄이 없으면 뒤에 나오는 Article이 무엇을 뜻하는지 기계가 알 수 없습니다.

@type이 이 데이터가 무엇인지 선언합니다. Article, FAQPage, Organization 같은 값이 들어가요. 배열로 적으면 한 블록이 두 타입을 겸할 수 있습니다.

@id가 이 대상의 고유 식별자입니다. URL 형태로 적어요. 여러 블록이 같은 대상을 가리킬 때 @id로 묶습니다.

@graph가 여러 개체를 한 블록에 담습니다. 글 하나에 Article, BreadcrumbList, Organization을 함께 적을 때 쓰는 키예요.

JSON-LD 필수 키 네 가지 카드. @context는 어휘 출처를 지정하며 값은 https://schema.org이고 없으면 타입 해석이 안 된다. @type은 Article이나 FAQPage처럼 데이터 종류를 선언하고 배열로 겸용할 수 있다. @id는 URL 형태의 고유 식별자로 블록 간 참조와 중복 정의 방지에 쓰인다. @graph는 Article과 BreadcrumbList 같은 여러 개체를 한 블록에 묶는다. 서치폴라리스 2026.07

실제로 적으면 이렇게 됩니다.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "JSON-LD란? 구조화 데이터 포맷 완벽 가이드",
  "datePublished": "2026-07-24",
  "author": {
    "@type": "Organization",
    "name": "서치폴라리스",
    "url": "https://searchpolaris.com"
  }
}

author 자리에 객체가 통째로 들어간 부분이 JSON-LD의 성격을 잘 보여줍니다. 값이 문자열이 아니라 또 하나의 개체예요. 사람 이름을 적는 대신 그 사람이 무엇인지를 함께 적는 구조입니다.

여러 개체를 묶을 때는 @graph를 씁니다.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Article",
      "@id": "https://searchpolaris.com/blog/json-ld/#article",
      "headline": "JSON-LD란? 구조화 데이터 포맷 완벽 가이드",
      "publisher": {"@id": "https://searchpolaris.com#organization"}
    },
    {
      "@type": "Organization",
      "@id": "https://searchpolaris.com#organization",
      "name": "서치폴라리스",
      "url": "https://searchpolaris.com"
    }
  ]
}

두 번째 블록이 @id로 한 번만 정의되고, 첫 블록은 그 @id를 참조만 합니다. 같은 조직 정보를 페이지마다 반복해서 적지 않아도 되는 구조예요. 이름표를 한 번 붙여두고 계속 부르는 방식이라고 보면 됩니다.

구조화 데이터를 넣으면 AI가 더 인용해줄까

여기서 솔직하게 적을 부분이 있습니다. 많이 팔리는 이야기와 공식 문서가 어긋나요.

구글은 생성형 AI 기능 최적화 가이드에서 구조화 데이터가 생성형 AI 검색의 요건이 아니라고 밝혔습니다. 같은 문서는 AI를 위해 콘텐츠를 잘게 쪼개거나 별도 문체로 쓸 필요도 없다고 적었어요.

JSON-LD를 추가한다고 AI 답변 인용이 올라간다는 보장은 구글 쪽에서는 없습니다.

그럼에도 넣는 이유는 따로 있어요. 리치 결과 자격입니다. FAQ, 이벤트, 상품, 레시피 같은 검색 결과의 확장 표시는 구조화 데이터가 있어야 후보가 됩니다. 이건 AI 이야기가 아니라 기존 검색 이야기예요.

두 목적을 섞지 않는 편이 낫습니다. 리치 결과를 노리는 작업과 AI 인용을 노리는 작업은 근거가 다르니까요. AI 인용 쪽에서 실제로 작동하는 요건은 AEO vs SEO 차이에서 색인과 스니펫 자격 중심으로 정리했어요.

아직 확실하지 않은 부분도 있습니다. 챗GPT나 퍼플렉시티가 구조화 데이터를 파싱해 가중치로 쓰는지는 각 사가 공개하지 않았어요. 구글 진술을 다른 엔진에 그대로 옮기면 안 되는 이유입니다.

검증에서 반복해서 걸리는 세 지점

문법이 맞아도 반려되는 경우가 있습니다. 규칙이 문법 바깥에 있어서 그래요.

본문에 없는 정보를 마크업하면 걸립니다. 구글은 구조화 데이터만 담기 위한 빈 페이지를 만들지 말고, 사용자에게 보이지 않는 정보에 대한 구조화 데이터를 추가하지 말라고 명시했어요. 별점 4.9를 JSON-LD에만 적고 페이지에는 안 보이게 두는 방식이 대표적인 위반입니다.

타입 이름의 대소문자도 자주 틀립니다. schema.org 타입은 FAQPage처럼 대문자로 시작하고, 속성은 datePublished처럼 소문자로 시작해요. Faqpage나 DatePublished로 적으면 인식되지 않습니다.

날짜 형식은 ISO 8601을 씁니다. 2026-07-24 형태예요. 2026년 7월 24일이나 07/24/2026은 통과하지 못합니다.

배포 전 확인은 구글 리치 결과 테스트로 하고, 배포 후에는 서치 콘솔의 리치 결과 상태 리포트를 봅니다. 앞쪽은 문법 검사이고 뒤쪽은 실제 색인된 페이지 기준이라 성격이 달라요. 둘 중 하나만 보면 반쪽입니다.

크롤러가 페이지에 접근하지 못하면 이 모든 검사가 무의미해집니다. 접근 정책 쪽은 AI 크롤러 robots.txt 설정법에서 토큰 단위로 다뤘어요.

이런 경우엔 JSON-LD 작업을 뒤로 미루세요.

색인 자체가 안 되는 사이트라면 순서가 다릅니다. 크롤링과 색인이 막힌 상태에서 마크업을 다듬어봐야 읽어갈 주체가 없어요. 리치 결과 대상 기능이 하나도 없는 페이지도 우선순위가 낮습니다. 구글이 문서로 지원하는 기능이 없는 유형에 JSON-LD를 붙이면 검증은 통과하지만 검색 결과는 그대로입니다.

JSON-LD를 어렵게 만드는 건 문법이 아닙니다. 키가 네 개뿐이고 나머지는 JSON이에요.

어려운 쪽은 층 구분입니다. 문법에서 막힌 건지, 어휘를 잘못 고른 건지, 애초에 구글이 지원하지 않는 기능을 기대한 건지를 나누는 일이요. 세 질문의 답이 다르면 고칠 곳도 다릅니다.

다음 질문이 이어집니다. 우리 페이지의 JSON-LD가 구글 문서에 기능 페이지가 있는 타입을 쓰고 있는가, 마크업한 정보가 본문에도 보이는가, 서치 콘솔 리치 결과 리포트에 오류가 몇 건인가. 세 답이 없으면 마크업은 넣어둔 상태일 뿐입니다.

자주 묻는 질문

JSON-LD와 schema.org는 무엇이 다른가요?

층이 다릅니다. schema.org는 Article이나 FAQPage처럼 무엇을 무엇이라고 부를지 정해둔 어휘 사전이고, JSON-LD는 그 어휘를 JSON 문법으로 적는 표기 방식입니다. 같은 schema.org 어휘를 마이크로데이터나 RDFa 문법으로 적을 수도 있습니다. 검증 오류가 났을 때 괄호나 쉼표 문제면 JSON-LD 층이고, 타입이나 속성 이름 문제면 schema.org 층입니다.

구글은 어떤 구조화 데이터 포맷을 권장하나요?

JSON-LD입니다. 구글은 JSON-LD, 마이크로데이터, RDFa 세 포맷을 지원하지만 사이트 구성이 허용한다면 JSON-LD 사용을 권장하며, 대규모로 구현하고 유지하기에 가장 쉬운 방법이기 때문이라고 밝혔습니다. JSON-LD는 스크립트 블록 한 곳에 모여 있어 본문 HTML을 수정해도 마크업이 깨지지 않습니다.

JSON-LD는 head에 넣어야 하나요, body에 넣어야 하나요?

어느 쪽이든 됩니다. 구글은 JSON-LD를 head와 body 중 어느 위치의 script 태그에 넣어도 읽는다고 밝혔습니다. 자바스크립트 코드나 위젯으로 동적으로 삽입한 JSON-LD도 구글이 읽을 수 있습니다.

JSON-LD를 넣으면 AI 검색에 더 인용되나요?

구글 기준으로는 보장되지 않습니다. 구글은 생성형 AI 기능 최적화 가이드에서 구조화 데이터가 생성형 AI 검색의 요건이 아니라고 밝혔습니다. JSON-LD를 넣는 실질적인 이유는 FAQ나 상품, 이벤트 같은 리치 결과 자격을 확보하기 위한 것입니다. 챗GPT나 퍼플렉시티가 구조화 데이터를 어떻게 처리하는지는 각 사가 공개하지 않았으므로 구글 진술을 다른 엔진에 그대로 적용할 수는 없습니다.

JSON-LD 검증은 어떻게 하나요?

배포 전에는 구글 리치 결과 테스트로 문법과 자격을 확인하고, 배포 후에는 서치 콘솔의 리치 결과 상태 리포트로 실제 색인된 페이지의 오류를 확인합니다. 앞쪽은 개별 코드 검사이고 뒤쪽은 사이트 전체 기준이라 성격이 다르므로 둘 다 봐야 합니다.

JSON-LD는 언제 만들어진 표준인가요?

JSON-LD 1.1은 2020년 7월 16일 W3C 권고안으로 발행됐습니다. 문서는 JSON-LD를 연결 데이터를 직렬화하는 JSON 기반 포맷으로 정의하며, 이미 JSON을 사용하는 시스템에 쉽게 통합되도록 설계돼 JSON에서 JSON-LD로의 전환 경로가 매끄럽다고 밝히고 있습니다.