용어집
SEO

스키마 마크업

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

  • 스키마 마크업은 schema.org 어휘로 페이지의 의미를 검색엔진에 표시하는 표준 구조화 데이터입니다.
  • 마크업을 적용하면 구글이 별점, FAQ, 브레드크럼 같은 리치 결과를 노출하므로 노출도와 클릭률이 올라갑니다.
  • JSON-LD, Microdata, RDFa를 모두 지원하지만 구글은 구현과 유지보수가 가장 간단한 JSON-LD를 권장합니다.
  • 특정 유형의 리치 결과로 노출되려면 그 유형의 필수 속성을 빠짐없이 채워야 합니다.
  • 마크업 값은 페이지에 실제로 보이는 내용과 일치해야 하며, 게시 전 리치 결과 테스트로 검증하는 편이 좋습니다.
구글 검색의 레시피 리치 결과

레시피

titlesourceratingtime
촉촉하고 달콤한 초코칩쿠키 만들기만개의레시피5.0 ⭐⭐⭐⭐⭐ (3)30분
초코칩 쿠키우리의식탁리뷰 없음30분
촉촉하고 부드러운 초코칩쿠키만개의레시피5.0 ⭐⭐⭐⭐⭐ (180)30분

더보기

구글 검색의 레시피 리치 결과. 별점·이미지·조리시간은 각 페이지의 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로 옮깁니다.

참고·출처

관련 용어