스키마 마크업, 구조화된 데이터의 등장
점점 더 많은 사람들이 일상에 AI와 함께합니다. ChatGPT한테 날씨를 물어보며 하루를 시작하고, 기획안 퀄리티를 높이기 위해 Gemini와 이야기하고, 주말 데이트 장소 추천도 AI에게 물어봅니다. AI와 묻고 답하고, 소통하며 사는 시대죠.
소비자이자 마케터인 우리는, 이 현상을 줌 아웃해서 볼 수 있어야 합니다. 우리의 고객 일상에도 AI가 촘촘히 스며들었습니다. 그렇다면 마케터인 우리는 무엇을 해야 할까요? 고객의 새로운 접점인 AI 답변에 우리 브랜드가 언급되게 하는 것, GEO(Generative Engine Optimization)라는 새로운 이름으로 자리잡은 이 영역을 알아야 합니다.
그런데 어떻게 AI 답변에 나올 수 있을까요?
AI 답변 자체는 조작이 불가능합니다. 통제할 수 없는 영역입니다. 다만 우리가 할 수 있는 건, 사용자가 어떤 질문을 던지는지 정교하게 유추하고, 그 답변을 생성할 때 우리 브랜드를 인용할 수 있도록 "신뢰할 수 있는 참고자료"를 준비하는 것입니다.
그 준비의 핵심이 바로 스키마 마크업입니다. (물론, 가장 중요한 건 스키마 마크업이 담고 있는 내용입니다!!!)
AI에게 없는 3가지
스키마 마크업을 이해하려면, 먼저 AI가 어떻게 정보를 읽는지 알아야 합니다.
AI는 눈👀이 없습니다
AI는 사람이 보듯 이미지나 화면을 눈으로 보고 판단하는 것이 아닙니다. 기계의 언어로 정보를 이해하고, 그 언어 간의 관계를 분석해 의미를 해석합니다.
당신의 웹사이트 홈페이지가 아무리 잘 디자인되어 있어도, AI가 그 화면을 "보는" 방식은 사람과 다릅니다. 눈에 보이는 텍스트와 HTML 구조를 읽는 것이지, 디자인의 의도나 레이아웃의 맥락을 감각적으로 파악하지 않습니다.
AI는 두뇌🧠 가 없습니다
이 해석하는 과정이 마치 두뇌가 있는 것처럼 보입니다. 하지만 AI는 두뇌가 없습니다. 인간의 뇌과학 원리를 적용했을 뿐, 스스로 알아서 판단하는 것이 아닙니다.
AI는 텍스트를 잘게 쪼개어 엔티티(entity)로 분류하고, 각 엔티티 간의 관계를 분석해 의미를 추론합니다. "엘리펀트컴퍼니"라는 단어를 읽었을 때, 이게 기업인지 서비스명인지 사람 이름인지 — 문맥이 없으면 확신하지 못합니다. 스키마 마크업은 "이것은 Organization(기업)이고, 이것은 그 기업이 제공하는 Service(서비스)입니다"라고 기계 언어로 명확히 선언하는 것입니다.
AI는 뜨거운 심장🫀이 없습니다
SNS에서 "이 집 서비스 진짜 미쳤다"라는 리뷰가 달렸다고 해봅시다. 마케터인 우리는 맥락에 따라 이게 '최고의 극찬'인지, '최악의 불만'인지 즉각 체감합니다. 하지만 AI에게 "미쳤다(Crazy)"는 중립적이거나 때로 부정적인 단어일 뿐입니다.
다른 예로 바꿔볼까요. "중꺾마(중요한 건 꺾이지 않는 마음)"라는 표현도 마찬가지입니다. AI는 이 문장의 사전적 의미는 알지만, 그 안에 담긴 한국인의 불굴의 의지와 트렌드적 맥락을 스스로 느끼지 못합니다. 스키마 마크업은 이런 인간적 맥락(Context)을 기계가 오해하지 않도록 "이것은 긍정적인 리뷰(Review)이며, 5점 만점의 평점(Rating)을 포함한다"라고 명확한 '팩트'로 박아주는 작업입니다.
AI는 기계입니다. (그런데 이제 아주 뛰어난...)
기계의 언어로, 기계가 볼 수 있도록 정보를 제공해야 비로소 AI가 "볼 수 있고"(AI Visibility), 가장 적합한 정보라고 판단했을 때 비로소 AI가 생성하는 답변에 “언급(mention)하거나 인용(citation)”합니다.
스키마 마크업이란?
스키마 마크업, 기계가 이해할 수 있는 공통 단어 사전!
스키마 마크업은 웹페이지에 추가하는 코드로, 검색엔진과 AI에게 "이 페이지가 무엇인지, 어떤 정보가 담겼는지"를 기계가 읽을 수 있는 언어로 설명합니다.
2011년, 구글·마이크로소프트·야후·얀덱스 네 회사가 함께 만든 공통 어휘 표준 schema.org가 그 기반입니다. "Organization", "Article", "Product"처럼 기계가 이해하는 공통 단어 사전이라고 보면 됩니다. 주요 검색엔진과 여러 플랫폼이 참고하는 대표적인 표준 언어라고 할 수 있습니다.
HTML vs 스키마 마크업, 뭐가 다른가요?
우리가 보는 화면은 HTML로 만들어집니다. 스키마 마크업은 그 HTML 본문에 아무런 영향을 주지 않고, <script> 태그 안에 따로 작성됩니다. 스키마 마크업을 추가해도 방문자 화면에는 아무것도 달라지지 않습니다. 오직 구글과 AI만 읽는 보이지 않는 언어입니다.
| 구분 | 일반 HTML | 스키마 마크업 |
| 표현 방식 | 예) "삼성전자" (텍스트) | 예) "@type": "Organization" |
| 검색엔진 이해 | 단어 나열로 인지 | "조직” 엔티티로 인식 |
| 관계 파악 | 추측 필요 | 명확히 인식 |
| 구글 리치 스니펫 | ❌ 불가능 | ✅ 가능 |
| AI 인용 | ❌ 어려움 | ✅ 높은 확률 |
🥸 스키마 마크업, JSON-LD로만 써야 하나요?
스키마 마크업을 작성하는 형식에는 JSON-LD, Microdata, RDFa 세 가지가 있다고 합니다. 구글이 권장하는 방식은 JSON-LD입니다.
이유는 JSON-LD 형식이 HTML 본문과 완전히 분리되어 있어서 유지보수가 쉽고, 코드에 오류가 생겨도 전체 페이지가 망가지지 않기 때문이라고 하는데요. 더 쉽게 말하면, 페이지의 디자인, 모양이 바뀌어도 정체성(스키마 마크업 내용)은 바뀌지 않는다면 분리하는 것이 더 관리하기 효율적이기 때문입니다.
물론!!! HTML 본문 핵심정보가 바뀐다면, 스키마 마크업도 바꿔줘야 합니다!
스키마 마크업과 구조화된 데이터(Structured Data), 그리고 구글 리치스니펫
- 스키마 마크업 (Schema Markup) : 웹 표준, 전체 어휘 체계
- 구글 구조화된 데이터 (Structured Data) : 구글이 공식 지원하는 타입
- 구글 리치 결과 (Rich Result) : 특정 조건 충족 시 검색 결과 화면(SERP)에 시각적으로 표현하는 것
1️⃣ 스키마 마크업 : 웹 표준
스키마 마크업은 웹 표준입니다. 2011년 구글, 마이크로소프트, 야후, 얀덱스가 공동으로 만든 schema.org라는 공통 어휘 체계를 기반으로 합니다. "이 페이지는 Article이다", "이 조직은 Organization이다", "이 상품의 가격은 얼마다"처럼 기계가 읽을 수 있는 공통 언어로 웹페이지의 의미를 선언하는 것입니다.
2025년 기준 schema.org가 정의하는 타입은 800여개가 넘습니다. Organization, Person, Product, Article, Event, LocalBusiness, Recipe, MedicalCondition, SoftwareApplication... 대부분의 종류의 정보를 구조화할 수 있는 어휘 체계입니다. 어떤 검색엔진이든, 어떤 AI 크롤러든 대부분 이 표준을 사용합니다.
스키마 마크업은 구글만의 것이 아닙니다. Bing, Naver, 그리고 ChatGPT, Perplexity 같은 AI도 이 표준을 읽습니다.
2️⃣ 구글 구조화된 데이터 : 구글이 공식 지원하는 타입
schema.org의 약 800개 타입 중 구글이 "우리가 공식적으로 지원하고, 특정 형식에 맞게 작성하면 검색에 활용하겠다"고 지정한 타입들이 있습니다. 구글은 이를 **구조화된 데이터(Structured Data)**라는 이름으로 별도 문서화하고, 각 타입마다 필수 속성과 권장 속성을 명시해두었습니다.
구글 구조화된 데이터의 핵심은 구글이 요구하는 형식과 속성을 정확히 맞춰야 구글이 제대로 인식한다는 점입니다. schema.org에 정의된 타입이라도 구글이 공식 지원하지 않는 타입은 구글 리치 결과로 표현되지 않을 수 있습니다.
3️⃣ 구글 리치 결과(리치 스니펫) : 조건 충족 시 SERP에 등장하는 시각적 표현
리치 결과(Rich Results, 리치스니펫)는 구글 구조화된 데이터 중에서도 시각적 표현이 가능한 타입에 필수 속성이 충족됐을 때 검색결과에 추가로 보여주는 요소입니다. 일반 파란 링크와 달리 별점, 가격, 발행일, 이미지 썸네일, 이벤트 날짜 같은 정보가 검색결과에 직접 표시됩니다.
리치 결과가 적용된 페이지는 그렇지 않은 페이지보다 평균 20~80% 높은 클릭률(CTR)을 기록하기 때문에, 구글 리치 스니펫을 선점하는 것은 마케팅 성과를 높이기 위한 관점에서 중요합니다.
👉 스키마 마크업, 이왕 쓸거면 구글 리치스니펫 고려해서 쓰자!
모든 스키마 마크업이 구글 리치 스니펫 선점되는 결과가 있는 것은 아닙니다. 다만, 우리가 설계한 스키마 마크업이 구글이 정의한 구조화된 데이터 영역과 유사하다면, 리치 스니펫 선점할 수 있도록 Schema.org의 표준 구글의 구조화된 데이터 마크업의 표준을 같이 적용하는 것이 좋습니다! 1석 2조의 효과!
AI 검색에서 스키마 마크업이 중요한 이유
검색의 판도가 바뀌었다.
서두에서도 언급했지만, AI 기술이 빠르게 대중화 되면서 많은 것들이 바뀌고 있습니다. 특히, 2025년 상반기 엘리펀트를 포함한 고객사들은 AI 기반 검색(ChatGPT, Perplexity, Google AI Overviews)에서 유입된 트래픽이 전년 동기 3배 이상 증가했습니다. 단순한 유행이 아니라 고객의 행동 자체가 바뀌고 있다는 신호입니다.
고객이 "B2B CRM 솔루션 추천해줘"라고 ChatGPT에 물으면, ChatGPT는 10개의 링크를 나열하는 대신 2~7개 브랜드를 직접 언급하며 답변을 만듭니다. 그 답변에 포함되는 브랜드와 그렇지 않은 브랜드의 차이는 어디서 생길까요?
GEO에서 스키마 마크업이 하는 역할 3가지
첫째, 브랜드를 독립된 "엔티티"로 등록합니다.
Organization 스키마를 제대로 작성하면 AI는 당신의 브랜드를 단순한 웹사이트가 아니라, 특정 분야의 전문 기업으로 인식합니다. 마치 사람의 이름이 위키피디아에 등재되어 있으면 AI가 그 사람을 더 확신 있게 언급하는 것처럼요.
둘째, AI가 인용할 수 있는 구조화된 팩트를 제공합니다.
Article 스키마의 description 속성에 담긴 내용은 AI 답변 생성 시 인용 소스가 됩니다. "이 회사가 뭘 하는 곳인지"를 기계가 읽을 수 있는 형태로 준비하는 것입니다.
셋째, 콘텐츠 간 관계를 명시합니다.
provider, isPartOf, about 속성으로 블로그 글과 서비스 페이지, 회사 정보를 연결하면, AI는 개별 페이지가 아니라 하나의 브랜드 지식으로 묶어 인식합니다.
스키마 마크업 없이 아무리 좋은 콘텐츠를 써도, AI는 그것이 누구의 것인지, 어떤 의미인지 확신하기 어렵습니다. 스키마 마크업은 AI에게 보내는 공식 자기소개서입니다.
schema.org가 정의하는 스키마 타입은 수백 가지가 넘습니다. 다행히 마케터가 이 모두를 알 필요는 없습니다. 내 웹사이트, 내 페이지에 어떤 스키마를 적용해야 가장 효과적으로 정보를 선언할 수 있는지를 판단하는 것이 핵심입니다.
업종별 주요 스키마 종류
| 스키마 마크업 | 기대효과 | 업종별 중요도 |
|---|---|---|
| Organization | ✅기업 필수 스키마, Knowlege graph 기초 ✅조직-브랜드 계층구조 중요 (Brand 스키마와 조합) | 공통 / 필수 |
| LocalBusiness | ✅지역 비즈니스를 운영하는 경우 명시 | 해당 시 필수 |
| FAQPage | ✅AI가 가장 인용하기 쉬운 형태 *단, FAQ 남발하면 오히려 신뢰X 단, 구글 구조화된 데이터에서는 민간 기업에게 적용 X | 공통 / 권장 |
| Product | ✅제품 검색 시 가격, 재고, 리뷰 노출 ✅리치 스니펫 선점 | 커머스(뷰티, 패션, 건기식 등) 필수 |
| Service | ✅무형의 제품/서비스에 대한 정보 제공 | B2B SaaS, IT 필수 |
| Review | ✅제품 신뢰, 신뢰 담보하는 역할 | 소비재 권장 |
업종별 추천 스키마 조합
| 업종 | 핵심 스키마 타입 | 포인트 |
|---|---|---|
| B2B SaaS / 에이전시 | Organization, Service, Article, FAQPage | 서비스 소개 + 블로그 콘텐츠가 핵심 |
| 이커머스 (자사몰) | Product, Offer, BreadcrumbList, Review | 가격·재고·평점이 핵심, 리치 스니펫 고려해서 스키마 작업해야 함! |
| 지역 오프라인 매장 | LocalBusiness, OpeningHours, ContactPoint | 영업시간·위치 정보 정확히 |
| 의료·헬스 | MedicalOrganization, Medical Business, Physician, FAQPage | 정확성·권위가 생명 |
| 호텔·숙박 | Hotel, Offer, Review | 체크인 정보, 편의시설 구조화 |
| 교육·강좌 | Course, EducationalOrganization, Event | 강의 일정·수강 조건 명확히 |
기타 활용하면 좋은 스키마
| 스키마 마크업 | 기대효과 | 중요도 |
|---|---|---|
| Image/VideoObject | ✅제품 이미지, 영상 등이 사용법 등 중요한 정보를 담고 있는 경우 | 고관여 제품, 병원 등 권장 |
| Breadcrumb Schema | ✅사이트 구조를 더 명확하게 표현 | 선택 |
| Article/BlogPost | ✅제품, 서비스 외에 유용한 정보 제공시 명시 | 블로그 운영 시 필수 |
| Person | ✅경영진, 창업자 등 주요 인물 전문성 강화 ✅연구진, 저자 등 있는 경우 권장 | 저자, 전문가 있는 경우 권장 |
| Offer, Event 등 | ✅할인, 프로모션 등의 일시적인 이벤트 정보 | 해당 시 권장 |
| Store | ✅오프라인 매장이 있는 경우 | 해당 시 권장 |
페이지별 스키마 마크업 추천 조합
스키마 마크업은 해당하는 웹페이지에 가장 적합한 마크업을 중첩하여 작성할 수 있습니다. 일반적으로 가장 많이 쓰는 조합을 예시로 소개합니다.
- 홈페이지 (
/) →Organization+WebSite세트 (필수) 전체 사이트의 기반 엔티티. 모든 스키마의 출발점.sameAs에 LinkedIn URL 추가하면 AI의 브랜드 인식이 달라집니다. - About Us / 회사 소개 →
Organization+AboutPage회사명·로고·연락처·설립 연도·sameAs(외부 권위 링크) 포함. - 서비스 / 기능 / 솔루션 상세 페이지 →
Service(또는SoftwareApplication) +BreadcrumbList"도입 문의" 중심이면 Service, 앱/소프트웨어 자체를 설명하면 SoftwareApplication.provider로 Organization을 연결하는 것이 핵심입니다. - 요금제 / 가격 페이지 →
Product+Offer+BreadcrumbList플랜명·가격·통화·가용성이 페이지에 실제로 보일 때만 사용. 없는 가격을 넣으면 구글 정책 위반입니다. - 블로그 글 / 인사이트 →
Article또는BlogPosting+BreadcrumbListdateModified가 핵심. 글을 업데이트할 때마다 반드시 수정. AI는 최신 정보를 더 신뢰합니다. - FAQ 페이지 / FAQ 섹션이 있는 서비스 페이지 →
FAQPage+BreadcrumbList실제로 페이지에 보이는 Q&A만 마크업. AI 인용 소스로 활용 가능성이 높습니다. - 단계별 가이드 / How-to 콘텐츠 →
HowTo+Article+BreadcrumbListAI가 "~하는 방법"류 질문에 답변할 때 HowTo 구조를 참조하는 경향이 있습니다.step배열에 각 단계를 명확히 기술해야 합니다. - 문의 / 도입 상담 페이지 →
ContactPage+Organization전화번호·이메일·주소가 있다면ContactPoint도 추가. - 팀 / 전문가 소개 페이지 →
Person저자·연사·임원 페이지. Article의author와 연결하면 사고 리더십(Thought Leadership) 콘텐츠의 신뢰도가 높아집니다.
실전! 스키마 마크업 JSON-LD 코드 직접 보기
스키마 마크업, 왜 쓰라고 하는지는 이해 했는데… 마케터인 내가 코드까지 짜야 하는걸까?! 걱정되시나요? 괜찮습니다. 스키마 마크업 코드를 짜는 것은 아주 단순한 작업이에요. 사실 더 중요한 것은, 어떤 스키마 마크업을 쓸 것이고, 어떤 내용을 담을 것인지 판단하는 게 마케터의 몫입니다.
마크업 코드는 개발자나 엘리펀트가 개발한 Schema 제작 서비스, 스키마 버디 같은 도구가 생성을 쉽게 도와드려요!
JSON-LD 기본 구조, 어떻게 생겼을까?
@context는 "schema.org 언어를 씁니다"는 선언, @type은 "이 페이지는 Article입니다"라는 유형 선언입니다. 이 두 가지만 이해하면 절반은 된 겁니다.
홈페이지: Organization + WebSite
@graph 배열을 쓰면 여러 스키마를 하나의 스크립트에 묶을 수 있습니다. 홈페이지는 Organization과 WebSite를 반드시 세트로 넣으세요.
블로그 글: Article(또는 BlogPost) + BreadcrumbList
코드를 완성했다면 반드시 검증해야 합니다
JSON-LD는 하나의 언어입니다. 그 언어의 문법에 맞게 작성되어야 인식합니다. 완성한 코드는 반드시 Validator로 검증한 뒤 활용해야 합니다.
- 1단계 (필수)— 어휘·문법 오류 확인:schema.org Validator → JSON 문법, 필수 속성 누락 여부
- 2단계 (선택) — 구글 리치스니펫 자격 확인:Google Rich Results Test → 구글이 이 스키마로 어떤 리치 결과를 만들 수 있는지 시뮬레이션. 단, 구글 리치 스니펫은 일부 스키마만 해당하기 때문에 2단계는 선택입니다.
- 3단계 - Validator 결과, 오류가 0건 확인 후 개발팀에 전달하세요.
스키마 마크업, 절대 하지 말아야 하는 것
구글의 구조화 데이터 품질 정책을 위반하면 리치스니펫 노출 박탈은 물론, 검색 순위 패널티까지 받을 수 있습니다. 아래 4가지는 반드시 피하세요.
1. 페이지에 없는 정보를 마크업하는 것
스키마 마크업의 절대 원칙은 하나입니다. 페이지에 실제로 보이는 내용만 마크업하라. 별점이 없는 페이지에 aggregateRating을 넣거나, 가격이 없는 서비스 페이지에 offers를 넣으면 절.대. 안 됩니다.
2. 잘못된 타입 선택
"도입 상담" CTA가 중심인 B2B 서비스 소개 페이지에 Product 스키마를 쓰는 경우가 있습니다. 가격표가 없는데 Product를 쓰면 필수 속성인 offers를 채울 수 없고, 강제로 넣으면 정책 위반입니다. 애매할 때는 Service가 안전합니다.
3. 상대경로 이미지·URL 사용
// 잘못된 예 — 구글이 리소스를 찾지 못함
"logo": "/images/logo.png"
// 올바른 예
"logo": "<https://elifunt.kr/images/logo.png>"
스키마 마크업의 모든 URL과 이미지는 https://로 시작하는 절대경로여야 합니다.
4. 같은 FAQ를 여러 페이지에 복붙
FAQPage 스키마를 만들어놓고 동일한 Q&A를 서비스 소개, 블로그, 문의 페이지에 똑같이 넣는 경우입니다. 구글은 중복 FAQPage를 발견하면 어떤 페이지에서도 FAQ 리치 결과를 주지 않습니다.
스키마 마크업, 한번 만들면 끝일까? …아쉽게도…아니요…
스키마 마크업은 한 번 만들고 끝이 아닙니다. 회사명이 바뀌거나, 서비스가 추가되거나, 가격이 변경되면 스키마도 함께 수정해야 합니다. 오류가 생겨도 방문자 화면에는 아무것도 안 보이기 때문에 모르고 지나치는 경우가 많습니다.
스키마 업데이트가 필요한 순간
다음 상황이 생기면 스키마도 함께 업데이트해야 합니다.
- 회사명, 로고, 주소, 연락처 변경
- 서비스명, 요금제, 가격 변경
- 신규 페이지 추가 / 페이지 URL 변경
- 블로그 글 대폭 업데이트 (dateModified 수정)
- 담당자 이메일·전화번호 변경
이 목록을 온보딩 체크리스트 또는 업무 매뉴얼에 넣어두면, 담당자가 바뀌어도 스키마 관리가 끊기지 않습니다.
스키마 마크업 효율적으로 관리할 수 있는 5가지 필수 툴
스키마 마크업, 관리를 위해 사용할 수 있는 도구들을 소개합니다.
도구 1: Google Search Console (무료, 필수)
구글이 내 사이트의 스키마를 어떻게 인식하고 있는지 확인하는 공식 창구입니다.
- 어떻게 활용하나: Search Console → 검색 결과 → 리치 결과 보고서를 확인하세요. 어떤 페이지의 스키마가 유효한지(Valid), 경고(Warning)가 있는지, 오류(Error)가 있는지 타입별로 보여줍니다.
- 언제 꼭 확인해야 하나: 스키마를 새로 적용한 직후, 사이트 대규모 업데이트 후, 구글에서 "구조화 데이터 문제" 이메일을 받았을 때.
도구 2: Rank Math (WordPress 사이트)
WordPress를 쓰는 경우 가장 많이 추천되는 스키마 관리 플러그인, Rank Math입니다. 23개 이상의 스키마 타입을 코드 없이 GUI로 설정할 수 있고, 콘텐츠를 발행하면서 바로 스키마를 함께 입력할 수 있습니다.
- 무료 버전에서도 Article, Product, FAQ, HowTo 등 핵심 타입을 모두 지원합니다. PRO 버전에서는 페이지별 커스텀 스키마 템플릿과 실시간 검증 기능도 제공합니다.
- 추천 대상: WordPress + Elementor 또는 Gutenberg 사용자, SEO 담당자가 직접 스키마를 관리하고 싶은 경우.
도구 3: Yoast SEO (WordPress 사이트)
Rank Math와 함께 WordPress에서 가장 많이 쓰이는 SEO 플러그인입니다. Yoast의 강점은 Schema Graph 개념 — 사이트 내 여러 페이지의 스키마를 서로 연결하는 구조를 자동으로 관리합니다.
- 추천 대상: 이미 Yoast를 쓰고 있는 경우, Organization-WebSite-Article 연결 구조를 간편하게 유지하고 싶은 경우.
도구 4: Schema Buddy (모든 웹사이트 · 마케터 전용)
비개발자 마케터가 웹사이트 URL만 입력하면 사이트 전체를 분석해 페이지별 스키마 마크업을 자동 생성하는 도구입니다. 속성 편집 테이블에서 값을 채우면 JSON-LD가 실시간으로 완성되고, 개발팀에 전달할 수 있는 형태로 내보낼 수 있습니다.
WordPress에 종속되지 않아도 되고, 코드를 전혀 몰라도 마케터가 직접 스키마를 만들고 검증할 수 있습니다. (엘리펀트 웹사이트에 공개할 예정입니다!)
- 추천 대상: 모든 웹사이트, 개발 리소스 없이 스키마를 관리해야 하는 마케팅 팀.
도구 5: schema.org Validator + Google Rich Results Test (검증 전용)
새 스키마를 작성하거나 수정했을 때마다 확인하는 검증 도구입니다. 관리 도구는 아니지만, 스키마를 배포하기 전 마지막 관문으로 반드시 거쳐야 합니다.
- schema.org Validator — 어휘·문법 오류
- Google Rich Results Test — 리치스니펫 자격 확인
그래도 어렵나요? 자주 묻는 질문 10가지
Q1. 스키마 마크업을 넣으면 검색 순위가 바로 올라가나요?
직접적인 순위 상승 요인은 아닙니다. 구글은 공식적으로 스키마 마크업을 순위 결정 요인으로 쓰지 않는다고 밝혔습니다. 하지만 리치스니펫으로 인한 CTR 향상이 간접적으로 순위에 영향을 주고, AI 검색 인용 가능성을 높이는 데는 매우 직접적인 효과가 있습니다.
Q2. WordPress를 쓰는데, 개발자 없이 스키마 마크업을 할 수 있나요?
가능합니다. Rank Math 또는 Yoast SEO 플러그인을 설치하면 GUI 폼에서 스키마를 설정할 수 있습니다. 코드를 직접 작성하지 않아도 됩니다. 다만 GEO 최적화를 위한 세밀한 설정은 스키마 버디 같은 툴을 활용해 JSON-LD를 작성하는 것을 추천합니다!
Q3. 스키마 마크업과 og태그(Open Graph)는 같은 건가요?
다릅니다. og태그는 카카오톡·SNS에서 링크 미리보기(제목·이미지·설명)를 위한 것이고, 스키마 마크업은 구글과 AI가 페이지의 의미를 이해하기 위한 것입니다. 둘 다 필요하며 서로 보완적입니다.
Q4. 스키마 마크업을 적용했는데 리치스니펫이 안 뜨는 이유는 뭔가요?
네 가지를 확인하세요. ① 구글이 해당 페이지를 아직 크롤링하지 않았을 수 있습니다(Search Console에서 색인 상태 확인). ② 스키마 코드에 오류가 있을 수 있습니다(Rich Results Test로 검증). ③ 해당 타입의 리치 결과가 일반 기업에 제한되어 있을 수 있습니다(구글의 리치 스니펫은 민간 기업에 적용되지 않는 항목들이 있습니다). ④ 스키마 적용 후 구글이 리치 결과를 부여하기까지 수 주가 걸릴 수 있습니다.
Q5. 스키마 마크업은 얼마나 자주 업데이트해야 하나요?
"이벤트처럼 주기적으로"가 아니라, "변경사항이 생길 때마다 즉시" 업데이트해야 합니다. 회사 정보, 서비스명, 가격, 콘텐츠 내용이 바뀌면 반드시 함께 수정하세요.
Q6. 작은 회사나 스타트업도 스키마 마크업이 필요한가요?
오히려 작은 회사일수록 더 필요합니다. 대기업은 브랜드 인지도 자체가 AI가 인식하는 신호가 됩니다. 아직 브랜드 인지도가 낮은 회사는 스키마 마크업으로 엔티티를 선언하는 것이 AI에게 "우리가 여기 있다"를 알리는 가장 확실한 방법입니다.
Q7. 스키마 마크업 없이도 AI가 우리 브랜드를 언급할 수 있나요?
물론입니다. 스키마 마크업이 AI 인용을 보장하지는 않습니다. 하지만 스키마 마크업이 있는 페이지는 AI가 더 정확하게 이해하고, 더 확신 있게 인용할 가능성이 높습니다. FAQ 스키마 적용 시 AI Overviews 등장 확률이 3.2배 높다는 데이터가 그 근거입니다.
Q8. 모든 페이지에 스키마를 넣어야 하나요?
그럴 필요는 없습니다. 우선순위는 ① 홈페이지(Organization+WebSite) → ② 핵심 서비스/제품 페이지 → ③ 블로그 주요 글 → ④ 문의/CTA 페이지 순서입니다. 콘텐츠가 많은 경우, 트래픽이 높은 페이지부터 차례로 적용하는 것이 현실적입니다.
Q9. 스키마 마크업을 여러 개 중복으로 넣어도 되나요?
한 페이지에 같은 타입을 중복으로 넣으면 안 됩니다. 다만 서로 다른 타입은 @graph 배열로 묶어 함께 사용할 수 있습니다. 예를 들어 블로그 글에 Article + BreadcrumbList + FAQPage를 하나의 @graph로 묶는 것은 권장 방식입니다.
Q10. 스키마 마크업 작성을 대행해주는 서비스가 있나요?
그럼요! 엘리펀트컴퍼니에 문의해주세요!
직접 하고 싶다면 엘리펀트컴퍼니가 만든 스키마 버디(Coming Soon!!)처럼 마케터가 코드 없이 스키마를 만들 수 있는 도구를 활용하는 것이 현실적입니다. 중요한 것은 어떤 방식을 택하든, 스키마에 담기는 내용(어떤 정보를 강조할지)은 마케터가 직접 판단해야 한다는 점입니다.
결론! 스키마 마크업, 개발자의 영역일까?
사실은 마케팅, 커뮤니케이션의 영역입니다.
우리 브랜드가 무엇인지, 우리 서비스가 무엇을 해결하는지, 우리 콘텐츠가 누구를 위한 것인지 — 이것을 사람이 아닌 기계의 언어로, AI가 읽을 수 있는 형태로 선언하는 것. 그것이 스키마 마크업입니다.
AI가 일상이 된 시대에, 고객이 AI에게 물어볼 때 당신의 브랜드가 답변에 등장하게 하고 싶다면, 지금 시작해야 합니다.
1순위부터 시작하세요. 홈페이지 Organization 스키마 하나부터! 엘리펀트가 함께 할게요 : )