용어집
SEO

스키마 마크업

스키마 마크업은 schema.org 어휘를 사용해 페이지 콘텐츠의 의미(작성자, 평점, 가격, 이벤트 등)를 검색엔진이 이해할 수 있도록 명시하는 표준 구조화 데이터입니다. 구글은 이 마크업을 읽어 별점, FAQ, 브레드크럼 같은 리치 결과를 표시하며, JSON-LD·Microdata·RDFa를 모두 지원하지만 구현과 유지보수가 가장 쉬운 JSON-LD를 권장합니다.

  • 스키마 마크업은 schema.org 어휘를 사용해 페이지의 의미를 검색엔진에 명시하는 표준 구조화 데이터입니다.
  • 마크업이 적용되면 구글은 별점, FAQ, 브레드크럼 같은 리치 결과를 노출할 수 있어 노출도와 클릭률이 향상됩니다.
  • JSON-LD, Microdata, RDFa가 모두 지원되지만 구글은 구현과 유지보수가 가장 쉬운 JSON-LD를 권장합니다.
  • 특정 유형의 향상된 표시(리치 결과)에 노출되려면 해당 유형의 필수 속성을 빠짐없이 채워야 합니다.
  • 마크업 값은 실제로 페이지에 보이는 내용과 일치해야 하며, 게시 전 리치 결과 테스트로 검증하는 것이 좋습니다.
구글 검색의 레시피 리치 결과
구글 검색의 레시피 리치 결과. 별점·이미지·조리시간은 각 페이지의 Recipe 스키마 마크업에서 끌어온 것으로, 구조화 데이터가 만드는 시각적 결과물입니다.

스키마 마크업이란

스키마 마크업은 "이 텍스트가 실제로 무엇을 의미하는지"를 검색엔진에 명시적으로 알려주기 위해, 페이지에 구조화 데이터를 심는 표준 방식입니다. 구글의 설명을 빌리면, 레시피 페이지에서 어떤 값이 재료이고 조리 시간이며 온도이고 칼로리인지를 표시해 주는 것과 같습니다. 사람 눈에는 어느 쪽이든 동일한 글자로 보이지만, 검색엔진은 "아바타(Avatar)"가 영화를 가리키는지 프로필 사진을 가리키는지 구분하기 어렵기 때문에, schema.org 어휘를 사용해 콘텐츠에 의미를 부여하는 것입니다.

스키마 마크업이 적용되면 구글은 이를 리치 스니펫(리치 결과)의 근거로 활용합니다. 별점, 펼쳐지는 FAQ, 브레드크럼 내비게이션, 가격과 재고 상태, 이벤트 일정 같은 향상된 표시가 모두 그 예입니다. schema.org는 구글, 마이크로소프트(빙), 얀덱스, 야후가 공동으로 사용하는 공유 어휘이므로, 한 번만 구현해도 여러 검색엔진과 AI 답변 엔진이 동시에 참조할 수 있습니다.

JSON-LD 예시 (구글 권장 형식)

JSON-LD는 <script type="application/ld+json"> 블록 안에 데이터를 담습니다. 눈에 보이는 본문 콘텐츠와 뒤섞이지 않기 때문에 가장 다루기 쉬운 형식입니다. 아래는 Article 유형의 유효한 스니펫입니다. <head><body> 어디에 두어도 됩니다.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "The Complete Guide to Schema Markup",
  "image": "https://example.com/images/cover.jpg",
  "datePublished": "2026-01-05T08:00:00+09:00",
  "dateModified": "2026-02-05T09:20:00+09:00",
  "author": {
    "@type": "Person",
    "name": "Jane Doe",
    "url": "https://example.com/profile/jane"
  },
  "publisher": {
    "@type": "Organization",
    "name": "SearchOS",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  }
}
</script>

핵심은 세 가지입니다. @context는 어휘의 출처(https://schema.org)를 선언하고, @type은 객체의 종류(Article, Product, FAQPage 등)를 선언하며, 그 아래의 속성들은 해당 유형이 요구하거나 권장하는 필드입니다. 구글은 "향상된 표시에 노출되려면 모든 필수 속성을 포함해야 한다"고 명시하며, 권장 속성은 가능한 한 많이 추가하되 부정확한 값을 억지로 채워 넣기보다 개수가 적더라도 정확하고 완전한 값을 우선하라고 조언합니다.

JSON-LD vs Microdata vs RDFa

구글은 세 형식을 (유효하게 구현되기만 하면) 동등하게 지원하며, 대부분의 경우 JSON-LD를 권장합니다. 대규모로 구현하고 유지보수하기 가장 쉽고 오류가 가장 적기 때문입니다.

구분JSON-LD (권장)MicrodataRDFa
형태<script> 블록 안에 JSON으로 분리HTML 태그 속성으로 인라인 삽입HTML 태그 속성으로 인라인 삽입
본문과의 관계본문과 뒤섞이지 않음 (독립 블록)눈에 보이는 마크업에 직접 부착눈에 보이는 콘텐츠에 직접 부착
표준 출처자바스크립트 표기법 (W3C 권고안)오픈 커뮤니티 HTML 명세HTML5 확장
주요 위치<head>/<body>주로 <body> (head도 가능)<head><body> 모두
동적 삽입JS로 삽입해도 구글이 읽음정적 마크업 기반정적 마크업 기반
유지보수쉬움 (데이터가 한곳에 통합됨)보통 (중첩이 깊어질수록 복잡)보통

동일한 데이터를 두 형식으로 표현해 보면 차이가 분명해집니다. 아래는 같은 BreadcrumbList를 JSON-LD와 Microdata로 각각 나타낸 것입니다.

JSON-LD

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Blog", "item": "https://example.com/blog" },
    { "@type": "ListItem", "position": 2, "name": "SEO", "item": "https://example.com/blog/seo" },
    { "@type": "ListItem", "position": 3, "name": "Schema Markup" }
  ]
}
</script>

Microdata

<ol itemscope itemtype="https://schema.org/BreadcrumbList">
  <li itemprop="itemListElement" itemscope itemtype="https://schema.org/ListItem">
    <a itemprop="item" href="https://example.com/blog">
      <span itemprop="name">Blog</span></a>
    <meta itemprop="position" content="1" />
  </li>
  <li itemprop="itemListElement" itemscope itemtype="https://schema.org/ListItem">
    <a itemprop="item" href="https://example.com/blog/seo">
      <span itemprop="name">SEO</span></a>
    <meta itemprop="position" content="2" />
  </li>
</ol>

Microdata는 itemscope, itemtype, itemprop 속성을 눈에 보이는 마크업 곳곳에 흩뿌려야 하므로, 중첩이 깊어질수록 관리가 번거로워집니다. JSON-LD는 데이터가 단일 블록에 모여 있어 템플릿화와 검증이 쉽습니다.

실제 효과 (구글 사례 연구)

구글 검색 센터(Google Search Central)가 공개한 도입 사례 연구는 다음과 같습니다 (출처: 구글의 구조화 데이터 소개 문서).

  • Rotten Tomatoes: 10만 개 페이지에 구조화 데이터를 적용해, 적용하지 않은 페이지 대비 클릭률(CTR) 25% 상승을 기록했습니다.
  • Food Network: 전체 페이지의 80%를 검색 기능 지원으로 전환해 방문 35% 증가를 달성했습니다.
  • Rakuten: 구조화 데이터가 적용된 페이지에서 사용자의 페이지 체류 시간이 1.5배 길었고, 상호작용 비율은 3.6배 높았습니다(AMP 기준).
  • Nestlé: 리치 결과로 노출된 페이지가 리치 결과가 아닌 페이지보다 CTR이 82% 높았습니다.

다만 리치 결과가 보장되는 것은 아닙니다. 구글은 마크업이 유효하더라도 표시 여부는 알고리즘이 결정한다고 명시합니다. 또한 구글은 두 가지 지침을 못 박습니다. 사용자에게 보이지 않는 정보를 마크업하지 말 것, 그리고 마크업만을 위해 빈 페이지를 만들지 말 것입니다.

구현 체크리스트

  • 가능하면 JSON-LD로 작성합니다(구글 권장, 유지보수 용이).
  • 유형은 schema.org에서 고르되, 구글 검색 센터 문서를 1차 기준으로 삼습니다(구글이 요구하는 필수·권장 속성은 schema.org와 다를 수 있습니다).
  • 필수 속성을 빠짐없이 채웁니다. 하나라도 누락되면 해당 페이지는 향상된 표시에서 제외됩니다.
  • 마크업 값을 페이지에 실제로 보이는 내용과 일치시킵니다(불일치 마크업이나 숨김 마크업 금지).
  • 게시 전 리치 결과 테스트로 검증하고, 게시 후에는 서치 콘솔의 리치 결과 보고서로 모니터링합니다.
  • data-vocabulary.org 마크업은 더 이상 리치 결과 대상이 아니므로 schema.org로 이전합니다.

참고·출처