검색 결과 페이지에서 별점, 가격, 영업시간, FAQ 드롭다운 같은 부가 정보가 함께 표시되는 페이지를 본 적이 있는가? 이런 풍부한 검색 결과는 우연히 만들어지지 않는다. 스키마 마크업(Schema Markup)이라는 구조화된 데이터 코드를 웹페이지 HTML에 삽입했기 때문에 가능한 것이다.
2024년 기준, 전 세계 약 4,500만 개 도메인이 schema.org 구조화된 데이터를 적용했지만 이는 전체 등록 도메인의 약 12.4%에 불과하다. 반면 Google 첫 페이지에 노출되는 사이트의 72% 이상이 스키마를 사용하고 있다는 통계가 있다. 이 격차가 의미하는 바는 명확하다. 스키마 마크업을 아직 활용하지 않는 사이트에게는 분명한 경쟁 우위를 확보할 기회가 존재한다.
이 글에서는 스키마 마크업의 정확한 정의부터 SEO에서의 역할, 세 가지 인코딩 형식 비교, JSON-LD 실전 구현 방법, Google과 네이버 양쪽에서의 활용 전략, 그리고 반드시 피해야 할 실수와 주의사항까지 데이터를 근거로 상세하게 다룬다. 특히 2023년 FAQ 리치 결과 제한 이후 변화한 스키마 전략과, AI 검색 시대에 스키마가 어떤 새로운 가치를 갖게 되었는지까지 포함했다.
스키마 마크업의 정의: 검색 엔진이 콘텐츠를 '이해'하는 언어
스키마 마크업(Schema Markup)은 웹페이지의 콘텐츠가 무엇에 관한 것인지를 검색 엔진이 기계적으로 해석할 수 있도록 HTML에 추가하는 구조화된 데이터 코드다. 이 코드는 Schema.org라는 국제 표준 어휘(vocabulary)를 기반으로 작성되며, 2011년 Google, Bing, Yahoo, Yandex가 공동으로 만든 프로젝트에서 출발했다. 2015년에는 웹 표준 기구인 W3C에 공식 편입되어 현재까지 활발하게 표준화가 진행되고 있다.
사람은 웹페이지를 보고 "이건 레시피 페이지이고, 조리 시간은 30분이며, 별점은 4.5점"이라고 즉시 판단할 수 있다. 하지만 검색 엔진 크롤러는 HTML만으로는 이런 맥락을 파악하기 어렵다. Schema.org가 제공하는 공식 예시가 이를 잘 설명한다. HTML의 <h1>Avatar</h1> 태그는 브라우저에 "Avatar"라는 텍스트를 큰 제목으로 표시하라는 지시일 뿐, 이것이 2009년 3D 영화를 가리키는지 프로필 사진 유형을 말하는지 구분해주지 않는다. 스키마 마크업은 이런 모호함을 제거하는 역할을 한다.
현재 Schema.org는 827개의 타입(Type), 1,528개의 속성(Property), 14개의 데이터 타입, 94개의 열거형(Enumeration), 522개의 열거형 멤버를 제공한다. 이 방대한 어휘 체계 덕분에 거의 모든 종류의 웹 콘텐츠를 구조화할 수 있다.
구조화된 데이터 vs 스키마 마크업 vs 리치 결과: 용어 구분
이 세 용어는 실무에서 혼용되지만 엄밀히 다른 개념이다.
구조화된 데이터(Structured Data)는 정보를 논리적으로 조직화한 데이터 형태 전체를 의미한다. 관계형 데이터베이스가 대표적인 예시다.
스키마 마크업(Schema Markup)은 구조화된 데이터 중에서도 특별히 Schema.org 어휘를 사용해 웹페이지에 구현한 코드를 가리킨다.
리치 결과(Rich Results)는 스키마 마크업 덕분에 검색 결과 페이지(SERP)에 표시되는 별점, 가격, 이미지, FAQ 등 부가 정보가 포함된 향상된 검색 결과를 말한다.
정리하면, 스키마 마크업은 입력(Input)이고 리치 결과는 출력(Output)이다. 스키마를 넣었다고 반드시 리치 결과가 나오는 것은 아니며, Google이 해당 페이지의 스키마를 유효하다고 판단했을 때만 리치 결과로 표시된다.
** Schema.org에 827개 타입이 존재하지만, Google이 실제로 리치 결과로 지원하는 타입은 약 30여 개 수준이다. Google Search Central의 Structured Data Search Gallery에서 공식 지원 타입을 확인한 뒤 구현 우선순위를 정하는 것이 효율적이다. 다만 현재 미지원 타입이라도 향후 지원될 가능성이 있으므로, 핵심 페이지에는 선제적으로 적용해두면 유리하다.
스키마 마크업이 SEO에 중요한 7가지 이유
스키마 마크업은 Google의 공식 랭킹 팩터가 아니다. Google의 John Mueller를 비롯한 여러 엔지니어가 이를 반복적으로 확인했다. 그런데도 SEO 전문가 절대다수가 스키마 구현을 필수 전략으로 권장하는 이유는 분명하다.
1. 리치 결과(Rich Results)를 통한 CTR 폭발적 향상
리치 결과란 별점, 가격, 이미지, FAQ 등 부가 정보가 함께 표시되는 검색 결과다. Google Search Central에 공개된 Nestlé 사례에 따르면, 리치 결과가 노출된 페이지는 비리치 결과 대비 CTR이 82% 높았다. Milestone Research의 데이터도 리치 스니펫의 평균 CTR이 58%인 반면 일반 결과는 41%에 머물렀다고 보고한다. 구조화된 데이터를 제대로 적용한 사이트는 평균 20~30% 높은 클릭률을 기록한다는 연구도 있다.
2. 검색 엔진의 콘텐츠 이해도 향상
스키마는 검색 엔진에게 페이지 콘텐츠의 맥락(context)을 명시적으로 전달한다. "Paris"라는 단어가 프랑스 수도인지, 캐나다 온타리오의 도시인지, 인물 이름인지를 sameAs 속성으로 위키피디아나 Knowledge Graph 엔티티에 연결해 구분할 수 있다. Schema App의 CEO Martha van Berkel은 "엔티티 링킹(Entity Linking)을 통해 위치 기반 검색 쿼리와 비브랜드 검색어에서 CTR이 증가하는 것을 확인했다"고 밝혔다.
3. AI 검색(AI Overview, ChatGPT, Perplexity) 시대의 핵심 인프라
Google AI Overview, ChatGPT 웹 검색, Perplexity 같은 AI 검색 엔진이 급부상하면서, 스키마 마크업은 단순 SEO를 넘어 AEO(Answer Engine Optimization)와 GEO(Generative Engine Optimization)의 기반 기술이 되었다. AI 시스템은 웹 콘텐츠를 파싱할 때 구조화된 데이터를 핵심 신호로 활용해 콘텐츠의 주제, 구조, 엔티티 관계를 파악한다. 2024년 GEO 연구에 따르면 FAQPage 마크업이 적용된 페이지는 Google AI Overview에 노출될 확률이 3.2배 높았다.
4. E-E-A-T 신호 강화
Organization, Person, Article 스키마를 통해 콘텐츠 저자, 발행 기관, 전문 분야를 명시적으로 선언할 수 있다. sameAs 속성으로 저자의 LinkedIn, 공식 프로필에 연결하면 Google이 저자의 엔티티를 인식하고 신뢰도를 판단하는 데 직접적으로 기여한다.
5. 음성 검색 최적화
Google Assistant, Siri, Alexa 같은 음성 비서는 구조화된 데이터를 활용해 답변을 생성한다. FAQ 스키마나 HowTo 스키마가 적용된 페이지는 음성 검색 결과로 채택될 가능성이 높다.
6. 로컬 SEO 성과 강화
LocalBusiness 스키마를 적용하면 Google 지도와 "내 주변" 검색에서의 노출이 강화된다. 영업시간, 주소, 전화번호, 서비스 지역, 결제 수단 같은 정보를 구조화하여 전달할 수 있기 때문이다.
7. 대규모 사이트의 크롤링 효율성 개선
수백만 페이지를 보유한 사이트에서 스키마 마크업은 검색 엔진이 페이지 내용을 빠르게 파악하는 데 도움을 준다. 크롤링 예산(Crawl Budget)을 절약하는 간접적 효과가 있다.
** 스키마 마크업 자체가 검색 순위를 직접 올려주지는 않는다. "스키마를 넣으면 1위에 간다"는 식의 과장된 기대는 금물이다. 스키마는 검색 엔진의 이해도를 높이고, 리치 결과 자격을 부여하며, AI 검색에서의 인용 가능성을 높이는 역할이다. 순위 자체는 콘텐츠 품질, 백링크, 페이지 경험, E-E-A-T 등 종합적인 요소가 결정한다.
Google이 지원하는 주요 스키마 타입과 활용 사례
Schema.org의 827개 타입 중 Google이 리치 결과로 지원하는 핵심 타입을 용도별로 정리한다. 자신의 사이트 유형에 맞는 타입을 선택하는 것이 첫 번째 단계다.
| 스키마 타입 | 대상 사이트 | 리치 결과 형태 | 우선순위 |
|---|---|---|---|
| Article / BlogPosting | 블로그, 뉴스 | 기사 제목, 썸네일, 발행일 | 필수 |
| Product + Offer | 이커머스 | 가격, 재고, 별점 | 필수 |
| LocalBusiness | 지역 업체 | 영업시간, 주소, 전화번호 | 필수 |
| Organization | 모든 사이트 | 로고, 연락처, 소셜 링크 | 필수 |
| BreadcrumbList | 모든 사이트 | 탐색 경로 계층 구조 | 필수 |
| Person | 저자 페이지 | 저자 정보, 프로필 연결 | 높음 |
| FAQPage | FAQ 페이지 | 질문-답변 펼침 (제한적) | 높음 |
| Recipe | 요리 사이트 | 조리시간, 칼로리, 별점 | 높음 |
| Event | 이벤트/행사 | 날짜, 장소, 티켓 가격 | 중간 |
| VideoObject | 동영상 포함 | 썸네일, 재생시간 | 중간 |
| Review / AggregateRating | 리뷰 사이트 | 별점, 리뷰 수 | 높음 |
| JobPosting | 채용 사이트 | 급여, 위치, 고용 형태 | 중간 |
거의 모든 사이트에 적용해야 할 기본 3종 세트
사이트 유형과 관계없이 Organization + Article(또는 WebPage) + BreadcrumbList 세 가지는 기본으로 적용해야 한다. Organization 스키마는 사이트 운영 주체를 검색 엔진에 명확히 알리고, Article/WebPage 스키마는 개별 콘텐츠의 유형을 정의하며, BreadcrumbList는 사이트의 계층 구조를 전달한다.
** 2025년 6월 Google은 일부 스키마 타입(Sitelinks Search Box, Data Highlights 등)에 대한 지원을 중단했다. 이런 변경은 수시로 발생하므로, Google Search Central의 Search Gallery를 분기별로 확인해 최신 지원 현황을 파악하는 습관이 필요하다. 지원이 중단된 타입의 마크업을 방치해도 페널티는 없지만, 불필요한 코드가 쌓이면 유지보수 비용이 증가한다.
스키마 인코딩 형식 비교: JSON-LD vs Microdata vs RDFa
Schema.org 어휘를 실제 웹페이지에 적용하는 데는 세 가지 인코딩 형식이 존재한다. 형식 선택은 프로젝트의 기술 환경과 유지보수 역량에 따라 달라지지만, 결론부터 말하면 JSON-LD가 압도적인 표준이다.
JSON-LD: Google 공식 권장, 업계 표준
JSON-LD(JavaScript Object Notation for Linked Data)는 Google이 명시적으로 권장하는 형식이다. HTML 본문 코드와 완전히 분리되어 <script type="application/ld+json"> 태그 안에 독립적으로 존재한다. 기존 HTML을 전혀 건드리지 않고 추가, 수정, 삭제가 가능해 유지보수 효율이 탁월하다.
2024년 이커머스 스키마 연구에서 조사 대상 사이트의 61.54%가 JSON-LD를 사용한 것으로 확인되었다. <head> 또는 <body> 어디에든 배치할 수 있으며, @graph 구조를 활용하면 Organization, WebPage, Article, Person 같은 여러 타입을 하나의 스크립트 블록 안에서 @id로 연결해 관계를 표현할 수 있다.
Microdata: HTML 인라인 삽입 방식
Microdata는 HTML 태그의 itemscope, itemtype, itemprop 속성을 사용해 콘텐츠에 직접 스키마 정보를 삽입한다. 코드가 HTML 본문 전체에 분산되기 때문에 복잡한 페이지에서는 가독성과 유지보수가 크게 떨어진다.
RDFa: Resource Description Framework in Attributes
RDFa는 HTML5의 확장으로, vocab, typeof, property 같은 속성을 사용한다. Microdata와 마찬가지로 인라인 방식이며, 사용 빈도가 가장 낮다.
| 비교 항목 | JSON-LD | Microdata | RDFa |
|---|---|---|---|
| Google 공식 권장 | 권장 | 지원 | 지원 |
| HTML 코드 분리 | 완전 분리 (script 태그) | 인라인 삽입 | 인라인 삽입 |
| 유지보수 편의성 | 높음 | 낮음 | 낮음 |
| 코드 가독성 | 높음 | 낮음 (분산) | 낮음 (분산) |
| 구현 난이도 | 쉬움 | 중간~어려움 | 중간~어려움 |
| JavaScript 동적 생성 | 가능 | 어려움 | 어려움 |
| 페이지 크기 영향 | 별도 스크립트 (최소) | HTML 크기 증가 | HTML 크기 증가 |
| 혼합 사용 | @id로 Microdata 연결 가능 | JSON-LD와 혼합 가능 | 단독 사용 권장 |
| 2024년 사용률 | 61.54% | 약 25% | 약 13% |
| 네이버 지원 | 지원 | 지원 | 미확인 |
** JSON-LD와 Microdata를 혼합해서 사용하는 것도 가능하다. 예를 들어 라이브 블로깅처럼 텍스트가 매우 긴 콘텐츠에서는 본문을 Microdata로, 메타 정보를 JSON-LD로 처리하고 @id와 itemid를 매칭시켜 연결할 수 있다. 이 방식은 동일 콘텐츠를 JSON-LD에서 중복 기재하지 않아도 되므로 HTML 크기를 줄이고 페이지 로딩 성능(FCP, LCP)에 미치는 영향을 최소화한다.
네이버의 구조화된 데이터 지원
한국 시장에서 네이버를 무시할 수 없다. 네이버 서치어드바이저에 따르면, 네이버 검색 로봇도 구조화된 데이터를 자동 수집해 콘텐츠 특성에 맞는 검색 결과를 구성한다. 네이버는 JSON-LD와 Microdata 형식을 모두 권장하며, schema.org 표준을 따른다. 채용 정보, 연관 채널, 상품 정보 등 특정 영역에서 구조화된 데이터를 적극 활용하고 있다.
다만, 네이버는 공식적으로 "구조화된 데이터를 정상 마크업했더라도 검색 결과 반영을 보장하지 않는다"고 명시하고 있다. 검증 도구로는 Schema.org에서 제공하는 Schema Markup Validator(validator.schema.org)를 권장한다.
** Google은 JavaScript로 동적 생성된 JSON-LD도 읽을 수 있다고 밝혔지만, 상품(Product) 마크업의 경우 초기 HTML에 직접 포함하는 것을 베스트 프랙티스로 공식 권장한다. JavaScript 렌더링에 의존하면 크롤링 지연이나 누락이 발생할 수 있다.
스키마 마크업 실전 구현 6단계
이론을 파악했다면, 실제 웹사이트에 적용하는 과정을 단계별로 정리한다.
1단계: 사이트 유형 분석과 적용 페이지 선정
모든 페이지에 무차별적으로 스키마를 적용하는 것은 비효율적이다. 전환에 직접적으로 기여하는 핵심 페이지부터 우선순위를 매긴다. 이커머스라면 상품 상세 페이지, 블로그라면 핵심 콘텐츠, 서비스업이라면 서비스 소개와 FAQ 페이지가 1순위다.
2단계: 스키마 타입 매핑
선정한 페이지마다 콘텐츠 유형에 맞는 스키마 타입을 매핑한다. 블로그 포스트에는 Article 또는 BlogPosting, 상품 페이지에는 Product + Offer, 회사 소개 페이지에는 Organization을 적용하는 식이다. 가장 구체적인(specific) 타입을 선택하는 것이 원칙이다. Person 대신 Thing을 쓰거나, NewsArticle이 아닌 Article이 적합한 곳에 NewsArticle을 쓰는 실수를 피해야 한다.
3단계: JSON-LD 코드 작성
수동 작성과 도구 활용 두 가지 방법이 있다.
수동 작성은 Schema.org 문서를 참고해 직접 JSON-LD 코드를 작성하는 방식이다. 개발 역량이 있다면 가장 세밀한 제어가 가능하다.
WordPress 플러그인 활용은 코딩 없이 스키마를 추가하는 가장 빠른 방법이다. Rank Math는 무료 버전에서 Article, Product, Recipe, FAQ, Event 등 다양한 스키마 타입을 제공하고, 포스트 편집 화면에서 스키마 타입을 선택하면 JSON-LD가 자동 생성된다. Yoast SEO는 통합 그래프(Unified Graph) 프레임워크를 통해 Organization, WebPage, Article 스키마를 자동 구성하지만, 일부 고급 스키마 기능은 프리미엄 버전에서만 제공한다.
Google Structured Data Markup Helper를 사용하면 URL을 입력하고 페이지 요소를 태그하는 방식으로 간편하게 마크업 코드를 생성할 수 있다.
4단계: HTML에 코드 삽입
JSON-LD 코드는 HTML의 <head> 또는 <body> 태그 어디에든 배치할 수 있다. Google은 두 위치 모두 정상적으로 인식한다. 관례적으로는 <head> 섹션에 넣는 것이 권장된다.
5단계: 테스트 및 검증
구현 후 반드시 검증 도구로 오류를 확인해야 한다.
- Google Rich Results Test: 스키마가 Google 리치 결과 자격을 충족하는지 확인한다. Google 고유의 필수/권장 속성 충족 여부를 진단한다.
- Schema Markup Validator (validator.schema.org): Schema.org 표준 전체에 대한 유효성을 검사한다. Google 리치 결과 지원 여부와 무관하게 모든 스키마 타입을 검증할 수 있다.
- Google Search Console 구조화된 데이터 리포트: 사이트 전체의 구조화된 데이터 오류, 경고, 유효 항목을 모니터링한다.
- Bing Webmaster Tools Markup Validator: Bing 검색에서의 구조화된 데이터 인식 여부를 확인한다.
6단계: 지속적 모니터링과 유지보수
스키마는 한 번 적용하고 끝이 아니다. 사이트 업데이트, CMS 테마 변경, 플러그인 충돌, URL 구조 변경 등으로 스키마가 깨지거나 무효화될 수 있다. Google Search Console에서 분기별로 구조화된 데이터 리포트를 확인하고, 오류가 발생하면 즉시 수정해야 한다.
** WordPress에서 Rank Math와 Yoast SEO를 동시에 사용하면 스키마가 중복 생성되어 오류를 유발할 수 있다. 반드시 하나의 SEO 플러그인만 활성화하고, 별도의 스키마 플러그인을 추가할 경우 기존 플러그인의 스키마 출력과 충돌하지 않는지 확인해야 한다. 중복 스키마는 검색 엔진 혼란의 가장 흔한 원인이다.
반드시 피해야 할 스키마 마크업 실수 8가지와 Google 스팸 정책
스키마 마크업을 잘못 구현하면 효과가 없는 수준을 넘어 역효과가 발생한다. Google은 구조화된 데이터에 대한 Spammy Structured Markup 수동 조치(Manual Action) 정책을 운영하고 있으며, 위반 시 리치 결과 자격 박탈이나 검색 노출 하락을 초래할 수 있다.
실수 1: 사용자에게 보이지 않는 콘텐츠를 마크업하는 것
스키마 마크업의 내용은 실제로 페이지에서 사용자가 볼 수 있는 콘텐츠와 정확히 일치해야 한다. 숨겨진 텍스트(display:none)나 사용자에게 노출되지 않는 정보를 마크업하면 Google의 스팸 정책에 직접 위반된다.
실수 2: 잘못된 스키마 타입 선택
블로그 글에 Product 스키마를 적용하거나, 일반 기사에 NewsArticle 타입을 사용하는 경우다. Google은 "가장 구체적인 타입을 사용하되, 콘텐츠의 실제 유형과 일치해야 한다"고 명시한다.
실수 3: 필수 속성 누락
각 스키마 타입에는 Google이 정의한 필수(required)와 권장(recommended) 속성이 있다. Product 스키마에서 name이나 image를 빠뜨리면 리치 결과 자격 자체를 얻지 못한다.
실수 4: 허위 또는 오해 유발 정보 입력
실제 별점이 3.2점인데 스키마에 4.9점으로 기재하거나, 실재하지 않는 할인 가격을 표기하는 행위는 명백한 스팸으로 간주된다. Google은 "마크업된 정보가 페이지에 표시된 내용과 정확히 일치하지 않는 경우" 수동 조치를 적용한다.
실수 5: 사이트 전체에 페이지별 스키마를 일괄 적용
모든 페이지에 동일한 Product 스키마를 복사-붙여넣기 하는 식의 구현은 부정확한 데이터를 양산하고 검색 엔진의 신뢰를 떨어뜨린다. 각 페이지의 실제 콘텐츠에 맞는 개별적인 스키마를 적용해야 한다.
실수 6: JSON-LD 문법 오류
쉼표 하나, 중괄호 하나가 빠져도 전체 JSON-LD 스크립트가 무효화된다. 특히 문자열 안의 큰따옴표 이스케이프 누락, 마지막 속성 뒤 불필요한 쉼표(trailing comma) 등이 흔한 실수다.
실수 7: 검증 없이 라이브 배포
적용 후 Rich Results Test나 Schema Markup Validator로 테스트하지 않고 라이브에 바로 올리면, 오류가 있어도 모른 채 수개월간 방치되는 경우가 빈번하다.
실수 8: 과도한 스키마 타입 남용
하나의 페이지에 5~6개 이상의 서로 다른 스키마 타입을 무리하게 적용하면, 오히려 검색 엔진이 페이지의 핵심 주제를 파악하기 어려워진다. 페이지당 핵심 타입 1~2개에 집중하고, 보조 타입(Organization, BreadcrumbList)을 추가하는 방식이 효과적이다.
| 실수 유형 | 위험도 | 결과 |
|---|---|---|
| 보이지 않는 콘텐츠 마크업 | 매우 높음 | 수동 조치(Manual Action) |
| 허위 정보 입력 | 매우 높음 | 수동 조치 + 순위 하락 |
| 잘못된 타입 선택 | 높음 | 리치 결과 미노출 |
| 필수 속성 누락 | 높음 | 리치 결과 미노출 |
| JSON-LD 문법 오류 | 중간 | 스키마 전체 무효화 |
| 중복 스키마 | 중간 | 검색 엔진 혼란, 오류 |
| 검증 미실시 | 중간 | 오류 장기 방치 |
| 과도한 타입 남용 | 낮음~중간 | 핵심 주제 희석 |
** Google의 Spammy Structured Markup 수동 조치를 받으면 리치 결과가 전면 차단되고, 복구까지 수개월이 소요될 수 있다. 의도하지 않은 실수라도 스팸으로 분류되므로, 구현 전 Google Search Central의 General Structured Data Guidelines를 반드시 숙지하고, 배포 전 검증을 습관화해야 한다.
AI 검색 시대의 스키마 전략: FAQ 제한 이후 무엇이 달라졌나
2023년 8월, Google은 FAQ 리치 결과를 권위 있는 정부 및 건강 관련 사이트로 제한하고, HowTo 리치 결과를 데스크톱에서만 표시하다가 이후 완전 폐지했다. 이로 인해 "스키마가 이제 의미 없어진 것 아닌가?"라는 의문이 제기되었다.
하지만 현실은 정반대다. AI 검색의 급부상으로 스키마 마크업의 가치는 오히려 전략적으로 상승했다. SchemaApp의 분석에 따르면, 스키마 마크업의 역할이 "리치 결과 노출"이라는 전술적 효과에서 "AI가 콘텐츠를 정확히 해석하도록 돕는 시맨틱 인프라"로 진화하고 있다.
AEO(Answer Engine Optimization)는 ChatGPT, Perplexity 같은 답변 엔진에서 콘텐츠가 인용되도록 최적화하는 전략이다. FAQ 스키마, Q&A 스키마는 AI가 질문-답변 구조를 파악하는 데 직접적으로 기여한다. Frase.io의 연구에 따르면, FAQ 스키마는 AI 검색 타입 중 가장 높은 인용률을 기록하는 스키마 타입 중 하나다.
GEO(Generative Engine Optimization)는 Google AI Overview 같은 생성형 AI 검색에서 콘텐츠가 참조 소스로 선택되도록 하는 전략이다. Article, Organization, Person 스키마를 통해 콘텐츠 저자와 발행 기관을 명확히 하면, AI가 신뢰할 수 있는 소스로 판단할 가능성이 높아진다.
| 비교 항목 | 2023년 이전 (전통 SEO) | 2024년 이후 (AI 검색 시대) |
|---|---|---|
| 스키마의 핵심 목적 | 리치 결과(별점, FAQ) 노출 | 콘텐츠 의미 전달 + 엔티티 연결 |
| FAQ 스키마의 가치 | 리치 결과 CTR 향상 핵심 | 리치 결과 제한적이나 AI 인용에 핵심 |
| 핵심 전략 타입 | Product, Review, Recipe | Article, Organization, Person, FAQ |
| 효과 측정 지표 | CTR, 리치 결과 노출수 | AI 인용 빈도, 브랜드 멘션, 엔티티 인식 |
| E-E-A-T 연관성 | 간접적 | 직접적 (저자/기관 sameAs 연결) |
| sameAs 속성 중요도 | 선택 사항 | 핵심 전략 (엔티티 디스앰비규에이션) |
| 지식 그래프 연결 | 부가 가치 | 경쟁 우위 요소 |
** FAQ 리치 결과가 제한되었다고 FAQ 스키마를 제거할 필요는 전혀 없다. AI 검색 엔진이 질문-답변 구조를 해석하는 데 여전히 강력하게 작동하고, 권위 있는 정부/의료 사이트에서는 리치 결과도 여전히 표시된다. 리치 결과에 대한 기대치만 조정하고 스키마 자체는 전략적으로 유지하는 것이 현명한 접근이다.
스키마 마크업은 웹사이트의 "보이지 않는 인프라"에 해당한다. 사용자 눈에 직접 보이지 않지만, 검색 엔진과 AI가 콘텐츠를 해석하는 근본적인 방식을 바꿔놓는다. 리치 결과를 통한 CTR 향상은 당장 체감할 수 있는 효과이고, 장기적으로는 사이트의 엔티티를 명확히 정의해 검색 생태계와 AI 생태계 양쪽에서의 권위를 구축하는 과정이다.
2026년 현재, 스키마 마크업은 선택이 아니라 디지털 마케팅의 기본 인프라로 자리 잡았다. SchemaApp은 "2026년 디지털 예산에 스키마 마크업이 반드시 포함되어야 한다"고 명시적으로 권고하고 있다.
지금 바로 Google Search Console에서 사이트의 구조화된 데이터 현황을 확인해보자. 오류가 있다면 즉시 수정하고, 아직 스키마를 적용하지 않았다면 Organization, Article, BreadcrumbList 세 가지부터 시작하는 것을 권한다. 이 세 가지만으로도 검색 엔진과 AI에게 사이트의 정체성을 명확히 전달할 수 있다.