스키마 마크업: 스팸 없는 구조화된 데이터

유효한 JSON-LD 블록이 Rich Results Test를 통과해도 리치 결과가 나타나지 않을 수 있습니다. 검증 실패가 아닙니다. 구조화된 데이터는 기계가 읽을 수 있는 형식으로 콘텐츠를 설명할 뿐 콘텐츠를 대신하거나 검색 기능을 보장하거나 순위 상승 스위치로 작동하지 않습니다.

흔한 실수는 “웹사이트에 어떤 스키마 유형을 더 넣어야 할까?”에서 시작하는 것입니다. 더 적절한 질문은 이 페이지가 어떤 개체를 다루는지, 사용자가 실제로 보는 정보는 무엇인지, Google이 현재 그 콘텐츠 유형에 어떤 표시 방식을 지원하는지입니다.

구조화된 데이터, Schema.org, 스키마 마크업

구조화된 데이터는 기계가 읽을 수 있는 형식으로 정리된 데이터입니다. Schema.org는 개체 유형과 속성을 설명하는 어휘 집합입니다. 스키마 마크업은 그 어휘를 JSON-LD, Microdata, RDFa로 페이지에 넣는 방식입니다.

Google 검색은 여러 기능에서 세 형식을 모두 지원하며 표시용 HTML과 분리하기 쉽고 유지보수가 쉬운 JSON-LD를 주로 권장합니다. 하지만 형식이 잘못된 데이터를 바로잡지는 못합니다. JSON-LD 문법이 완벽한 Product도 페이지에 없는 가격을 명시하면 일관성 원칙을 위반합니다.

스키마가 순위를 높이나요?

스키마를 직접적인 순위 상승 요소로 판매해서는 안 됩니다. 구조화된 데이터는 시스템이 페이지를 더 잘 이해하고 일부 리치 결과의 자격을 갖추도록 도울 수 있습니다. 눈에 띄는 표시가 특정 상황에서 CTR에 영향을 줄 수 있지만 마크업이 올바르더라도 Google은 리치 결과 노출을 보장하지 않습니다.

결과는 다음에도 달려 있습니다.

• 페이지가 크롤링되고 색인되는지.
• 콘텐츠가 검색 정책과 기능별 정책을 충족하는지.
• 데이터가 정확하고 충분하며 최신 상태이고 페이지에 보이는지.
• 검색어, 기기, 지역, Google의 표시 방식 선택.
• 최신 문서상 해당 기능이 여전히 지원되는지.

리치 결과 목록은 바뀔 수 있으므로 오래된 가이드나 플러그인 목록에 의존하지 말고 공식 Search Gallery를 확인하세요.

주요 콘텐츠에서 스키마 유형 선택하기

관련 있어 보이는 모든 유형으로 모든 페이지를 마크업하지 마세요. 주요 개체를 정하세요.

• 편집한 글: Article, BlogPosting 또는 적절한 하위 유형.
• 구매 가능한 상품 페이지: 실제 판매 제안, 가격, 구매 가능 여부를 갖춘 Product.
• 실제 사업장: LocalBusiness 또는 정확한 하위 유형.
• 요리법: Recipe.
• 동영상이 중심인 페이지: VideoObject.
• 조직 소개: Organization.
• 계층형 경로: BreadcrumbList.

상품을 나열하는 카테고리 페이지가 자동으로 하나의 Product가 되는 것은 아닙니다. 노트북 선택법을 설명하는 글도 여러 모델을 언급한다는 이유로 자신을 상품이라고 선언해서는 안 됩니다. 스키마 유형은 페이지가 실제로 제공하는 것을 나타내야 합니다.

JSON 문자열이 아니라 원본 데이터에서 시작하기

지속 가능한 스키마는 사용자 화면을 렌더링하는 것과 같은 데이터 출처에서 생성합니다.

템플릿의 가격은 데이터베이스에서 가져오는데 JSON-LD에는 CMS에 수동 입력한 숫자를 넣으면 첫 할인 행사 때부터 어긋납니다. 구조화된 데이터는 두 번째 콘텐츠 저장소가 아니라 같은 사실의 다른 표현이어야 합니다.

최소한의 BlogPosting 예시

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://example.com/blog/image-seo#article",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/blog/image-seo"
  },
  "headline": "Image SEO and alt text",
  "image": [
    "https://example.com/images/image-seo-1200x630.png"
  ],
  "datePublished": "2026-06-10T08:00:00+07:00",
  "dateModified": "2026-06-15T09:30:00+07:00",
  "author": {
    "@type": "Person",
    "@id": "https://example.com/authors/alex#person",
    "name": "Alex Nguyen",
    "url": "https://example.com/authors/alex"
  },
  "publisher": {
    "@type": "Organization",
    "@id": "https://example.com/#organization",
    "name": "Example",
    "url": "https://example.com/"
  }
}
</script>

이 예시는 구조만 보여줍니다. 구현할 때는 Article 전용 문서의 필수·권장 속성과 대조하세요. 예시의 날짜, URL, 작성자를 운영 환경에 복사하지 마세요.

@id로 개체를 안정적으로 연결하기

@id는 사용자가 별도로 여는 페이지일 필요는 없습니다. 그래프 안의 안정적인 식별자이며 흔히 절대 URL에 프래그먼트를 붙여 사용합니다.

• https://example.com/#organization
• https://example.com/#website
• https://example.com/authors/alex#person
• https://example.com/products/a#product

글의 publisher와 사이트 전체의 Organization이 같은 @id를 참조하면 시스템은 관계없이 이름만 같은 두 객체가 아니라 하나의 개체로 이해합니다.

식별자는 렌더링할 때마다 안정적으로 유지되어야 합니다. 요청마다 새로운 무작위 UUID를 만들지 마세요. 조직과 웹사이트처럼 서로 다른 두 개체에 같은 @id를 사용하는 것도 피하세요.

한 페이지에 여러 항목 넣기

한 페이지에 유효한 구조화된 데이터 블록이 여러 개 있을 수 있습니다.

• 페이지를 설명하는 WebPage.
• 글을 설명하는 BlogPosting.
• 이동 경로를 설명하는 BreadcrumbList.
• 게시자·작성자로 참조되는 Organization 또는 Person.
• 삽입된 주요 동영상을 위한 VideoObject.

객체는 따로 두거나 @graph로 연결할 수 있습니다. 배치보다 정확한 관계와 모순이 없는 것이 중요합니다. 동영상이 관련 없는 광고일 뿐인데 동영상 기능을 노리고 VideoObject를 추가하면 페이지를 잘못 표현하게 됩니다.

모든 노드에 긴 Organization 전체를 반복할 필요는 없습니다. 표준 개체 하나를 선언하고 @id로 참조하면 그래프가 간결해집니다.

필수 속성과 권장 속성

각 기능의 문서는 속성을 필수와 권장으로 구분합니다. 필수 속성이 없으면 항목이 자격을 갖추지 못합니다. 권장 속성은 결과를 풍부하게 하지만 실제 데이터가 있을 때만 선언해야 합니다.

좋은 원칙은 적더라도 정확하고 완전하게입니다. 다음은 추가하지 마세요.

• 실제 평점 없이 aggregateRating 추가.
• 경고를 없애려고 priceValidUntil을 꾸며냄.
• 프로필이나 편집 책임이 없는데 작성자를 “관리자”로 지정.
• 관련 없는 콘텐츠의 이미지로 공통 로고 사용.
• 개체 소유가 아닌 프로필을 가리키는 sameAs 링크.

검사의 경고는 가짜 데이터를 채우라는 명령이 아닙니다. 권장 속성이 없다는 뜻이며 신뢰할 만한 추가 출처가 있는지는 제품팀이 결정해야 합니다.

마크업한 콘텐츠는 보이고 일관되어야 합니다

Google은 구조화된 데이터가 주요 콘텐츠를 정확히 나타내며 독자에게 숨긴 정보를 설명하지 않도록 요구합니다. 위험한 사례는 다음과 같습니다.

• JSON-LD에는 $99인데 페이지에는 “문의”로 표시됨.
• 구매가 비활성화되었는데 스키마에는 재고 있음으로 표시됨.
• 표시되지 않은 별점 5점 후기 다섯 개를 마크업에 선언함.
• FAQ 답변이 JSON-LD에만 있음.
• 만료된 채용 정보의 validThrough가 미래로 설정됨.

“보인다”는 것이 모든 기술 속성을 일반 텍스트로 표시해야 한다는 뜻은 아닙니다. URL, ID, 그래프 관계는 메타데이터일 수 있습니다. 하지만 가격, 평점, 행사, 질문, 작성자처럼 사용자에게 중요한 주장은 실제 경험과 일치해야 합니다.

Product 스키마: 데이터 오류가 가장 빨리 드러나는 영역

가격과 재고는 계속 바뀝니다. Product 마크업은 화면과 같은 요청 또는 파이프라인에서 생성해야 합니다. 다음을 통일하세요.

• 적절한 ISO 코드로 통화 표시.
• 데이터 필드에는 통화 기호 없는 숫자 가격 사용.
• 구매 가능 여부에 올바른 schema.org URL 사용.
• 올바른 변형에 판매 제안 연결.
• 변형의 표준 URL과 상품 ID 일관성 유지.
• 해당 상품의 정당한 후기만 평점에 집계.

변형이 많은 상품은 가격, 색상, SKU를 임의로 한 객체에 합치지 말고 상품 변형 문서를 읽으세요. 페이지에서 구매할 수 없거나 실제 판매 제안이 없다면 오류를 없애려고 가짜 제안을 만들지 마세요.

LocalBusiness: 빈 템플릿으로 사업장을 복제하지 마세요

각 사업장에는 실제 이름, 주소, 전화번호, 영업시간, 서비스 지역, URL이 필요합니다. 해당 랜딩 페이지도 이에 맞는 가치를 제공해야 합니다. 거의 같은 도시 페이지 200개에 LocalBusiness를 추가해도 사무실 200개가 생기지는 않습니다.

스키마의 사실 정보는 문의 페이지, 비즈니스 프로필, 내부 관리 데이터와 일치해야 합니다. 공휴일 영업시간이 바뀌면 같은 출처를 바탕으로 화면과 JSON-LD를 갱신하세요.

후기와 평점은 스팸이 되기 쉬운 영역입니다

다음은 마크업하지 마세요.

• 업체가 직접 작성한 후기.
• 다른 상품에서 가져온 평점.
• 원본 후기 없는 집계 점수.
• 회사에 대한 일반 추천사를 모든 서비스의 평점으로 사용한 것.
• 스크립트 안에만 존재하는 숨겨진 데이터.

품질 위반은 리치 결과 노출 자격을 잃게 하고 구조화된 데이터 관련 직접 조치로 이어질 수 있습니다. 웹 검색 순위 전체가 자동으로 사라진다는 뜻은 아니지만 별 몇 개를 위해 감수할 만한 위험은 아닙니다.

FAQ 스키마가 모든 글의 기본값은 아닙니다

본문의 FAQ는 여전히 독자에게 유용하지만 플러그인에 체크박스가 있다는 이유만으로 마크업을 추가해서는 안 됩니다. 각 리치 결과의 표시 가능성과 조건은 시간, 분야, 정책에 따라 바뀝니다. 대규모로 활성화하기 전에 다음을 수행하세요.

1. 해당 유형이 Search Gallery에 남아 있고 사이트에 적용되는지 확인합니다.
2. 기능별 가이드라인을 모두 읽습니다.
3. 모든 질문과 답변이 페이지에 표시되는지 확인합니다.
4. 같은 FAQ를 수천 URL에 반복하지 않습니다.
5. “유효함”을 성공으로 보지 말고 결과를 측정합니다.

스키마가 편집 구조를 결정해서는 안 됩니다. 콘텐츠에 FAQ가 필요하면 먼저 작성한 뒤 유효한 마크업을 검토하세요.

세 계층으로 검증하기

1계층: JSON과 스키마 문법

파서가 JSON-LD를 읽을 수 있어야 합니다. 쉼표, 괄호, 이스케이프, 데이터 유형이 정확해야 합니다. 상품명의 따옴표 하나를 이스케이프하지 않으면 블록 전체가 깨질 수 있습니다.

2계층: Rich Results Test

이 도구는 Google이 지원하는 유형을 검사하고 오류와 경고를 표시합니다. 오류는 해결해야 하고 경고는 실제 데이터에 따라 평가해야 합니다. “유효한” 항목은 검사 시점의 기술 자격을 충족한다는 뜻일 뿐 표시를 보장하지 않습니다.

3계층: 운영 페이지와 Search Console

배포한 URL을 URL Inspection으로 검사하고 실제 HTML과 리치 결과 보고서를 확인하세요. 스테이징 검사로는 캐시, 언어, 기능 플래그, 동의 처리, 실제 상품 데이터의 오류를 잡지 못합니다.

SEO 검사기로 페이지 신호를 표본 점검하고 무료 SEO 진단으로 비정상적인 메타데이터나 표준 URL 패턴을 찾은 뒤 스키마 원인을 판단하세요.

불완전하거나 문제를 일으키는 데이터 검사하기

완전한 샘플 상품에서는 좋아 보이는 템플릿도 경계 조건에서 깨질 수 있습니다.

• 이미지 없음.
• 가격이 0이거나 미공개.
• 두 가지 통화.
• 이름에 따옴표와 줄바꿈 포함.
• 작성자 없음.
• 이전 작업으로 수정일이 게시일보다 빠름.
• 후기 수가 0.
• 판매 중단 상품.
• 영어 페이지에 원치 않는 베트남어 조직명이 표시됨.

이 사례들의 테스트 데이터를 만드세요. JSON이 파싱되는지, 절대 URL이 올바른 언어를 사용하는지, 필수 속성이 자격을 충족할 때만 나타나는지, 핵심 데이터를 얻을 수 없을 때 객체가 생략되는지 검증하세요.

흔한 구현 오류

두 플러그인이 동시에 스키마 생성

테마가 Article을, SEO 플러그인이 BlogPosting을, 후기 플러그인이 다른 ID의 Product를 생성할 수 있습니다. 그러면 작성자, 이미지, 평점이 모순되는 여러 객체가 생깁니다. 모든 application/ld+json 스크립트를 조사하고 개체별 담당 출처 하나를 선택하세요.

스키마에 스테이징 URL 사용

환경 변수나 캐시 때문에 @id, 이미지, 표준 URL이 테스트 도메인을 가리킬 수 있습니다. 운영 HTML에서 원치 않는 호스트명을 모두 찾아 검사하세요.

언어 데이터 혼합

영어 페이지의 헤드라인은 영어인데 이동 경로와 조직명을 베트남어 버전에서 잘못 가져올 수 있습니다. 공통 부분과 현지화 부분을 정의하고 inLanguage를 사용한다면 확인하세요.

JavaScript가 너무 늦게 마크업 삽입

Google은 JavaScript를 렌더링할 수 있지만 실패하거나 차단된 클라이언트 요청에 의존하면 데이터가 불안정해집니다. 서버에 이미 데이터가 있다면 초기 HTML에 JSON-LD를 렌더링하는 편이 대개 더 단순하고 신뢰할 만합니다.

약한 콘텐츠를 가리기 위한 스키마 사용

상세한 마크업도 정보가 부족한 상품 페이지나 복사한 글을 보완하지 못합니다. 구조화된 데이터는 콘텐츠를 설명하며 페이지에 없는 가치를 만들어내지 않습니다.

배포 후 모니터링

스키마를 약속된 규격으로 배포 절차에 포함하세요.

• 테스트 데이터로 생성기를 단위 검사합니다.
• 주요 템플릿에 스냅샷 또는 스키마 검증을 적용합니다.
• 스테이징과 운영 환경을 크롤링해 항목과 오류를 집계합니다.
• 마크업이 있는 페이지 비율이 급감하면 알립니다.
• 개선사항 보고서와 직접 조치를 모니터링합니다.
• 변경 날짜를 기록해 CTR, 노출, 오류를 비교합니다.

Google이 리치 결과 유형의 지원을 바꿔도 유용한 schema.org 문장을 모두 급하게 제거할 필요는 없습니다. 콘텐츠를 명확히 설명하는 개체 마크업과 특정 검색 기능만을 위해 유지하는 마크업을 구분하세요. 관리 비용과 실제 이익을 비교하세요.

게시 전 체크리스트

• 스키마 유형이 주요 콘텐츠를 정확히 나타내나요?
• 최신 문서상 Google이 기능을 계속 지원하나요?
• 실제 데이터 출처의 필수 속성이 모두 있나요?
• 중요한 주장이 사용자에게 보이나요?
• URL, 이미지, @id가 절대 주소이며 크롤링 가능하고 올바른 도메인인가요?
• 표준 URL과 mainEntityOfPage가 같은 전략적 URL을 사용하나요?
• 날짜, 가격, 구매 가능 여부, 평점이 자동 갱신되나요?
• 다른 플러그인이 만든 중복 객체가 있나요?
• Rich Results Test를 통과하나요?
• 데이터가 없을 때 JSON이 깨지나요?
• 운영 환경과 Search Console을 확인했나요?

결론

좋은 스키마 마크업은 표시 중인 콘텐츠를 정직하고 구조적으로 설명합니다. JSON-LD 복사에서 시작하는 것이 아니라 데이터 모델과 출처의 책임에서 시작합니다. 올바른 유형과 안정적인 ID를 선택하고 실제 속성을 충분히 선언하며 경계 사례를 검사하고 배포 후 모니터링하세요.

경고를 없애려고 평점을 꾸며내거나 숨긴 콘텐츠를 마크업하거나 리치 결과를 확실한 성과로 약속하지 마세요. 페이지 데이터와 구조화된 데이터가 같은 사실을 바탕으로 하면 스키마는 깨지기 쉬운 장식이 아니라 유지보수하기 쉬운 기술 요소가 됩니다.

참고 자료: Google Search Central의 구조화된 데이터 소개, 일반 가이드라인, Schema.org.