스키마 마크업이란? 구조화 데이터부터 JSON-LD 적용·검증까지

스키마 마크업은 웹페이지에 있는 사람, 기업, 상품, 글 등의 정보가 무엇을 의미하는지 검색엔진이 더 명확하게 이해하도록 알려주는 방법입니다.

단순히 검색 노출을 높이기 위해 코드를 추가하는 작업으로 보기보다는, 페이지에 있는 정보를 검색엔진이 이해할 수 있는 구조로 정리하는 작업이라고 보는 것이 정확합니다.

Google은 구조화 데이터를 페이지 정보를 제공하고 콘텐츠를 분류하기 위한 표준화된 형식으로 설명합니다. 올바르게 적용하면 Google이 페이지의 의미를 이해하는 데 도움이 되고, 지원되는 유형은 리치 결과 등 확장된 검색 기능에 활용될 수 있습니다.

다만 스키마 마크업을 적용했다고 검색 순위가 자동으로 올라가거나 리치 결과가 반드시 노출되는 것은 아닙니다.

‍

핵심 정리

스키마 마크업의 핵심은 많이 추가하는 것이 아니라 다음 세 가지를 지키는 데 있습니다.

• 실제 페이지 내용과 일치할 것
• 페이지 목적에 맞는 타입을 사용할 것
• Google이 해당 타입을 어떻게 지원하는지 확인할 것

이 세 가지를 기준으로 적용하면 불필요한 마크업을 줄이고, 검색엔진이 페이지의 핵심 정보를 보다 정확하게 이해하도록 만들 수 있습니다.

‍

1. 스키마 마크업이란 무엇인가요?

예를 들어 상품 페이지에 `39,000원`이라는 숫자가 있다고 해보겠습니다.

사람은 주변 문맥을 보고 이것이 상품 가격이라는 것을 알 수 있습니다. 하지만 구조화 데이터를 사용하면 이 값이 단순한 숫자가 아니라 특정 `Product`에 연결된 `Offer`의 가격이라는 점까지 명확하게 표현할 수 있습니다.

즉 검색엔진이 문맥을 추측하도록 두기보다, 페이지에 있는 정보의 종류와 관계를 구조화해서 전달하는 것입니다.

Google 역시 구조화 데이터를 페이지의 의미에 관한 명시적인 단서를 제공하는 방법으로 설명합니다.

_{1-1. 스키마 마크업·구조화 데이터·Schema.org·JSON-LD는 무엇이 다른가요?}

처음 스키마 마크업을 접하면 네 용어가 섞여 사용돼 혼란스럽습니다.

관계를 간단하게 정리하면 다음과 같습니다.

• 구조화 데이터는 페이지 정보를 일정한 규칙에 따라 표현한다는 개념입니다.
• Schema.org는 사람, 기업, 상품, 글처럼 웹상의 정보를 어떤 타입과 속성으로 표현할지 정의한 공통 어휘 체계입니다.
• JSON-LD는 이러한 정보를 실제 코드로 작성하는 형식 가운데 하나입니다.

‍

‍

Google Search는 JSON-LD, Microdata, RDFa를 지원하며, 사이트 환경에서 사용할 수 있다면 일반적으로 JSON-LD 사용을 권장합니다. HTML 본문과 구조화 데이터를 비교적 분리해서 관리할 수 있어 유지보수에도 유리합니다.

정리하면 Schema.org의 어휘를 사용해 페이지 정보를 정의하고, 이를 JSON-LD 등의 형식으로 구현하는 작업을 실무에서 흔히 스키마 마크업이라고 부릅니다.

‍

2. 스키마 마크업은 SEO에 어떤 도움이 되나요?

스키마 마크업의 가장 직접적인 역할은 검색엔진이 페이지의 내용과 의미를 보다 명확하게 이해하도록 돕는 것입니다.

Google은 구조화 데이터를 이용해 페이지의 콘텐츠를 이해하고, 사람·기업·상품 등 페이지에 등장하는 개체에 대한 정보를 파악합니다.

또 Google이 지원하는 구조화 데이터라면 리치 결과 등 확장된 검색결과에 표시될 자격을 얻을 수 있습니다.

하지만 여기서 한 가지를 분명히 해야 합니다.

스키마 마크업 자체를 검색 순위를 직접 올려주는 랭킹 요소로 이해하면 안 됩니다.

Google은 올바른 구조화 데이터를 구현하더라도 리치 결과 표시 자체를 보장하지 않습니다. 따라서 스키마 마크업의 역할은 다음과 같이 이해하면 됩니다.

페이지 의미를 명확하게 전달하고 → 지원되는 검색 기능에 활용될 수 있는 조건을 만들고 → 검색결과에서 사용자가 페이지 정보를 이해하는 데 도움을 주는 것입니다.

‍

‍

실무에서도 “스키마를 넣으면 몇 위가 오르는가?”보다 “검색엔진이 이 페이지의 핵심 정보를 제대로 이해할 수 있는가?”를 기준으로 보는 편이 적절합니다.

‍

3. 내 페이지에는 어떤 스키마 마크업을 적용해야 하나요?

먼저 확인해야 할 것은 페이지의 실제 목적과 핵심 콘텐츠입니다.

“넣을 수 있는 스키마가 무엇인가?”부터 찾기보다 “이 페이지는 무엇을 설명하는 페이지인가?”를 먼저 판단해야 합니다. 그다음 Google이 해당 타입을 어떻게 지원하는지 확인하면 됩니다.

대표적으로는 다음과 같이 검토할 수 있습니다.

‍

‍

예를 들어 상품 상세페이지라면 `Product`, 블로그 글이라면 `Article` 또는 `BlogPosting`을 우선 검토할 수 있습니다.

한 페이지에 여러 타입을 함께 사용하는 것도 가능합니다. 다만 실제 페이지에 존재하는 정보를 설명해야 하며, 타입 개수를 늘리는 것 자체를 목표로 해서는 안 됩니다.

Google Search는 Article, Breadcrumb, Event, LocalBusiness, Organization, Product, ProfilePage, Recipe, Review, Video 등 다양한 구조화 데이터 기능을 지원합니다. 다만 실제 지원 방식과 필요한 속성은 유형마다 다르므로 개별 문서를 확인해야 합니다.

페이지별 스키마 타입 선정이나 기존 마크업 구조가 적절한지 판단하기 어렵다면, 실제 URL을 기준으로 현재 구조화 데이터를 점검해 보는 것이 가장 빠릅니다.

_{3-1. Schema}^._{org에 있는 타입은 모두 Google 검색에 활용되나요?}

아닙니다.

Schema.org에는 매우 많은 타입과 속성이 있지만, 그 모든 항목이 Google의 리치 결과나 검색 기능에 활용되는 것은 아닙니다.

따라서 Google 검색 노출을 목적으로 스키마를 적용한다면 Schema.org에 타입이 존재하는지 확인하는 것만으로는 충분하지 않습니다.

Google Search Central에서 해당 구조화 데이터가 실제로 지원되는지 확인하고, 지원된다면 필수 속성과 권장 속성을 함께 검토해야 합니다.

Google도 Google Search에서의 구체적인 동작을 판단할 때는 Schema.org 문서보다 Search Central 문서를 기준으로 확인할 것을 안내하고 있습니다.

‍

4. 스키마 마크업은 어떻게 적용하나요?

실무에서는 다음 순서로 진행하는 것이 효율적입니다.

1. 페이지 목적 확인
2. 타입 선택
3. Google 지원 여부 확인
4. 실제 콘텐츠와 일치하도록 작성
5. 테스트
6. 배포 후 확인

‍

‍

코드부터 생성하면 페이지 내용과 맞지 않는 타입을 선택하거나, 기존 테마·플러그인이 이미 생성하고 있는 구조화 데이터와 중복될 수 있습니다.

_{4-1. 페이지의 실제 콘텐츠와 목적을 확인합니다}

먼저 해당 URL의 목적을 한 문장으로 정의해보세요.

상품을 판매하는 페이지인지, 정보를 제공하는 블로그 글인지, 회사 자체를 소개하는 페이지인지부터 구분해야 합니다.

구조화 데이터는 실제 페이지를 설명해야 합니다.

페이지에 없는 내용을 구조화 데이터에만 추가하거나, 페이지의 핵심 주제와 관계없는 정보를 마크업하는 방식은 피해야 합니다.

예를 들어 실제 페이지에 리뷰나 평점이 없는데 구조화 데이터에만 별점 정보를 추가하는 방식은 적절하지 않습니다.

_{4-2. Google 지원 타입과 속성을 확인합니다}

페이지 목적에 맞는 타입을 정했다면 Google Search Central에서 해당 타입의 문서를 확인합니다.

Schema.org에 정의된 모든 속성을 채울 필요는 없습니다. Google은 각 검색 기능에서 필요한 속성과 권장 속성을 안내하고 있으므로, 많은 정보를 넣기보다 실제 페이지 내용과 일치하는 값을 정확하게 제공하는 것이 우선입니다.

예를 들어 Article 계열에서는 `author`, `datePublished`, `dateModified`, `headline`, `image` 등의 속성을 활용할 수 있습니다.

_{4-3. JSON-LD를 작성합니다}

예를 들어 블로그 글이라면 다음과 같은 형태로 작성할 수 있습니다.

‍

<script type="application/ld+json">

{

 "@context": "https://schema.org",

 "@type": "BlogPosting",

 "headline": "스키마 마크업이란? 구조화 데이터 적용 방법",

 "image": "https://example.com/images/schema-markup.jpg",

 "datePublished": "2026-09-16",

 "dateModified": "2026-09-16",

 "author": {

   "@type": "Person",

   "name": "홍길동",

   "url": "https://example.com/author/hong"

 }

}

</script>

‍

• `@type`은 어떤 종류의 정보를 설명하는지 나타냅니다.
• `headline`은 글 제목입니다.
• `author`는 작성자입니다.
• `datePublished`와 `dateModified`는 게시일과 수정일을 뜻합니다.

이 예제를 그대로 복사하기보다 실제 페이지에 표시되는 제목, 이미지, 게시일, 수정일, 작성자 정보와 일치하도록 값을 작성해야 합니다.

_{4-4. 실제 페이지에 적용합니다}

JSON-LD는 HTML의 `<head>`나 `<body>`에 삽입할 수 있습니다. Google은 동적으로 생성된 JSON-LD도 처리할 수 있다고 안내합니다.

WordPress나 Shopify 같은 CMS를 사용한다면 직접 추가하기 전에 기존 마크업부터 확인하는 것이 좋습니다.

예를 들어 테마에서 이미 `Article`을 생성하고 있는데 SEO 플러그인에서도 같은 정보를 다시 생성하면, 운영자가 직접 코드를 추가하지 않았더라도 동일한 페이지 정보가 중복될 수 있습니다.

따라서 직접 코드를 추가하기 전에 페이지 소스와 Rich Results Test를 먼저 확인하는 편이 안전합니다.

‍

5. 스키마 마크업이 제대로 적용됐는지는 어떻게 확인하나요?

구조화 데이터는 코드가 유효한지 확인하는 과정과 Google이 실제 페이지를 어떻게 인식하는지 확인하는 과정을 나눠서 보는 것이 좋습니다.

Rich Results Test를 통과했다는 사실만으로 검색결과에 리치 결과가 표시된다는 의미는 아닙니다.

검증할 때는 스키마 문법 자체와 Google의 리치 결과 요구사항을 나눠서 확인하는 편이 좋습니다. Schema.org Validator에서는 구조화 데이터의 문법과 타입 구성을 확인하고, Rich Results Test에서는 Google이 지원하는 리치 결과와 관련된 오류와 자격 여부를 확인할 수 있습니다.

‍

‍

_{5-1. Results Test로 코드를 확인합니다}

Google의 Rich Results Test를 이용하면 페이지에 있는 구조화 데이터를 검사하고, Google이 지원하는 리치 결과와 관련된 오류를 확인할 수 있습니다.

이미 공개된 페이지라면 URL을 입력해 검사하고, 아직 사이트에 적용하지 않은 JSON-LD라면 코드 자체를 입력해 먼저 확인할 수 있습니다.

필수 속성이 빠지거나 형식에 문제가 있어 Critical error가 발생한다면 먼저 수정해야 합니다.

다만 테스트를 통과했다는 것은 구조화 데이터가 기술적으로 유효하고 해당 검색 기능의 자격을 갖출 수 있다는 의미에 가깝습니다.

실제 리치 결과 노출까지 보장한다는 의미는 아닙니다.

_{5-2. URL 검사와 Search Console에서 실제 인식을 확인합니다}

코드를 배포한 뒤에는 Search Console의 URL 검사 기능을 통해 Google이 해당 페이지를 어떻게 확인하고 있는지 점검하는 것이 좋습니다.

특히 사이트 템플릿이나 SEO 플러그인을 변경했다면 이전에 정상 작동하던 구조화 데이터도 다시 확인할 필요가 있습니다.

제목, 작성자, 날짜 등 특정 필드가 빠지거나 예상과 다른 값이 출력될 수 있기 때문입니다.

Google 역시 구조화 데이터를 구현한 뒤 일부 페이지부터 배포하고 URL Inspection 등을 통해 실제 페이지가 어떻게 처리되는지 확인하는 절차를 권장합니다.

구조화 데이터 오류가 계속 발생하거나 동일한 엔티티가 여러 방식으로 중복 생성되고 있다면 개별 코드만 고치기보다 사이트 전체의 스키마 생성 구조를 먼저 파악하는 것이 효율적입니다. 현재 사이트에서 어떤 마크업이 생성되고 있는지부터 확인이 필요하다면 상담을 통해 URL 단위로 점검할 수 있습니다.

‍

6. 스키마 마크업에서 자주 발생하는 실수는 무엇인가요?

스키마 마크업에서 자주 발생하는 문제는 단순한 문법 오류보다 실제 페이지 내용과 구조화 데이터가 서로 맞지 않는 경우입니다.

Rich Results Test에서 오류가 없더라도 구조화 데이터가 페이지를 정확하게 설명하지 못하면 좋은 구현이라고 보기 어렵습니다.

_{6-1. 페이지에 없는 정보를 마크업하는 경우}

페이지에서 사용자가 확인할 수 없는 정보를 구조화 데이터에만 넣는 것은 피해야 합니다.

예를 들어 실제 페이지에는 평점이나 리뷰가 없는데 별점 정보만 구조화 데이터에 추가하거나, 제공하지 않는 서비스 정보를 마크업하는 방식입니다.

구조화 데이터는 실제 페이지의 내용을 그대로 설명해야 합니다.

_{6-2. 페이지 목적과 맞지 않는 스키마를 과도하게 추가하는 경우}

한 페이지에 여러 종류의 스키마를 사용하는 것 자체는 문제가 아닙니다.

예를 들어 실제 페이지에 Article과 Breadcrumb가 함께 존재한다면 두 정보를 모두 구조화할 수 있습니다.

문제는 SEO 효과를 기대하며 페이지와 직접적인 관계가 없는 타입까지 추가하는 경우입니다.

타입 개수를 늘리기보다 페이지의 실제 내용과 관계가 있는 구조화 데이터를 정확하게 표현하는 것이 우선입니다.

_{6-3. 테스트 통과를 리치 결과 노출 보장으로 해석하는 경우}

이 경우 코드 오류만 반복해서 찾기보다 해당 구조화 데이터가 Google에서 어떤 검색 기능을 지원하는지, 현재 페이지가 관련 가이드라인을 충족하는지를 함께 확인해야 합니다.

‍

7. 스키마 마크업 적용 전 무엇을 확인해야 하나요?

사이트 전체에 적용하기 전에 아래 항목을 순서대로 확인하면 불필요한 오류를 줄일 수 있습니다.

• 이 페이지가 무엇을 설명하는 페이지인지 명확한가?
• 페이지 목적에 맞는 스키마 타입을 선택했는가?
• Google Search가 해당 구조화 데이터 유형을 지원하는지 확인했는가?
• 실제 페이지에 보이는 정보와 구조화 데이터가 일치하는가?
• 필요한 속성에 정확한 값을 입력했는가?
• 기존 테마나 플러그인이 같은 구조화 데이터를 생성하고 있지는 않은가?
• Rich Results Test에서 오류를 확인했는가?
• 배포 후 Search Console에서 Google이 페이지를 어떻게 인식하는지 확인했는가?

처음부터 전체 사이트에 일괄 적용하기보다 대표 페이지 몇 개에 먼저 적용하고 검증하는 편이 안전합니다.

문제가 없다면 동일한 템플릿이나 페이지 유형으로 확장하는 방식이 관리하기도 쉽습니다.