스키마 마크업은 Schema.org의 유형과 속성으로 웹페이지에 담긴 정보와 관계를 표현하는 코드입니다. 글의 제목과 작성자, 상품의 가격과 재고처럼 각 값이 무엇을 뜻하는지 기계가 구분하도록 돕습니다. 페이지에 보이는 실제 정보에 맞춰 작성해야 합니다.
유형, 속성, 값으로 정보를 표현하는 방법
다음은 글을 Article 유형으로 표시하고 제목, 발행일, 작성자를 넣은 JSON-LD 예시입니다. 구조를 설명하기 위한 코드이므로 적용할 때는 해당 글의 실제 제목, 날짜와 작성자 정보로 바꿔야 합니다.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "스키마 마크업이란?",
"datePublished": "2026-07-26",
"author": {
"@type": "Organization",
"name": "AVCD"
}
}
</script>
- 유형은 대상의 종류입니다. 예시의
Article은 글을, 작성자에 넣은Organization은 조직을 나타냅니다. - 속성은 대상의 어떤 정보를 나타내는지 정하는 항목입니다.
headline은 제목,datePublished는 발행일,author는 작성자를 뜻합니다. - 값에는 실제 제목과 날짜, 작성자 정보를 넣습니다. 제목처럼 글자로 적는 값도 있고, 예시의 작성자처럼 별도의 유형과 속성을 갖춘 대상을 넣는 값도 있습니다.
구조화 데이터와 JSON-LD의 관계
구조화 데이터는 정보를 일정한 구조로 표현한 데이터를 뜻합니다. Schema.org는 Article, author처럼 그 구조에서 쓸 유형과 속성의 이름을 정한 공용 어휘입니다. JSON-LD는 이 정보를 코드로 작성하는 형식입니다.
| 구분 | 역할 | 예시 |
|---|---|---|
| 구조화 데이터 | 정보를 정해진 항목과 관계로 표현 | 글 제목과 작성자를 구분한 데이터 |
| Schema.org | 유형과 속성의 이름 및 의미 정의 | Article, author |
| JSON-LD | 데이터를 코드로 표현하는 형식 | application/ld+json 스크립트 |
Google은 JSON-LD, Microdata, RDFa를 지원하며, 대체로 구현과 관리가 쉬운 JSON-LD를 권장합니다. 세 형식 모두 같은 Schema.org 유형과 속성을 표현할 수 있습니다. JSON-LD는 본문 HTML과 별도의 스크립트에 데이터를 적고, Microdata와 RDFa는 HTML 요소의 속성에 정보를 넣는다는 차이가 있습니다.
페이지에 맞는 유형 고르기
조직을 소개하는 홈페이지나 회사 소개 페이지에는 Organization, 제품 상세 페이지에는 Product, 기사나 블로그 글에는 Article 계열을 적용할 수 있습니다. Google은 조직 정보의 경우 홈페이지나 조직을 소개하는 한 페이지에 두도록 권장하며, 모든 페이지에 반복할 필요는 없다고 안내합니다.
Schema.org에 유형이 있어도 검색엔진이 그 유형의 리치 결과를 제공하지 않을 수 있습니다. Google 검색 기능이 목적이라면 검색 갤러리에서 지원하는 유형을 찾고, 그 기능의 필수 속성과 정책을 따라야 합니다. 필수 속성이 없는 Organization도 있지만, LocalBusiness처럼 별도 지침이 있는 하위 유형까지 필수값이 없다고 보아서는 안 됩니다.
화면에 없는 상품이나 리뷰를 코드에만 넣어서는 안 됩니다. 한 페이지에 여러 유형을 쓰더라도 각각 실제 본문의 대상과 일치해야 합니다.
WordPress에서 누가 마크업을 출력하는지 확인하기
WordPress에서는 테마, SEO 플러그인, 개발자가 작성한 템플릿이 마크업을 출력할 수 있습니다. 커스텀 필드의 값을 읽어 JSON-LD를 만드는 구성도 가능합니다.
새 코드를 넣기 전에 페이지 소스에서 application/ld+json을 검색해 기존 마크업을 찾습니다. 테마와 플러그인이 같은 Organization이나 Article을 각각 출력한다면 이름, 작성자와 날짜가 서로 같은지 대조합니다. 같은 유형이 여러 번 있다는 사실만으로 오류는 아니지만, 한 대상을 서로 다른 값으로 설명하고 있다면 어느 기능이 잘못된 값을 출력하는지 찾아야 합니다.
여러 대상을 그래프로 연결하기
한 글에는 글 자체인 Article, 작성자인 Person 또는 Organization, 탐색 경로인 BreadcrumbList가 함께 들어갈 수 있습니다. 같은 대상을 여러 곳에서 참조할 때 @id를 쓰면 어떤 조직이나 작성자를 가리키는지 연결할 수 있습니다.
{
"@context": "https://schema.org",
"@graph": [
{"@type": "Organization", "@id": "https://example.com/#org", "name": "AVCD"},
{"@type": "Article", "headline": "스키마 마크업이란?", "author": {"@id": "https://example.com/#org"}}
]
}
예시의 @graph에는 조직과 글이 함께 들어 있습니다. 조직에 부여한 @id를 글의 author에서 다시 참조하므로, “이 글의 작성자는 그 조직이다”라는 관계를 표현합니다. 이 방식을 쓰면 작성자 정보를 참조하는 곳마다 같은 조직임을 명시할 수 있습니다. 모든 Google 리치 결과가 @graph나 이 연결 방식을 요구하는 것은 아닙니다.
운영할 때는 조직 정보, 글 정보 등 각 데이터를 어느 플러그인이나 템플릿에서 출력할지 정합니다. 중복 기능을 끈다면 필요한 데이터까지 없어지거나 기존 @id 참조가 끊기지 않았는지 배포된 페이지에서 다시 검사합니다.
화면과 코드가 같은 값을 쓰도록 관리하기
가격, 재고, 작성자, 수정일을 화면과 마크업에 따로 입력하면 한쪽만 갱신하기 쉽습니다. 제품 데이터베이스나 CMS 필드처럼 원본을 한 곳에 두고 화면과 JSON-LD가 같은 값을 읽도록 구성합니다.
상품 가격을 바꾼 뒤에는 화면과 Product 마크업에 새 가격이 표시되는지 확인합니다. 이전 값이 남았다면 데이터 원본뿐 아니라 캐시가 예전 내용을 제공하는지도 확인합니다. 작성자를 바꿨을 때는 화면의 작성자 정보와 Article의 author를 대조합니다. 같은 템플릿으로 많은 페이지를 운영한다면 화면과 JSON-LD의 값을 자동 비교해 불일치를 찾는 방법도 쓸 수 있습니다.
검사 도구와 오류를 구분하는 법
Schema Markup Validator는 Schema.org 마크업을 추출하고 유형, 속성과 구문을 검사합니다. 리치 결과 테스트는 Google이 지원하는 검색 기능의 기술적 요건을 검사합니다. 한 도구에서 오류가 없다고 다른 도구의 요건까지 충족한 것은 아닙니다.
| 문제 | 확인할 내용 |
|---|---|
| 코드 구문 오류 | 쉼표나 괄호가 빠지지 않았는지, 값의 형식이 맞는지 확인합니다. |
| 검색 기능 요건 오류 | 해당 Google 기능의 필수값과 지원 값, 중첩 구조에 맞게 수정합니다. |
| Schema.org 경고 | 해당 유형에 쓸 속성이 맞는지, 속성이 기대하는 종류의 값을 넣었는지 대조합니다. |
| 권장 속성 경고 | 실제로 제공할 수 있는 정보라면 보완합니다. |
| 정책 또는 본문 불일치 | 화면에 없는 가격, 리뷰나 작성자를 코드에 넣지 않았는지 사람이 직접 대조합니다. |
개발 중에는 코드를 검사하고, 배포 후에는 URL로 다시 검사합니다. 이후 Google 서치 콘솔의 URL 검사에서 Google이 수집한 페이지와 구조화 데이터를 확인합니다. 해당 유형의 보고서가 있다면 배포 뒤 유효하지 않은 항목이 늘었는지도 살핍니다. 경고를 없애려고 확인되지 않은 값을 만들어 넣어서는 안 됩니다.
검사를 통과했다고 리치 결과가 반드시 표시되지는 않습니다. 노출이 사라졌다면 코드뿐 아니라 색인 상태, 현재 지원 기능, 수동 조치, 구조화 데이터 정책, 해당 검색어의 결과 구성을 확인해야 합니다. Google이 기능을 중단하거나 해당 검색에서 표시하지 않는 상황은 코드 수정만으로 해결할 수 없습니다.
AI 검색과의 관계
Google은 AI Overviews와 AI Mode에 표시되기 위해 별도의 스키마 유형을 추가할 필요는 없다고 안내합니다. 구조화 데이터는 기존 정책에 맞게 작성하고 본문과 일치시켜야 합니다. 마크업의 유효성만으로 AI 답변에 인용될지는 판단할 수 없습니다.
Google 검색의 생성형 AI 기능에 사이트를 포함할지는 스키마와 별도로 Search Console의 “Search generative AI” 설정에서도 관리합니다. 기본값은 포함이며, 상위 속성이 있으면 그 설정을 상속할 수 있습니다. 스키마를 추가해도 이 설정에서 제외한 사이트를 다시 포함시키지는 않습니다.
자주 묻는 질문
마크업을 넣으면 순위가 오르나요?
마크업은 검색엔진이 페이지의 정보를 해석하고 리치 결과 후보로 처리하도록 돕습니다. 코드가 유효해도 콘텐츠와 검색 기능의 지침을 충족해야 하며, Google이 항상 리치 결과로 표시하는 것은 아닙니다. 마크업을 추가했다는 사실만으로 순위 상승을 기대해서는 안 됩니다.
모든 페이지에 같은 스키마를 넣어도 되나요?
공통 템플릿을 쓸 수는 있지만 값까지 똑같이 복사하면 안 됩니다. 상품의 이름과 가격, 글의 제목과 작성자는 각 페이지의 실제 내용이어야 합니다. 조직 정보도 모든 페이지에 반복해야 하는 것은 아니며, Google은 홈페이지나 조직 소개 페이지에 두도록 권장합니다.
오류 없이 경고만 있으면 괜찮나요?
리치 결과 테스트의 권장 속성 경고라면 해당 항목은 여전히 유효할 수 있습니다. 반면 Validator에서 유형과 속성이 맞지 않는다고 표시했다면 Schema.org 정의를 대조해야 합니다. 검사 도구와 경고 내용을 확인한 뒤 실제 정보를 보완하고, 코드 값이 본문과도 일치하는지 점검합니다.
함께 알아두면 좋은 용어
- 구조화 데이터: 페이지 정보를 정해진 형식으로 분류해 제공하는 데이터
- JSON-LD: JSON 문법으로 구조화 데이터를 표현하는 형식
- Schema.org: 스키마 유형과 속성을 제공하는 공동 어휘
- 리치 결과: 구조화 데이터를 바탕으로 추가 요소가 표시될 수 있는 검색결과