[2026 최신] 스키마 마크업 적용 시 고려사항 완벽 가이드 | 테라그로스

우리가 대행사에서 클라이언트 사이트에 스키마 적용을 본격적으로 시작한 게 꽤 됐는데, 처음엔 그냥 “Article 스키마만 박아두면 되겠지” 싶었다. 근데 막상 해보니 함정이 한두 개가 아니더라. 잘못 박았다가 Search Console에서 경고 폭탄 맞은 적도 있고, 폐기된 스키마를 모르고 추천했다가 클라이언트한테 미안했던 적도 있다. 2026년 현재 시점에서 우리가 직접 부딪치며 정리한 고려사항을 풀어본다.

스키마 마크업이 2026년에 더 중요해진 이유

몇 년 전만 해도 스키마는 그냥 “있으면 좋은 것” 정도였다. 리치 결과 별점 보여주고, 빵부스러기 경로 예쁘게 나오게 하는 그 정도. 근데 2026년 들어 분위기가 완전히 바뀌었다. 구글의 AI Overviews가 검색 결과 상단을 차지하면서, 어떤 콘텐츠가 AI 답변의 근거로 인용되느냐가 핵심 쟁점이 됐다.

AI 답변 생성 모델들이 웹페이지를 이해할 때, HTML 본문만 보는 게 아니라 JSON-LD에 박힌 구조화 데이터를 우선 참조한다. 사실 이건 구글뿐만 아니라 ChatGPT Search, Bing의 Copilot, Perplexity 모두 비슷한 방식으로 움직인다. 우리가 운영하는 한 이커머스 클라이언트는 Product 스키마를 정밀하게 다시 짠 뒤 AI Overviews 인용 빈도가 눈에 띄게 늘었다.

리치 결과보다 중요해진 GEO 신호

GEO(Generative Engine Optimization)라는 용어가 본격적으로 자리 잡은 게 2025년 후반이다. 과거에는 SERP 1페이지 진입이 목표였다면, 지금은 AI 답변 박스 안에 우리 사이트가 출처로 떠야 한다. 이 출처 인용에 가장 강한 신호를 주는 게 바로 스키마다.

구체적으로 말하면, FAQPage(단 자격 있는 도메인에 한해), HowTo가 폐지된 자리를 대신하는 Article과 Question 스키마 조합, 그리고 Organization 스키마의 sameAs와 knowsAbout 필드가 AI에 “이 사이트가 뭘 아는 곳인지”를 알려주는 핵심 통로가 됐다.

JSON-LD 형식을 우선해야 하는 이유

스키마 마크업은 크게 세 가지 방식이 있다. JSON-LD, Microdata, RDFa. 구글은 공식 문서에서 JSON-LD를 명확하게 권장한다(support.google.com/search/docs/appearance/structured-data/intro-structured-data). 근데 아직도 옛날 블로그 글 따라서 Microdata로 박아두는 경우가 종종 보인다.

JSON-LD가 좋은 이유는 본문 HTML과 분리돼 있어서다. 콘텐츠 수정해도 스키마는 그대로 유지되고, 거꾸로 스키마만 수정해도 본문은 멀쩡하다. 우리가 처음 대행을 맡았을 때 인계받은 한 클라이언트 사이트는 product 페이지마다 itemprop 속성이 본문 곳곳에 뿌려져 있어서, 디자이너가 마크업 수정하면 스키마가 깨지는 일이 반복됐다. JSON-LD로 통째 갈아엎고 나서야 운영이 정상화됐다.

2026년 폐지된 스키마, 절대 쓰면 안 되는 것들

이게 진짜 중요하다. 옛날 글들 보고 따라 하면 안 되는 스키마가 꽤 있다. 2023년 8월 구글이 FAQ 스키마 노출 정책을 크게 바꿨고, 지금은 정부 사이트와 공인된 의료/보건 사이트에서만 리치 결과로 노출된다. 일반 기업 블로그에 FAQ 스키마 박아둬도 검색결과에 아코디언처럼 안 펼쳐진다.

HowTo 스키마는 2023년 9월 모바일/데스크톱 양쪽 모두 리치 결과 노출이 폐지됐다. 아직도 “HowTo 스키마 적용법” 같은 글이 검색되는데, 추천하면 클라이언트한테 욕먹는다. SpecialAnnouncement 스키마는 2025년 7월 공식 폐지됐다. 코로나 시기에 잠깐 쓰던 건데 이제는 전혀 의미 없다.

그럼 FAQ와 HowTo 콘텐츠는 어떻게 표시하나

스키마는 못 박지만 콘텐츠 자체는 여전히 가치 있다. 우리는 FAQ 형태의 Q&A 섹션을 본문 HTML로 깔끔하게 정리해두고, 대신 Article 스키마의 mainEntity 필드에 Question/Answer 객체를 중첩시키는 방식으로 처리한다. 리치 결과에는 안 떠도 AI 답변 생성 시 인용 신호로는 작동한다.

HowTo 콘텐츠도 마찬가지다. 본문에 단계별 가이드를 ol 리스트로 명확하게 구조화하고, 각 step에 image와 캡션을 붙여둔다. 이게 AI Overviews에서 인용될 확률을 높인다.

도메인별로 다르게 짜야 하는 스키마 전략

이 부분에서 실수하는 분들이 정말 많다. 모든 사이트에 똑같은 스키마 템플릿 돌리면 안 된다. 이커머스, 콘텐츠 미디어, B2B SaaS, 로컬 비즈니스마다 우선순위가 완전히 다르다.

이커머스의 경우

Product 스키마가 최우선이다. 근데 단순히 name, price, image만 넣으면 부족하다. 2026년 기준 구글은 aggregateRating, review, availability, priceValidUntil, shippingDetails까지 요구한다. 특히 shippingDetails는 2024년부터 거의 의무화됐다. 무료배송 여부, 배송 소요일을 명확히 박아두지 않으면 머천트 리스팅에서 밀린다.

Offer 객체 안에 hasMerchantReturnPolicy를 추가하는 것도 잊지 말아야 한다. 반품 정책이 명시된 상품은 리치 결과에서 작은 신뢰 뱃지가 붙는다. 우리가 운영하는 패션 카테고리 클라이언트는 이거 추가하고 클릭률이 의미 있게 올랐다.

콘텐츠 사이트와 블로그

Article, NewsArticle, BlogPosting 중 콘텐츠 성격에 맞게 선택해야 한다. 뉴스성 콘텐츠가 아닌데 NewsArticle 쓰면 안 된다. 헷갈리는 분들이 많은데, 일반 정보성 블로그는 Article 또는 BlogPosting이 맞다.

중요한 건 author 필드를 Organization이 아니라 Person으로 박아두는 것이다. E-E-A-T 신호 때문이다. 사람 이름 + sameAs로 LinkedIn, 학회 프로필 같은 외부 권위 링크를 박아두면 신뢰도가 올라간다. 우리는 클라이언트 콘텐츠 작성자마다 Person 스키마 데이터베이스를 따로 관리한다.

로컬 비즈니스

LocalBusiness 스키마는 GPS 좌표(geo), 영업시간(openingHoursSpecification), 결제 수단(paymentAccepted), 서비스 지역(areaServed)을 빠뜨리면 안 된다. 특히 areaServed는 광고 진행할 때 지역 타기팅과도 연결되니까 정밀하게 짜야 한다.

스키마와 본문 콘텐츠의 일치성 – 위반하면 패널티

구글 가이드라인에서 가장 강조하는 게 이거다. 스키마에 적힌 내용이 실제 페이지에 보여야 한다. 너무 당연한 얘기 같지만, 의외로 자주 어긴다.

예를 들어 Review 스키마에 평균 별점 4.8을 박아뒀는데 페이지에는 별점 위젯이 안 보인다? 패널티 대상이다. Product 스키마에 가격이 50,000원인데 실제 페이지 가격이 다르다? 머천트 정책 위반이다. 우리가 한 번 인계받은 클라이언트는 이전 대행사가 모든 페이지에 일괄 평점 4.9를 박아둬서, Search Console에서 수동 조치 받은 상태였다. 복구하는 데 두 달 가까이 걸렸다.

동적 콘텐츠와 스키마 동기화

가격, 재고, 평점이 자주 바뀌는 사이트라면 스키마도 동적으로 업데이트되게 시스템을 짜야 한다. 정적 HTML에 박아두면 백 퍼센트 불일치 발생한다. WordPress 사이트라면 Yoast나 RankMath, Schema Pro 같은 플러그인이 가격 변경을 자동 반영해주고, 자체 개발 사이트라면 백엔드 API에서 JSON-LD를 동적으로 렌더링하는 구조가 안전하다.

BreadcrumbList – 작지만 강력한 신호

의외로 빼먹는 분들 많은데, BreadcrumbList 스키마는 SEO 효과가 꾸준하다. 검색 결과에 URL 대신 빵부스러기 경로가 표시되면 클릭률이 올라간다. 우리 데이터로는 이거 적용 전후 CTR 차이가 명확하게 나온다.

주의할 점은 itemListElement의 position 번호가 1부터 시작해야 하고, 마지막 항목은 url을 생략하거나 현재 페이지 URL을 넣어야 한다는 것이다. 가끔 마지막에 다른 URL이 들어가서 검색 결과에 엉뚱한 경로가 표시되는 사고가 난다.

Organization과 Person 스키마로 E-E-A-T 강화하기

2026년 E-E-A-T(경험, 전문성, 권위, 신뢰)는 더 이상 추상적 개념이 아니다. 구체적인 시그널로 측정된다. Organization 스키마의 sameAs 필드에 회사 LinkedIn, 위키피디아, 공식 SNS 링크를 박아두는 게 첫걸음이다.

knowsAbout 필드는 2025년경 들어와서 GEO 영역에서 본격적으로 활용된다. 우리 회사가 어떤 주제에 전문성이 있는지를 구조화 데이터로 명시할 수 있다. 예를 들어 마케팅 대행사라면 “Google Ads”, “Search Engine Optimization”, “Performance Marketing” 같은 분야를 박아둘 수 있다.

Author Person 스키마 작성법

Article 스키마의 author에 단순히 이름만 박지 말고, Person 객체를 통째로 중첩시켜야 한다. jobTitle, worksFor, alumniOf, sameAs를 모두 채워두는 게 이상적이다. 의료, 금융, 법률 같은 YMYL(Your Money Your Life) 주제라면 더더욱 필수다. 의사 면허 번호나 변호사 등록 번호 같은 자격증 정보는 hasCredential 필드에 넣을 수 있다.

Search Console에서 스키마 점검하기

스키마 박았으면 끝이 아니다. 지속적으로 모니터링해야 한다. Google Search Console의 “리치 결과” 보고서를 주 1회는 확인하는 게 좋다. 새로운 오류가 발견되면 알림이 오긴 하는데, 우리는 보수적으로 직접 확인하는 편이다.

Rich Results Test 도구(search.google.com/test/rich-results)는 페이지 단위로 즉시 검증할 수 있다. 새 페이지 발행 직전에 한 번 돌려보는 습관을 들이는 게 안전하다. Schema Markup Validator(validator.schema.org)는 구글이 인식하는 리치 결과 종류와 별개로, 스키마 문법 자체의 유효성을 검사한다. 두 도구를 병행하는 게 정확하다.

흔한 실수와 회피 전략

현장에서 자주 보는 실수들을 정리했다.

중복 스키마 문제

WordPress 사이트에서 SEO 플러그인 두 개를 동시에 활성화하면 같은 페이지에 Article 스키마가 두 번씩 박힌다. 구글은 둘 중 하나만 읽거나, 최악의 경우 무시한다. 플러그인 정리부터 해야 한다.

이미지 URL 누락

Article 스키마의 image 필드는 단일 URL이 아니라 배열로 1200픽셀 이상 너비의 이미지 여러 개를 넣는 게 권장된다. 16:9, 4:3, 1:1 비율을 각각 한 장씩 준비해두면 다양한 리치 결과 노출 환경에 대응할 수 있다.

datePublished와 dateModified 혼동

datePublished는 최초 발행일, dateModified는 최종 수정일이다. 두 값을 같게 박아두는 사이트가 많은데, 콘텐츠 업데이트한 경우 dateModified를 갱신해야 검색결과에 “업데이트됨” 신호가 뜬다. ISO 8601 형식(2026-05-25T10:30:00+09:00)을 엄수해야 한다.

가짜 평점 절대 금지

aggregateRating을 임의로 박는 건 명백한 정책 위반이다. 실제 사용자 리뷰 시스템과 연동되지 않은 평점은 빼는 게 낫다. 자체 리뷰 시스템이 없다면 외부 리뷰 플랫폼 위젯을 연동하고, 거기서 가져온 데이터로 스키마를 채우는 방식이 안전하다.

로케이션 페이지 – 양보다 질

지역 타기팅하는 사이트에서 LocalBusiness 스키마를 깔 때 주의해야 할 점이 있다. 도시나 동네별로 페이지를 우후죽순 만들어서 각각 LocalBusiness 스키마를 박는 방식은 지양해야 한다. 30개 넘으면 구글이 의심하기 시작하고, 50개 넘으면 거의 페널티 수준이다.

실제 운영하는 지점이 있는 경우에만 LocationOf 관계로 묶어주고, 단순히 서비스 지역만 표시하고 싶다면 areaServed 필드 하나로 GeoCircle이나 AdministrativeArea 객체를 활용하는 게 깔끔하다.

모바일 우선 스키마 – 2026년 필수 체크

구글은 이미 모바일 인덱싱이 기본이다. 데스크톱과 모바일 페이지에 다른 스키마를 박아두는 사이트가 가끔 있는데, 통일해야 한다. 반응형 사이트라면 자동으로 해결되지만, 모바일 별도 URL(m.example.com)을 운영하는 사이트는 특히 신경 써야 한다.

AMP 페이지를 운영한다면 AMP 페이지와 정규 페이지 둘 다 동일한 스키마를 가져야 한다. 우리는 AMP를 점진적으로 정리하는 방향을 추천하는 편이다. 2024년 이후 AMP의 SEO 이점이 거의 사라졌기 때문이다.

스키마 마크업은 한 번 박고 끝나는 게 아니라, 지속적으로 점검하고 업데이트해야 하는 살아있는 시스템입니다. 2026년 검색 환경은 AI 답변 중심으로 빠르게 재편되고 있고, 스키마는 그 흐름에서 우리 사이트가 인용되기 위한 가장 기본적인 통로다. 한 번 정리해두면 광고비 줄이고 유기적 트래픽으로 매출 만드는 자산이 됩니다.