스키마 마크업: 검색엔진이 콘텐츠를 이해하는 구조화된 데이터

스키마 마크업(Schema Markup)은 웹페이지의 콘텐츠를 검색엔진이 정확히 이해할 수 있도록 구조화된 데이터를 제공하는 기술이다. schema.org 표준 어휘를 사용하여 페이지의 내용을 기계가 읽을 수 있는 형태로 표현하며, 이를 통해 Google 검색 결과에서 리치 결과(Rich Results)를 얻을 수 있다. 별점, 가격, FAQ 아코디언 등 눈에 띄는 검색 결과 형태가 바로 스키마 마크업의 결과물이다.

스키마 마크업을 구현하기 전에 파악해야 할 것들

스키마 마크업을 적용하기 전에 세 가지를 먼저 파악해야 한다. 첫째, 페이지 유형이다. 이 페이지가 블로그 글인지, 제품 페이지인지, FAQ 페이지인지에 따라 적용할 스키마 타입이 달라진다. 둘째, 현재 상태를 점검해야 한다. 이미 적용된 스키마가 있는지, 구현에 오류가 있는지, 어떤 리치 결과가 이미 표시되고 있는지 확인한다. 셋째, 목표를 명확히 해야 한다. 어떤 리치 결과를 노리는지, 그것이 비즈니스에 어떤 가치를 가져오는지 정리해둔다.

핵심 원칙 네 가지

정확성이 최우선이다

스키마 마크업은 반드시 페이지에 실제로 존재하는 콘텐츠를 정확히 반영해야 한다. 페이지에 없는 내용을 마크업하면 안 되며, 콘텐츠가 변경되면 스키마도 함께 업데이트해야 한다. Google은 페이지 내용과 스키마가 일치하지 않으면 리치 결과를 제거하거나 페널티를 줄 수 있다.

JSON-LD 포맷을 사용한다

Google이 공식 권장하는 포맷은 JSON-LD(JavaScript Object Notation for Linked Data)이다. HTML 내에 인라인으로 넣는 Microdata나 RDFa에 비해 구현과 유지보수가 훨씬 쉽다. HTML의 head 태그 안이나 body 태그 끝에 script 태그로 삽입하면 된다.

Google 가이드라인을 따른다

Google이 실제로 지원하는 마크업만 사용해야 한다. 스팸성 전술은 피해야 하며, 각 스키마 타입별 자격 요건을 반드시 확인해야 한다. Google의 구조화된 데이터 문서에서 지원 여부와 필수 속성을 확인할 수 있다.

반드시 검증한다

배포 전에 반드시 테스트해야 하고, Search Console의 개선사항 보고서를 지속적으로 모니터링해야 한다. 오류가 발견되면 즉시 수정하는 것이 중요하다. 검증 없이 배포하면 의도치 않은 오류로 리치 결과를 잃을 수 있다.

자주 사용하는 스키마 타입

주요 스키마 타입별 상세 안내

Organization: 회사/브랜드 페이지

조직(Organization) 스키마는 회사 홈페이지나 소개 페이지에 적용한다. 필수 속성은 name(회사명)과 url(웹사이트 주소)이며, 권장 속성으로 logo(로고 이미지 URL), sameAs(소셜 미디어 프로필 URL 배열), contactPoint(고객 서비스 연락처) 등이 있다. sameAs에는 Twitter, LinkedIn, Facebook 등 공식 소셜 계정 URL을 배열로 넣으면 Google이 브랜드 프로필을 통합해서 인식한다.

WebSite: 홈페이지와 사이트링크 검색 박스

웹사이트(WebSite) 스키마는 홈페이지에 적용하여 사이트링크 검색 박스(Sitelinks Search Box)를 활성화할 수 있다. name과 url이 필수이며, potentialAction으로 SearchAction을 정의하면 된다. SearchAction 안에 EntryPoint 타입으로 urlTemplate을 지정하고, query-input에 검색어 파라미터명을 설정한다. 이렇게 하면 Google 검색 결과에서 사이트 내 검색 박스가 직접 표시된다.

Article과 BlogPosting: 블로그와 뉴스

기사(Article) 또는 블로그 포스팅(BlogPosting) 스키마는 블로그 글과 뉴스 기사에 적용한다. 필수 속성은 headline(제목), image(대표 이미지), datePublished(발행일, ISO 8601 형식), author(저자 정보)이다. 권장 속성으로 dateModified(수정일), publisher(발행자 조직 정보), description(요약), mainEntityOfPage(해당 웹페이지 ID)가 있다. author에는 Person 타입으로 name과 url을, publisher에는 Organization 타입으로 name과 logo를 포함한다.

Product: 제품 페이지

제품(Product) 스키마는 이커머스나 SaaS 제품 페이지에 적용한다. 필수 속성은 name(제품명), image(제품 이미지), offers(가격 및 재고 정보)이다. offers 안에는 Offer 타입으로 priceCurrency(통화), price(가격), availability(재고 상태, schema.org의 InStock 등 열거값 사용)를 넣는다. 권장 속성으로 sku(제품 코드), brand(Brand 타입), aggregateRating(평균 별점과 리뷰 수)이 있어 검색 결과에 별점과 가격이 표시되는 리치 스니펫을 만들 수 있다.

SoftwareApplication: SaaS 및 앱 페이지

소프트웨어 애플리케이션(SoftwareApplication) 스키마는 SaaS 제품이나 앱 랜딩 페이지에 적용한다. name과 offers가 필수이며, applicationCategory(예: BusinessApplication), operatingSystem(예: Web, iOS, Android)을 추가하면 더 풍부한 정보를 제공할 수 있다. 무료 앱이라면 offers의 price를 "0"으로 설정한다. aggregateRating으로 별점과 평가 수를 포함하면 검색 결과에서 눈에 띄게 된다.

FAQPage: 자주 묻는 질문

FAQ 페이지(FAQPage) 스키마는 자주 묻는 질문 콘텐츠에 적용한다. 필수 속성은 mainEntity 하나뿐이며, 이 안에 Question 타입 객체들의 배열을 넣는다. 각 Question에는 name(질문 텍스트)과 acceptedAnswer(Answer 타입, text 속성에 답변 텍스트)를 포함한다. 이 스키마를 적용하면 Google 검색 결과에서 질문-답변 아코디언이 바로 펼쳐지는 형태로 표시되어 클릭률을 크게 높일 수 있다.

HowTo: 튜토리얼과 가이드

사용법(HowTo) 스키마는 단계별 안내 콘텐츠에 적용한다. name(제목)과 step(단계 배열)이 필수이며, description(설명)과 totalTime(소요 시간, ISO 8601 기간 형식 예: PT15M)을 추가할 수 있다. step 배열 안에는 HowToStep 타입으로 각 단계의 name(단계명), text(상세 설명), url(해당 단계 링크)을 넣는다. Google 검색 결과에서 단계별로 펼쳐지는 리치 결과가 표시된다.

BreadcrumbList: 브레드크럼 내비게이션

브레드크럼(BreadcrumbList) 스키마는 브레드크럼 내비게이션이 있는 모든 페이지에 적용할 수 있다. itemListElement 배열이 필수이며, 각 항목은 ListItem 타입으로 position(순서 번호, 1부터 시작), name(표시 이름), item(해당 페이지 URL)을 포함한다. 예를 들어 "홈 > 블로그 > SEO 가이드" 경로라면 세 개의 ListItem을 순서대로 넣으면 된다. 브레드크럼 마크업은 검색 결과의 URL 부분에 경로 구조로 표시되어 사용자가 사이트 구조를 직관적으로 파악할 수 있게 한다.

LocalBusiness: 지역 사업장

지역 비즈니스(LocalBusiness) 스키마는 실제 매장이나 사무실이 있는 지역 사업장 페이지에 적용한다. name과 address(PostalAddress 타입)가 필수이며, geo(GeoCoordinates 타입으로 위도/경도), telephone(전화번호), openingHoursSpecification(영업시간), priceRange(가격대) 등을 추가할 수 있다. 영업시간은 OpeningHoursSpecification 타입으로 dayOfWeek(요일 배열), opens(오픈 시간), closes(마감 시간)를 지정한다.

Event: 이벤트와 웨비나

이벤트(Event) 스키마는 행사, 웨비나, 컨퍼런스 페이지에 적용한다. 필수 속성은 name(이벤트명), startDate(시작 일시), location(장소)이다. 온라인 이벤트라면 eventAttendanceMode를 OnlineEventAttendanceMode로 설정하고 location을 VirtualLocation 타입으로 지정한다. eventStatus(EventScheduled 등), endDate(종료 일시), offers(티켓 정보), performer(연사), organizer(주최자) 등을 추가하면 더 풍부한 리치 결과를 얻을 수 있다.

하나의 페이지에 여러 스키마 결합하기

하나의 페이지에 여러 스키마 타입을 동시에 적용할 수 있다. 이때 @graph 속성을 사용한다. JSON-LD 최상위에 @context로 schema.org를 지정하고, @graph 배열 안에 각 스키마 객체를 나란히 넣으면 된다. 예를 들어 회사 홈페이지라면 Organization, WebSite, BreadcrumbList를 하나의 @graph에 함께 포함할 수 있다.

각 스키마 객체에 @id를 부여하면 객체 간 참조가 가능해진다. 예를 들어 WebSite의 publisher 속성에서 Organization의 @id를 참조하면, 두 스키마가 연결되어 검색엔진이 관계를 명확히 이해한다.

검증 및 테스트 도구

스키마 마크업을 배포하기 전에 반드시 검증 도구로 테스트해야 한다. Google 리치 결과 테스트(Rich Results Test)는 Google이 실제로 인식하는 리치 결과 자격을 확인해주며, schema.org 검증기(Validator)는 문법적 정확성을 검사한다. Google Search Console의 개선사항(Enhancements) 보고서에서는 사이트 전체의 스키마 상태를 모니터링할 수 있다.

자주 발생하는 오류와 해결

필수 속성 누락은 가장 흔한 오류다. Google 문서에서 각 스키마 타입의 필수 필드를 반드시 확인해야 한다. 값 형식 오류도 자주 발생하는데, 날짜는 반드시 ISO 8601 형식이어야 하고, URL은 완전한 형태(fully qualified)여야 하며, 열거형 값은 정확히 일치해야 한다. 또한 스키마 내용이 실제 페이지 콘텐츠와 일치하지 않으면 Google이 리치 결과를 거부하므로, 마크업과 화면에 보이는 내용 사이의 일관성을 유지하는 것이 중요하다.

기술 스택별 구현 방법

정적 사이트

정적 사이트에서는 HTML 템플릿에 JSON-LD를 직접 삽입한다. 재사용 가능한 스키마 조각은 인클루드(include)나 파셜(partial)로 분리하면 유지보수가 편해진다. 매 페이지 빌드 시 자동으로 포함되므로 별도의 런타임 처리가 필요 없다.

동적 사이트 (React, Next.js)

React나 Next.js 같은 동적 사이트에서는 스키마를 렌더링하는 전용 컴포넌트를 만든다. 이 컴포넌트는 페이지 데이터를 받아 JSON-LD 객체를 생성하고, script 태그로 HTML head에 삽입한다. SEO를 위해 반드시 서버 사이드 렌더링(SSR)으로 처리해야 하며, Next.js의 경우 Head 컴포넌트 안에 type이 "application/ld+json"인 script 태그를 넣고 데이터를 JSON.stringify로 직렬화하는 방식이 일반적이다.

CMS 및 WordPress

WordPress 같은 CMS에서는 Yoast, Rank Math, Schema Pro 같은 플러그인을 활용하면 코드 없이 스키마를 관리할 수 있다. 플러그인이 제공하지 않는 커스텀 스키마가 필요하면 테마 수정이나 커스텀 필드를 통해 구조화된 데이터를 추가할 수 있다. 플러그인 간 중복 스키마가 생기지 않도록 주의해야 한다.

배포 전 확인 사항

스키마 마크업을 배포하기 전에 다음 네 가지를 반드시 확인해야 한다. 첫째, 리치 결과 테스트를 통과하는지 검증한다. 둘째, 오류(error)나 경고(warning)가 없는지 확인한다. 셋째, 스키마 내용이 실제 페이지 콘텐츠와 정확히 일치하는지 대조한다. 넷째, 해당 스키마 타입의 필수 속성이 모두 포함되어 있는지 점검한다.

스키마 마크업은 한 번 구현하고 끝나는 것이 아니다. 콘텐츠가 변경될 때마다 스키마도 함께 업데이트해야 하며, Search Console을 통해 지속적으로 상태를 모니터링하는 것이 리치 결과를 안정적으로 유지하는 핵심이다.