JSON-LD란? 검색엔진에게 웹페이지 내용을 설명하는 구조화 데이터

AI에게 SEO를 적용해달라고 했더니 페이지 코드에 처음 보는 내용이 생겼습니다.

<script type="application/ld+json">
  { "@context": "https://schema.org", "@type": "Article" }
</script>

화면에는 아무것도 달라진 것 같지 않은데 JSON-LD, schema.org, Article 같은 단어가 들어 있어요. 이 코드는 왜 추가된 걸까요?

JSON-LD는 웹페이지에 무엇이 들어 있는지 검색엔진 같은 기계가 이해하기 쉬운 형태로 설명하는 구조화 데이터 작성 방식입니다. 사람에게 보여주는 본문을 대신하는 것이 아니라, 이미 페이지에 있는 내용을 정해진 항목으로 한 번 더 설명해주는 역할을 해요.

이 글에서는 JSON-LD가 무엇인지부터 Schema.org, 구조화 데이터, 리치 결과(Rich Results)가 어떻게 연결되는지, AI가 추가한 코드에서 무엇을 확인해야 하는지까지 살펴봅니다.

사람은 문맥을 읽지만 기계에는 명확한 표지가 도움이 돼요

블로그 글에는 제목, 작성자, 발행일과 본문이 있습니다. 상품 페이지에는 상품명, 가격, 재고 상태와 후기 점수가 있을 수 있어요.

사람은 화면의 배치와 문장을 보고 각 정보의 역할을 대략 알아챕니다. 하지만 같은 숫자라도 페이지에 따라 뜻이 달라질 수 있습니다.

29,000원  → 상품 가격일 수 있어요.
2026.08.04 → 글 발행일이나 행사 날짜일 수 있어요.
4.8       → 후기 평점이나 제품 버전일 수 있어요.

구조화 데이터는 이런 값에 이름표를 붙입니다.

이 페이지는 블로그 글입니다.
제목은 "JSON-LD란?"입니다.
작성자는 임재후입니다.
발행일은 2026년 8월 4일입니다.

Google은 구조화 데이터를 페이지의 의미를 파악하기 위한 명시적인 단서로 사용하며, 조건을 충족하면 검색 결과를 더 풍부한 형태로 보여줄 수도 있다고 설명합니다. Google의 구조화 데이터 소개 (새 탭에서 열림)

본문을 읽지 않아도 된다는 뜻은 아닙니다. 검색엔진은 여전히 페이지의 제목, 본문, 링크와 여러 신호를 함께 확인해요. 구조화 데이터는 본문에 없는 정보를 몰래 추가하는 곳이 아니라, 본문에 있는 정보의 역할과 관계를 더 분명하게 알려주는 곳입니다.

JSON-LD, 구조화 데이터, Schema.org는 서로 다른 말이에요

세 단어가 함께 등장해서 같은 뜻처럼 보이지만 역할이 다릅니다.

예를 들어 블로그 글을 설명할 때 Schema.org의 BlogPosting이라는 종류를 선택하고, headline, author, datePublished 같은 항목을 사용합니다. 그 내용을 JSON-LD 문법으로 작성해 페이지에 넣는 거예요.

JSON-LD는 JavaScript Object Notation for Linked Data의 약자입니다. JSON을 바탕으로 대상과 속성, 대상 사이의 관계를 표현하는 형식이에요. JSON-LD 공식 명세도 이를 Linked Data를 표현하기 위한 JSON 기반 형식으로 정의합니다. JSON-LD 공식 명세 (새 탭에서 열림)

Google 검색은 JSON-LD 외에도 Microdata와 RDFa 형식을 지원합니다. 다만 JSON-LD는 화면의 HTML 요소마다 속성을 섞어 넣지 않아도 되고, 별도의 스크립트 블록에서 중첩된 관계를 표현하기 쉬워 Google이 일반적으로 권장하는 방식입니다.

블로그 글의 JSON-LD는 이렇게 생겼어요

JSON-LD는 보통 HTML의 head나 body 안에 다음처럼 들어갑니다.

<script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "BlogPosting",
    "headline": "JSON-LD란?",
    "description": "JSON-LD와 구조화 데이터의 역할을 설명합니다.",
    "datePublished": "2026-08-04T12:00:00+09:00",
    "dateModified": "2026-08-04T12:00:00+09:00",
    "author": {
      "@type": "Person",
      "name": "홍길동",
      "url": "https://example.com/authors/gildong"
    },
    "mainEntityOfPage": {
      "@type": "WebPage",
      "@id": "https://example.com/blog/what-is-json-ld"
    }
  }
</script>

화면에 그대로 출력하기 위한 JavaScript는 아닙니다. type="application/ld+json"은 이 스크립트 안의 내용을 JSON-LD 데이터로 해석하라는 표시예요.

각 항목은 다음 역할을 합니다.

• @context는 항목 이름을 어느 어휘 체계로 해석할지 알려줍니다.
• @type은 설명할 대상의 종류를 지정합니다.
• headline과 description은 글의 제목과 설명입니다.
• datePublished와 dateModified는 발행일과 실제 수정일입니다.
• author는 작성자를 또 하나의 대상으로 표현합니다.
• mainEntityOfPage는 이 글을 대표하는 페이지 주소를 연결합니다.

모든 페이지에 이 예제를 그대로 복사하면 되는 것은 아닙니다. 상품 페이지라면 Product, 행사 페이지라면 Event처럼 페이지의 실제 주제에 맞는 종류와 항목을 선택해야 해요. 블로그 글에 필요한 권장 항목도 Google의 Article 구조화 데이터 안내 (새 탭에서 열림)에서 확인하는 것이 가장 정확합니다.

메타 태그와 JSON-LD는 역할이 달라요

SEO 작업을 맡기면 제목과 설명을 담은 메타 태그도 함께 보게 됩니다.

<title>JSON-LD란? | 뚝딱 블로그</title> <meta name="description" content="JSON-LD의 역할을 쉽게 설명합니다." />

메타 태그와 JSON-LD는 일부 정보가 겹치지만 서로 대체하지 않습니다.

메타 태그
페이지의 제목과 요약, 검색·공유에 필요한 기본 정보를 제공해요.

JSON-LD
이 페이지가 글인지 상품인지, 누가 작성했는지,
가격이나 날짜 같은 값이 어떤 의미인지 관계까지 설명해요.

JSON-LD를 추가했다고 제목, 설명, 본문과 내부 링크를 생략할 수 없어요. 반대로 메타 태그를 잘 작성했다고 상품 가격이나 행사 일정의 의미까지 구조적으로 전달되는 것도 아닙니다.

SEO의 발견·수집·색인 과정에서 보면 JSON-LD는 검색엔진이 페이지를 읽고 이해하는 일을 돕는 여러 단서 중 하나입니다.

JSON-LD가 있으면 검색 결과가 더 풍부해질 수 있어요

일반적인 검색 결과에는 제목, 주소와 설명이 나타납니다. 구조화 데이터의 종류와 내용이 Google의 요구사항을 충족하면 이미지, 가격, 재고, 평점, 행사 날짜나 이동 경로 같은 정보가 더해진 리치 결과의 대상이 될 수 있어요.

페이지에 따라 다음과 같은 구조화 데이터를 고려할 수 있습니다.

하지만 Schema.org에 존재하는 모든 종류가 Google의 특별한 검색 화면으로 이어지는 것은 아닙니다. Schema.org는 훨씬 넓은 어휘를 제공하고, Google은 그중 일부 기능을 별도 요구사항과 함께 지원해요. 검색 결과에 어떤 기능이 현재 지원되는지는 Google의 구조화 데이터 검색 갤러리 (새 탭에서 열림)에서 확인해야 합니다.

지원 범위는 바뀌기도 합니다. 예를 들어 FAQPage를 추가하면 누구나 검색 결과에 질문과 답변을 펼쳐 보일 수 있다는 예전 안내가 아직 인터넷에 남아 있지만, 현재 Google의 FAQ 리치 결과는 잘 알려진 정부·보건 사이트로 크게 제한되어 있습니다. FAQ와 How-to 리치 결과 변경 안내 (새 탭에서 열림)

따라서 AI에게 “SEO에 좋은 스키마를 전부 넣어줘”라고 하기보다 현재 Google이 지원하는 기능과 이 페이지의 실제 내용에 맞는 종류만 선택하게 하는 것이 중요합니다.

JSON-LD는 검색 순위를 올리는 보장 장치가 아니에요

구조화 데이터를 올바르게 추가하면 검색엔진의 이해를 돕고 리치 결과의 대상이 될 수 있습니다. 그렇다고 다음 결과가 보장되지는 않아요.

• 검색 결과에 반드시 리치 결과가 표시된다.
• 특정 검색어의 순위가 바로 오른다.
• 새 페이지가 즉시 수집되거나 색인된다.
• 내용이 부족한 페이지가 좋은 콘텐츠로 평가된다.

Google은 Rich Results Test를 통과한 구조화 데이터도 실제 검색 결과에 표시된다고 보장하지 않는다고 명시합니다. 검색어, 기기, 위치, 페이지의 품질과 여러 조건에 따라 일반 검색 결과가 더 적절하다고 판단할 수도 있어요. Google의 구조화 데이터 일반 가이드 (새 탭에서 열림)

JSON-LD는 검색엔진에게 거짓말해서 점수를 얻는 요령이 아닙니다. 이미 좋은 페이지가 무엇에 관한 것인지 더 정확하게 전달하는 표지에 가까워요.

AI 검색에서도 별도의 구조화 데이터가 노출을 보장하지 않습니다. 기존 JSON-LD를 정확하게 유지하면서 실제 본문에 분명한 답과 근거를 제공해야 하는 이유는 AI 검색 시대의 SEO·AEO·GEO에서 이어서 확인할 수 있습니다.

화면의 내용과 JSON-LD가 반드시 일치해야 해요

상품 화면에는 39,000원이라고 적혀 있는데 JSON-LD에는 29,000원이라고 남아 있으면 어떤 정보가 맞는지 알 수 없습니다. 종료된 행사를 아직 신청 가능한 상태로 표시하거나, 화면에 없는 후기를 만들어 평점을 넣는 것도 잘못된 사용입니다.

Google의 일반 가이드는 독자에게 보이지 않는 내용을 구조화 데이터로 표시하지 말고, 페이지의 중심 내용과 관련 있으며 최신인 정보를 제공하라고 안내합니다.

특히 다음 실수가 자주 생깁니다.

• 모든 페이지에 똑같은 Organization이나 Article 데이터만 복사합니다.
• 상품 가격과 재고가 바뀌어도 JSON-LD는 예전 값을 유지합니다.
• 실제 사용자가 남긴 후기가 없는데 별점과 후기 수를 만듭니다.
• 글을 수정하지 않았는데 배포할 때마다 dateModified를 현재 시각으로 바꿉니다.
• 화면에 없는 질문과 답을 FAQPage에만 넣습니다.
• 로그인해야 볼 수 있거나 noindex인 페이지에서 리치 결과를 기대합니다.
• Schema.org 검사만 통과하면 Google의 요구사항도 모두 충족했다고 생각합니다.

페이지 데이터에서 화면과 JSON-LD를 함께 만들면 값이 어긋날 가능성을 줄일 수 있어요. 예를 들어 상품 이름과 가격을 데이터베이스에서 가져온다면, 화면과 Product JSON-LD가 같은 값을 사용하도록 구성합니다.

Next.js에서는 페이지 데이터로 JSON-LD를 만들 수 있어요

Next.js 공식 가이드는 layout이나 page 컴포넌트에서 JSON-LD 객체를 만들고 script 태그로 렌더링하는 방식을 안내합니다. Next.js의 JSON-LD 가이드 (새 탭에서 열림)

export default async function BlogPage() {
  const post = await getPost();

  const jsonLd = {
    "@context": "https://schema.org",
    "@type": "BlogPosting",
    headline: post.title,
    description: post.description,
    datePublished: post.publishedAt,
    dateModified: post.updatedAt ?? post.publishedAt,
    author: {
      "@type": "Person",
      name: post.author.name,
      url: post.author.url,
    },
  };

  return (
    <>
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{
          __html: JSON.stringify(jsonLd).replace(/</g, "\\u003c"),
        }}
      />
      <article>{/* 독자에게 보이는 글 */}</article>
    </>
  );
}

여기서 post.title, post.publishedAt처럼 실제 글 데이터로 JSON-LD를 만들면 글마다 다른 정보가 자동으로 들어갑니다.

JSON.stringify() 결과를 그대로 HTML에 넣을 때는 외부 입력에 포함된 문자가 스크립트 문맥을 깨지 않도록 안전하게 처리해야 합니다. 위 예제의 < 치환은 Next.js 공식 문서가 안내하는 기본 방어예요. 사용자나 외부 서비스가 제공한 값을 포함한다면 프로젝트의 신뢰 경계를 확인하고 더 엄격한 직렬화·검증 방식을 선택해야 합니다.

Next.js가 화면과 서버에서 어떤 역할을 맡는지 낯설다면 Next.js를 입문자 눈높이로 설명한 글을 먼저 읽어봐도 좋아요.

추가한 뒤에는 두 가지 검사 도구를 구분해서 사용하세요

코드가 화면에 보이지 않기 때문에 추가한 뒤 검증하는 과정이 중요합니다.

1. Google Rich Results Test

Google Rich Results Test (새 탭에서 열림)는 페이지가 Google이 지원하는 리치 결과의 대상이 될 수 있는지 검사합니다. 오류와 누락된 권장 항목을 확인하고, 지원되는 경우 검색 화면을 미리 볼 수 있어요.

2. Schema Markup Validator

Schema Markup Validator (새 탭에서 열림)는 Schema.org 어휘를 기준으로 구조와 항목 사용을 검사합니다. Google의 리치 결과 지원 여부와 관계없이 일반적인 Schema.org 데이터를 점검할 때 사용합니다.

두 검사는 질문이 다릅니다.

Schema Markup Validator
이 데이터가 Schema.org 어휘에 맞게 작성됐나요?

Google Rich Results Test
이 페이지가 Google이 지원하는 리치 결과 요구사항에 맞나요?

로컬 코드나 붙여 넣은 코드로 먼저 검사한 뒤, 실제 배포 주소로 다시 확인하세요. 배포 뒤에는 Search Console의 URL 검사에서 Google이 페이지에 접근할 수 있는지 보고, 지원되는 유형은 리치 결과 상태 보고서에서 오류 추이를 확인합니다.

SEO 기술 점검표를 함께 사용하면 JSON-LD만 통과하고 정작 noindex, canonical, 사이트맵이나 응답 상태가 잘못된 상황도 놓치지 않을 수 있어요.

AI에게 먼저 현재 상태를 점검하게 하세요

구조화 데이터는 페이지 종류와 실제 데이터에 따라 달라집니다. 무작정 새 코드를 추가하기 전에 현재 프로젝트에 무엇이 있는지 확인하게 하세요.

아직 코드를 수정하지 마.
이 프로젝트의 공개 페이지별 JSON-LD 구조화 데이터를 점검해줘.

각 페이지마다 다음 내용을 표로 정리해줘.
- 페이지 URL과 주된 목적
- 현재 사용 중인 @type
- 화면에 보이는 내용과 일치하는지
- Google이 현재 지원하는 리치 결과 유형인지
- 필수·권장 속성의 누락 여부
- 중복되거나 오래된 값이 있는지
- 확인에 사용한 공식 문서 링크

Schema.org에 존재한다는 이유만으로 추천하지 말고,
현재 Google Search 문서와 실제 페이지 내용을 기준으로 판단해줘.

점검 결과를 확인한 뒤 필요한 범위만 구현하게 합니다.

점검 결과에서 페이지의 실제 주제와 일치하는 구조화 데이터만 추가해줘.
화면과 JSON-LD가 같은 데이터 원본을 사용하게 하고,
사용자 입력이 script 태그를 깨지 않도록 안전하게 직렬화해줘.

구현 후에는 다음을 확인해줘.
- 생성된 HTML의 application/ld+json 내용
- JSON 문법과 Schema.org 유효성
- Google Rich Results Test 기준의 필수 항목
- 프로덕션 빌드와 기존 테스트

검색 순위나 리치 결과 노출이 보장된다고 표현하지 마.

AI가 작업을 마쳤다고 하면 코드 파일만 보지 말고, 실제 URL에서 글마다 제목·날짜·가격 같은 값이 올바르게 달라지는지도 확인하세요.

정리

• JSON-LD는 페이지 정보를 기계가 이해하기 쉬운 구조로 표현하는 방식입니다.
• 구조화 데이터는 작성된 정보, Schema.org는 항목 사전, JSON-LD는 작성 문법에 해당합니다.
• 페이지의 종류와 제목, 작성자, 가격, 날짜, 장소 같은 값의 의미와 관계를 설명할 수 있습니다.
• 올바른 구조화 데이터는 검색엔진의 이해를 돕고 리치 결과의 대상이 될 수 있지만, 검색 순위나 표시를 보장하지는 않습니다.
• JSON-LD의 내용은 독자에게 보이는 페이지 내용과 일치하고 최신 상태여야 합니다.
• Schema.org에 있는 모든 종류가 Google의 리치 결과로 지원되는 것은 아닙니다.
• 구현 전에는 유형별 공식 문서를 확인하고, 구현 후에는 Rich Results Test와 Schema Markup Validator를 목적에 맞게 사용해야 합니다.

JSON-LD를 복잡한 SEO 암호처럼 생각할 필요는 없어요. 사람에게 보여주는 페이지 내용을 검색엔진이 오해하지 않도록 정해진 항목으로 다시 써주는 설명표입니다.

중요한 것은 설명표를 많이 붙이는 일이 아니라, 페이지의 실제 내용을 정확하게 반영하는 설명표 하나를 유지하는 일입니다.