JSON-LD 구조화된 데이터: 복사해 바로 테스트하는 예시 2개

SEOgrinder 편집팀 · 게시일 2026년 11월 4일 · 읽는 시간 약 13분

핵심 답변: JSON-LD는 <script type="application/ld+json"> 태그 안에 넣는 JSON 블록으로, 페이지를 검색엔진에 설명하며 Google이 구조화된 데이터에 권장하는 형식입니다. 아래 예시 두 개 중 하나를 복사해 example.com이 들어간 값을 내 페이지에서 눈에 보이는 사실로 바꾸고, 결과를 Google의 리치 결과 테스트(Rich Results Test)로 확인하세요. 유효한 코드는 페이지가 리치 결과의 대상이 될 자격을 갖추게 해 줄 뿐이며, 리치 결과가 실제로 나타나는 것은 Google이 보장하지 않습니다.

JSON-LD란 무엇이고, Google은 이것으로 무엇을 하나요?

Google은 구조화된 데이터를 “a standardized format for providing information about a page and classifying the page content”(Google), 곧 페이지에 대한 정보를 제공하고 페이지 내용을 분류하는 표준화된 형식이라고 설명합니다. 용어의 대부분은 schema.org에서 왔고, JSON-LD는 이를 적는 세 가지 방법 가운데 하나입니다. 나머지 둘인 Microdata와 RDFa는 눈에 보이는 HTML에 속성을 덧붙입니다. JSON-LD는 모든 내용을 별도의 블록 하나에 담으므로 레이아웃을 건드리지 않고 추가하거나 고칠 수 있습니다.

마크업이 유효하고 올바르게 구현되어 있기만 하면 세 형식 모두 똑같이 괜찮다고 Google은 말합니다. 그래도 환경이 허락한다면 JSON-LD를 권하는데, “the easiest solution for website owners to implement and maintain at scale”, 곧 웹사이트 운영자가 대규모로 구현하고 유지하기에 가장 쉬운 방법이기 때문입니다(Google).

얻을 수 있는 것은 이렇습니다. 구조화된 데이터는 “can enable search results that are more engaging to users”, 즉 사용자에게 더 매력적인 검색 결과를 가능하게 할 수 있다고 Google은 적고, 이것을 리치 결과라고 부릅니다. Google은 지원하는 기능의 갤러리를 운영하며, 거기에 Article, Breadcrumb, Event, Organization, Product, Recipe 등이 있습니다. Google의 소개 문서에서 하나 더 짚을 점이 있습니다. 검색의 동작은 schema.org가 아니라 Google의 자체 문서를 기준으로 삼으라는 것입니다. schema.org에는 Google 검색이 필요로 하는 것보다 많은 속성과 객체가 있습니다.

Google의 구조화된 데이터 일반 가이드라인에서 코드를 쓰기 전에 적용되는 규칙 세 가지는 다음과 같습니다.

마크업이 들어 있는 페이지를 설명하세요. 방문자가 그 페이지에서 볼 수 있는 내용만 설명하세요.
구조화된 데이터가 있는 페이지를 robots.txt, noindex 등으로 Googlebot이 못 보게 막지 마세요.
쓰는 유형의 필수 속성을 모두 채우세요. 하나라도 빠진 항목은 “are not eligible for rich results”, 곧 리치 결과의 대상이 아닙니다.

예시 1: 시작 페이지용 Organization 마크업

Organization 마크업은 홈페이지에 넣거나, 소개 페이지처럼 조직을 설명하는 페이지 하나에 넣으라고 Google은 권합니다. 모든 페이지에 필요하지는 않습니다(Google). 이 유형에는 필수 속성이 없으며, Google은 해당하는 권장 속성을 추가하라고 합니다. 모든 값을 바꾸세요.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "예시 자전거",
  "url": "https://www.example.com/",
  "logo": "https://www.example.com/images/logo.png",
  "description": "예시 자전거는 체형에 맞춘 맞춤 자전거를 만듭니다.",
  "email": "contact@example.com"
}
</script>

Google 문서에 따르면 각 속성은 다음과 같은 일을 합니다.

name: 사이트 이름으로 쓰는 것과 같은 이름을 쓰세요.
url: 웹사이트의 주소로, Google이 조직을 고유하게 식별하는 데 도움이 됩니다.
logo: 최소 112 × 112px이며, 크롤링과 색인이 가능해야 합니다. Google이 검색 결과와 지식 패널에 어떤 로고를 보여 줄지 정하는 데 도움이 될 수 있습니다.
description과 email: 선택 항목입니다. address, contactPoint, sameAs(다른 사이트의 프로필 페이지)는 해당할 때만 추가하세요.

더 구체적인 하위 유형이 맞다면 Google은 그것을 권합니다. 쇼핑몰이라면 OnlineStore, 음식점이라면 LocalBusiness의 하위 유형이 그 예입니다.

예시 2: 블로그 글의 Article과 이동 경로

한 페이지에 항목이 여럿이면 중첩하든 따로 나열하든 Google은 이해합니다(Google). 이 예시는 두 항목을 JSON 배열에 따로 나열하며 각각 자신의 @context를 가집니다. 개별 항목에 대해 Google이 보여 주는 방식입니다.

<script type="application/ld+json">
[
  {
    "@context": "https://schema.org",
    "@type": "BlogPosting",
    "headline": "자전거 헬멧 고르는 법",
    "image": [
      "https://www.example.com/photos/helmet-16x9.jpg",
      "https://www.example.com/photos/helmet-4x3.jpg",
      "https://www.example.com/photos/helmet-1x1.jpg"
    ],
    "datePublished": "2026-10-12T08:00:00+09:00",
    "dateModified": "2026-11-04T09:20:00+09:00",
    "author": [
      {
        "@type": "Person",
        "name": "홍길동",
        "url": "https://www.example.com/team/gildong-hong"
      }
    ]
  },
  {
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [
      { "@type": "ListItem", "position": 1, "name": "블로그", "item": "https://www.example.com/blog" },
      { "@type": "ListItem", "position": 2, "name": "자전거", "item": "https://www.example.com/blog/cycling" },
      { "@type": "ListItem", "position": 3, "name": "자전거 헬멧 고르는 법" }
    ]
  }
]
</script>

Article. Google은 Article, NewsArticle, BlogPosting을 받아들입니다. 필수 속성은 없고, Google이 “show better title text, images, and date information”, 곧 더 나은 제목 텍스트와 이미지, 날짜 정보를 보여 주도록 author, datePublished, dateModified, headline, image를 권합니다(Google). 날짜는 시간대를 포함한 ISO 8601 형식으로 쓰세요. 시간대가 없으면 Google은 Googlebot의 시간대를 씁니다. 저자는 유형, 이름, URL을 갖춘 항목으로 하나씩 따로 적으세요. 제목(headline)은 짧게 유지하세요. “long titles may be truncated on some devices”, 곧 긴 제목은 일부 기기에서 잘릴 수 있기 때문입니다. 이미지는 로고가 아니라 글과 관련된 고해상도 파일을 16x9, 4x3, 1x1 비율로 여러 장 쓰라고 Google은 권합니다.

이동 경로(breadcrumb). 여기서는 규칙이 엄격합니다. BreadcrumbList에는 ListItem 항목이 최소 두 개 필요하고, 각 항목에는 보통 position, name, item(주소)이 필요합니다. 마지막 항목만 item을 생략할 수 있으며, 그러면 Google은 그 페이지 자체의 주소를 씁니다(Google). Google은 URL 구조를 그대로 베끼기보다 사용자가 흔히 거치는 경로를 권하고, 이 기능이 데스크톱에서 제공된다고 밝힙니다. 가이드라인에 대한 우리의 해석은 이렇습니다. 같은 경로를 페이지에도 눈에 보이게 표시하세요. 독자가 볼 수 없는 것에 마크업을 붙이는 것은 허용되지 않기 때문입니다.

JSON-LD는 게시 전후에 어떻게 테스트하나요?

리치 결과 테스트(Rich Results Test)(search.google.com/test/rich-results). Google은 이것을 “the official Google tool for testing your structured data”, 곧 구조화된 데이터를 테스트하는 Google 공식 도구라고 부릅니다. 이 도구 페이지는 주소나 붙여 넣은 코드를 받으므로 게시하기 전에 예시를 테스트할 수 있습니다. 치명적인 오류부터 고치세요. 치명적이지 않은 힌트는 대상 자격에 필수가 아니라고 Google은 말합니다.
Schema Markup Validator(validator.schema.org). Google의 테스트 문서는 이것이 schema.org 기반의 모든 마크업을 “without Google feature specific warnings”, 곧 Google 기능에 특정한 경고 없이 점검한다고 설명합니다. 내 유형에 맞는 Google 기능이 없을 때 쓰세요.
Search Console의 URL 검사. 페이지 몇 개를 배포한 뒤에 쓰세요. 페이지가 robots.txt, noindex, 로그인으로 막혀 있지 않은지 확인하라고 Google은 요청하며, 새 페이지가 크롤링되기까지는 며칠이 걸릴 수 있습니다.
Search Console의 리치 결과 보고서. 배포한 뒤에 템플릿이나 서빙 문제로 마크업이 깨질 수 있다고 Google은 지적하므로, 템플릿을 바꿀 때마다 다시 확인하세요(Google).

위의 두 예시를 2026년 11월 4일에 어떻게 확인했는지 밝힙니다. 두 블록 모두 유효한 JSON으로 읽혔고(Python의 json 모듈), 속성은 Google의 Organization, Article, Breadcrumb 문서(마지막 업데이트 2026년 9월 8일)를 따릅니다. Google의 도구에는 붙여 넣어 보지 않았습니다. 그러니 처음 붙여 넣는 순간이 진짜 테스트입니다.

JSON-LD가 하지 않는 일

리치 결과를 보장하지 않습니다. Google은 이렇게 적습니다. “Google does not guarantee that your structured data will show up in search results”(Google). 이유로는 알고리즘이 일반 텍스트 결과가 더 낫다고 판단할 수 있다는 점, 테스트가 잡아내지 못하는 방식으로 마크업이 틀릴 수 있다는 점이 있습니다.
순위 약속이 아닙니다. 우리가 본 이 Google 문서들에서는 구조화된 데이터가 순위를 올린다는 말을 찾지 못했습니다. Google은 이점을 리치 결과의 대상 자격으로 설명합니다. 구조화된 데이터에 대한 수동 조치는 그 자격을 없앨 뿐 “doesn't affect how the page ranks in Google web search”, 곧 Google 웹 검색에서 페이지의 순위에는 영향을 주지 않는다고 Google은 덧붙입니다.
AI 답변에는 필요하지 않습니다. Google의 생성형 AI 기능 가이드는 이렇게 말합니다. “Structured data isn't required for generative AI search, and there's no special schema.org markup you need to add”(Google). 그래도 리치 결과의 대상 자격을 위해서는 구조화된 데이터가 좋은 방법이라고 Google은 말합니다. SEOgrinder는 어떤 AI 시스템이 내 사이트를 언급하는지는 측정하지 않습니다.
FAQ 마크업은 더 이상 Google 결과가 없습니다. Google의 변경 기록에는 이렇게 적혀 있습니다. “This feature will no longer appear in Google Search starting May 7, 2026”(Google). 그 목적으로 FAQPage 마크업을 추가하지 마세요.

흔한 실수: JSON-LD 오류 5가지

1. 아무도 볼 수 없는 것에 마크업 붙이기

Google의 가이드라인은 이렇습니다. “Don't mark up content that is not visible to readers of the page.” Google이 직접 든 예는 이렇습니다. 마크업이 공연자를 설명한다면 페이지 본문도 바로 그 공연자를 설명해야 합니다.

2. 깨진 JSON

문법 실수 하나가 블록 전체를 못 쓰게 만듭니다. Search Console의 해석할 수 없는 구조화된 데이터 보고서(영어 이름은 “Unparsable structured data report”)는 쉼표나 닫는 중괄호가 빠진 경우, 콜론이 빠진 경우, 문자열 안의 잘못된 이스케이프 시퀀스(예를 들어 텍스트 값 안에 \q처럼 혼자 들어간 백슬래시) 같은 오류 유형을 꼽습니다. 실수를 찾는 Google의 요령은 빈 객체에서 시작해 코드를 조금씩 다시 붙여 넣는 것입니다.

3. 필수 속성 누락

필수 속성이 빠진 항목은 리치 결과의 대상이 아니라고 Google은 말합니다. 가장 흔한 경우는 position, name, item이 없는 이동 경로 항목입니다.

4. 페이지와 맞지 않는 유형

Google은 해당하는 가장 구체적인 유형을 원합니다. 맞지 않는 마크업의 예로 Google이 든 것은 스포츠 스트리밍 사이트가 중계를 지역 행사로 표시한 경우, 목공 사이트가 작업 안내를 레시피로 표시한 경우입니다.

5. 페이지나 이미지를 막아 놓기

구조화된 데이터가 있는 페이지는 Googlebot에 열려 있어야 하고, 마크업에 적은 이미지 주소는 크롤링과 색인이 가능해야 합니다. 이미지 폴더에 걸린 Disallow 규칙이 공들인 마크업을 무용지물로 만들 수 있습니다.

SEOgrinder는 구조화된 데이터를 어떻게 점검하나요?

SEOgrinder는 우리의 도구이며, 우리가 만듭니다. 페이지를 스캔하고 「Google에서의 페이지」 탭을 열어 카드 두 개를 보세요. 「구조화된 데이터」는 JSON-LD와 Microdata에서 찾은 유형을 나열합니다. 「항목 점검」은 항목 수를 세고, 그중 몇 개가 「무효」(필수 항목이 빠짐)이거나 「미비」(권장 항목만 빠짐)인지 빠진 항목의 이름과 함께 보여 줍니다. 할 일에는 「구조화된 데이터에 필수 항목이 빠졌습니다」, 「구조화된 데이터가 불완전합니다」, 「구조화된 데이터가 없습니다」로 나타나고, 코드를 읽을 수 없을 때는 「구조화된 데이터 블록 N개가 깨져 있습니다」로 나타납니다. 고친 뒤에는 다시 확인을 누르세요.

한계는 네 가지입니다. SEOgrinder는 서버가 보내는 HTML을 읽습니다. 브라우저에서 스크립트가 뒤늦게 넣는 JSON-LD는 보지 못하지만 Google은 읽을 수 있습니다. JSON-LD와 Microdata를 읽고, RDFa는 읽지 않습니다. 흔한 유형 목록의 필수 항목은 알지만 모든 유형의 필수 항목을 아는 것은 아닙니다. 그리고 Google이 리치 결과를 보여 줄지는 판단하지 않습니다. 그 미리 보기는 리치 결과 테스트가 해 줍니다.

우리의 페이지도 2026년 11월 4일에 같은 방식으로 읽었습니다. 이 명령은 글에서는 1을, 시작 페이지에서는 0을 돌려줍니다.

curl -sS https://seogrinder.com/en/blog/seo-audit-checklist | grep -c 'application/ld+json'

글에 있는 블록은 하나이며, BlogPosting과 BreadcrumbList가 들어 있고 BreadcrumbList에는 항목이 세 개(SEOgrinder, Blog, 글)입니다. 시작 페이지에는 구조화된 데이터가 없습니다.

자주 묻는 질문

모든 페이지에 구조화된 데이터가 필요한가요?

아니요. 페이지에 맞는 유형이 있는 곳에만 추가하세요. 시작 페이지나 소개 페이지에는 Organization, 글에는 Article입니다. 맞는 유형이 없는 페이지도 많고, 그래도 괜찮습니다.

플러그인이나 JavaScript로 JSON-LD를 넣어도 되나요?

네. CMS에서는 구조화된 데이터를 위한 설정 페이지나 플러그인이 있을 수 있고, Google은 스크립트로 넣은 JSON-LD도 읽을 수 있다고 말합니다(Google). 결과는 리치 결과 테스트로 확인하고, SEOgrinder는 서버가 보내는 것만 본다는 점을 기억하세요.

JSON-LD가 순위를 올려 주나요?

Google 문서가 설명하는 것은 리치 결과의 대상 자격이지 더 나은 순위가 아닙니다. 순위는 누구도 약속할 수 없습니다.

다음 단계

가장 중요한 페이지를 하나 고르세요. 예시 1이나 2를 내 값으로 바꿔 리치 결과 테스트에 붙여 넣고, 표시되는 문제를 고칩니다. 게시한 다음 SEOgrinder로 그 페이지를 스캔하고 「Google에서의 페이지」 탭을 열어 「항목 점검」 카드를 읽으세요. 구조화된 데이터가 다른 점검 항목들 사이에서 어디쯤 있는지는 SEO 체크리스트에서 볼 수 있습니다.