[2026 최신] 스키마 마크업을 통한 리뷰 구조화 데이터 구현 방법 완벽 가이드 | 테라그로스

구글 검색 결과에서 별점이 노란색으로 반짝이는 사이트, 다들 한 번쯤 부러워하셨을 겁니다. 우리도 처음 대행 맡았던 쇼핑몰 계정에서 리뷰 리치 결과 하나 띄우려고 몇 주를 삽질했던 기억이 나는데요. 솔직히 스키마 마크업 자체는 어렵지 않아요. 문제는 구글이 요구하는 조건이 계속 바뀐다는 것. 2026년 현재 기준으로 리뷰 구조화 데이터를 제대로 구현하는 방법, 실무에서 검증한 내용만 정리해봤습니다.

리뷰 스키마가 2026년에도 여전히 돈이 되는 이유

결론부터 말하면, 리뷰 리치 결과는 아직도 CTR을 올리는 가장 확실한 무료 수단 중 하나예요. 우리가 운영하는 계정 중 한 곳은 제품 상세 페이지에 Review 스키마를 붙인 뒤 4주 만에 검색 노출 대비 클릭률이 3.2%에서 5.1%로 올랐습니다. 순위는 그대로였는데 클릭만 늘어난 거죠. 별점이라는 시각 요소가 같은 위치의 경쟁 결과를 눌러버리는 겁니다.

근데 여기서 오해가 하나 있어요. 스키마를 넣는다고 순위가 오르지는 않습니다. 구글 공식 문서에서도 구조화 데이터는 랭킹 요소가 아니라 검색 결과의 표시 방식을 바꾸는 장치라고 못 박고 있고요. 과거에는 이걸 SEO 순위 치트키처럼 파는 업체들이 있었지만, 지금은 그런 얘기 하는 곳이면 일단 거르시는 게 맞습니다.

2026년 기준으로 달라진 점이 있다면, AI Overviews와 AI 모드가 검색 결과 상단을 차지하면서 일반 파란 링크의 클릭이 전반적으로 줄었다는 것. 그래서 남은 클릭을 가져오려면 리치 결과 같은 시각적 차별화가 오히려 더 중요해졌어요. 구조화 데이터가 잘 정리된 페이지는 AI 답변의 인용 소스로 선택될 확률도 체감상 높습니다.

Review와 AggregateRating, 뭐가 다르고 언제 쓰나

실무에서 제일 많이 헷갈리는 부분이 이겁니다. 둘 다 별점을 띄우는 스키마인데 용도가 달라요.

Review – 개별 리뷰 하나

특정 리뷰어 한 명이 남긴 평가를 마크업합니다. 리뷰어 이름, 별점, 리뷰 본문이 들어가고요. 에디터 리뷰나 전문가 평가 콘텐츠에 적합합니다. 예를 들어 우리가 특정 마케팅 툴을 직접 써보고 평가하는 글이라면 Review 스키마가 맞아요.

AggregateRating – 여러 리뷰의 집계

평균 별점과 리뷰 개수를 함께 표시합니다. ratingValue, reviewCount(또는 ratingCount), bestRating 속성이 핵심이고, 쇼핑몰 상품 페이지처럼 고객 리뷰가 쌓이는 곳이라면 이쪽입니다. 검색 결과에 “4.6점, 리뷰 128개” 형태로 뜨는 게 바로 이 스키마예요.

둘 중 하나만 골라야 하는 건 아니고, 상품 페이지라면 AggregateRating과 대표 Review 몇 개를 같이 넣는 구성이 일반적입니다. 구글 문서상 두 속성 모두 Product, LocalBusiness 같은 상위 타입 안에 중첩시키는 방식을 권장하고요.

구글이 리뷰 별점을 안 보여주는 3가지 대표 케이스

이게 진짜 중요한 파트인데, 스키마를 완벽하게 짜도 별점이 안 뜨는 경우가 있습니다. 우리한테 들어오는 문의의 절반이 “마크업 다 했는데 왜 안 나오냐”거든요. 원인은 대부분 아래 셋 중 하나였습니다.

셀프 서빙 리뷰 – 자기가 자기를 평가

구글은 조직이 자기 자신에 대해 붙인 리뷰 마크업을 리치 결과에서 제외합니다. LocalBusiness나 Organization 타입 홈페이지에 자사 별점을 박아넣는 것, 이게 대표적인 셀프 서빙이에요. 과거에는 이 방법으로 홈페이지에 별점 띄우는 게 유행이었지만 2019년 정책 변경 이후로는 막혔고, 2026년 지금은 시도 자체가 스팸 시그널이 될 수 있습니다. 별점은 제3자가 상품이나 콘텐츠를 평가한 페이지에만 붙인다고 생각하시면 편해요.

보이지 않는 콘텐츠 마크업

페이지에 실제로 표시되지 않는 리뷰를 스키마에만 넣는 경우입니다. 구조화 데이터의 대원칙이 “사용자가 눈으로 보는 내용과 일치할 것”인데, 이걸 어기면 수동 조치 대상이 됩니다. 실제로 인수받은 계정 중에 이 문제로 Search Console에 구조화 데이터 스팸 경고가 떠 있던 곳이 있었어요. 해제까지 재심사 요청 포함 3주 걸렸습니다. 페이지에 없는 건 스키마에도 넣지 마세요.

리뷰 대상이 지원 타입이 아님

리뷰 리치 결과가 뜨는 타입은 정해져 있습니다. Book, Course, Event, LocalBusiness, Movie, Product, Recipe, SoftwareApplication 정도가 지원 대상이고요. Article이나 일반 WebPage에 리뷰 스키마를 붙이면 오류는 안 나지만 별점도 안 뜹니다. 이거 모르고 블로그 글마다 별점 스키마 넣는 사이트, 지금도 종종 봅니다.

JSON-LD로 구현하는 실전 코드 – 상품 리뷰 기준

구현 형식은 JSON-LD 하나로 통일하세요. 마이크로데이터나 RDFa도 기술적으로는 유효하지만, 구글이 공식 문서에서 일관되게 JSON-LD를 권장하고 있고 유지보수도 압도적으로 편합니다. HTML 구조를 건드리지 않고 head나 body 어디든 script 블록 하나로 끝나니까요.

쇼핑몰 상품 페이지 기준으로 실무에서 쓰는 뼈대는 이렇습니다.

워드프레스라면 우커머스가 리뷰 스키마를 기본으로 출력해주긴 하는데, 테마나 플러그인이 중복 스키마를 뿌리는 경우가 많습니다. 한 페이지에 Product 스키마가 두 벌 출력되면 구글이 어느 쪽을 신뢰할지 애매해지거든요. Rank Math나 Yoast 쓰시면 테마 쪽 스키마 출력을 꺼주는 정리 작업부터 하시는 걸 추천합니다.

배포 전 검증 – 리치 결과 테스트와 Search Console 활용법

코드 짰으면 바로 배포하지 말고 두 단계 검증을 거치세요. 우리 내부 프로세스도 이 순서로 고정돼 있습니다.

첫 번째는 구글 리치 결과 테스트(Rich Results Test)입니다. URL이나 코드 조각을 넣으면 해당 페이지가 어떤 리치 결과 대상인지, 오류와 경고가 뭔지 바로 보여줘요. 여기서 “경고”는 무시해도 표시는 되지만, 채울 수 있으면 채우는 게 좋습니다. 경고 항목이 적을수록 리치 결과 안정성이 높다는 게 우리 경험이고요.

두 번째는 배포 후 Search Console의 리뷰 스니펫 보고서 모니터링. 페이지가 크롤링되면 “리뷰 스니펫” 항목에 유효 페이지와 오류 페이지가 집계됩니다. 배포 직후엔 반영이 안 되니 조급해하지 마시고요. 보통 재크롤링까지 며칠에서 2주 정도 걸렸습니다. 급하면 URL 검사 도구에서 색인 재요청을 걸어두면 빨라져요.

사실 검증보다 중요한 건 지속 관리입니다. 상품이 품절되거나 리뷰 위젯 플러그인이 업데이트되면서 스키마 출력이 조용히 깨지는 일이 생각보다 잦아요. 우리는 월 1회 주요 템플릿 URL을 리치 결과 테스트에 돌리는 걸 운영 루틴으로 잡아놨습니다.

AI 검색 시대의 리뷰 스키마 – 별점 그 이상의 역할

2026년 들어 체감하는 변화인데, 구조화 데이터의 역할이 리치 결과 표시를 넘어서고 있습니다. 구글의 AI 기반 검색 경험이 페이지 내용을 이해할 때 구조화 데이터가 명확한 신호로 작동하거든요. 리뷰 개수, 평균 평점, 가격 같은 정형 정보가 마크업으로 정리된 페이지는 AI가 쇼핑 관련 답변을 구성할 때 인용하기 좋은 소스가 됩니다.

특히 상품 데이터는 머천트 센터 피드와 페이지 스키마가 일치하는지가 중요해졌어요. 구글 쇼핑 그래프가 웹 페이지 스키마를 함께 읽기 때문에, 피드에는 4.8점인데 페이지 스키마에는 4.2점이면 신뢰도가 깎입니다. 광고 쪽에서 쇼핑 캠페인 돌리는 사이트라면 이 정합성 점검은 필수라고 보시면 되고요.

그리고 리뷰 콘텐츠 자체의 품질도 같이 봐야 합니다. 구글의 리뷰 시스템 업데이트가 계속 돌고 있어서, 실사용 경험 없이 쓴 복붙형 리뷰가 잔뜩 마크업된 페이지는 스키마가 아무리 깔끔해도 평가가 낮아요. 마크업은 포장이고 내용물은 리뷰 그 자체라는 것, 순서를 헷갈리면 안 됩니다.

실무 체크리스트 – 배포 전에 이것만 확인하자

지금까지 내용을 실무 순서로 압축하면 이렇습니다. 우리가 신규 계정 온보딩 때 실제로 돌리는 체크 항목이에요.

먼저 리뷰 대상 타입이 지원 목록에 있는지 확인합니다. Product, LocalBusiness, Recipe 등 지원 타입이 아니면 시작할 필요가 없어요. 다음으로 셀프 서빙 여부 점검. 자기 사이트가 자기를 평가하는 구조면 그 마크업은 빼야 합니다. 세 번째로 페이지 표시 콘텐츠와 스키마 데이터의 일치 여부. 화면에 보이는 별점, 리뷰 수와 스키마 값이 다르면 안 됩니다.

구현은 JSON-LD로, bestRating 명시하고, author는 문자열이 아니라 Person이나 Organization 타입 객체로 넣으세요. 이거 문자열로 넣으면 경고 뜹니다. 배포 전 리치 결과 테스트, 배포 후 Search Console 리뷰 스니펫 보고서 확인까지 마치면 1차 사이클 완료. 이후엔 월 단위로 깨진 곳 없는지 돌아보는 운영만 남습니다.

근데 솔직히 여기까지 읽고 “우리 사이트에 지금 당장 적용 가능한가?”를 판단하기 어려운 분이 더 많을 거예요. CMS 구조, 플러그인 충돌, 기존 스키마 중복 문제는 사이트마다 다 다르거든요. 그럴 땐 전체 구조를 한 번 진단받고 시작하는 게 시행착오 비용을 아끼는 길입니다.