리뷰 스키마 마크업 완벽 가이드 | 이루웹

결론부터 말하면 이렇다. 검색결과에 별점과 리뷰 개수를 노출시키는 것은 리뷰 위젯이 아니라 그 아래 깔린 Review·AggregateRating 구조화 데이터다. 위젯이 화면에 후기를 예쁘게 보여줘도, 코드에 이 두 스키마가 정확히 들어가 있지 않으면 구글은 그 정보를 별점으로 읽지 못한다.

문제는 이 두 타입을 다루는 실무 정보가 흩어져 있다는 점이다. 필수 속성이 무엇인지, 내 상품에 내 리뷰를 달아도 되는지, 왜 위젯을 붙였는데도 별점이 안 뜨는지가 각기 다른 글·커뮤니티 답변에 조각조각 흩어져 있다.

이 글은 Review와 AggregateRating의 필수·권장 속성부터 자사 리뷰 마크업 규정, 서치 콘솔에서 자주 보이는 오류 해석, 리치 결과 테스트로 검증하는 법, AI 검색에서의 활용까지 한 곳에 정리한다. 모든 내용은 구글 공식 개발자 문서 기준으로 다시 확인했다.

이커머스 운영자뿐 아니라 서비스업 홈페이지 운영자도 이 글이 필요하다. 상품이 아니라 서비스를 판매하더라도, 상담 후기·시공 후기·이용 후기를 페이지에 쌓고 있다면 똑같은 원리가 적용된다. 다만 무엇을 평가 대상으로 삼느냐에 따라 규정이 달라지므로, 이 차이를 정확히 아는 것이 이 글의 핵심 목적 가운데 하나다.

이 글의 핵심은 다음과 같다.

• Review는 개별 후기 하나, AggregateRating은 여러 후기를 합산한 평균 평점이다 — 역할이 다르다.
• Review 필수 속성은 author·reviewRating, AggregateRating 필수 속성은 ratingValue와 ratingCount(또는 reviewCount) 중 하나다.
• 상품(Product) 리뷰는 자사 페이지에 달아도 되지만, 회사·매장 자체(LocalBusiness·Organization) 평점을 자사 사이트에 직접 넣으면 리치 결과 자격을 잃는다.
• 위젯을 달고도 별점이 안 뜨는 가장 흔한 원인은 지연 로딩(lazy load)으로 구조화 데이터가 빈 값으로 나가는 문제다.
• 발행 전 리치 결과 테스트로 오류·경고 없이 인식되는지 반드시 확인해야 한다.

리뷰 스키마(Review·AggregateRating)란 정확히 무엇인가

리뷰 스키마는 사용자가 남긴 후기와 평점을 검색엔진이 읽을 수 있는 코드로 구조화한 구조화 데이터다. 스키마닷오알지(schema.org)가 정의한 Review와 AggregateRating이라는 두 타입을 <script type="application/ld+json"> 형식으로 페이지에 심는 방식이 구글이 공식 권장하는 형식이다.

이 코드가 있다고 해서 화면 디자인이 바뀌지는 않는다. 검색결과 화면에서 파란 제목 아래 노란 별점과 리뷰 개수가 뜨는 것, 그 리치 결과의 재료가 되는 것이 바로 이 마크업이다. 화면에 후기가 보이는 것과 그 후기가 구조화 데이터로 표현되는 것은 완전히 다른 작업임을 먼저 이해해야 한다.

화면에는 별 다섯 개가 예쁘게 떠 있어도, 페이지 소스에 Review·AggregateRating 코드가 없으면 구글 입장에서는 그냥 이미지와 텍스트 덩어리일 뿐이다.

리뷰 스키마는 Book, Course, Event, LocalBusiness, Movie, Product, Recipe, SoftwareApp 등 다양한 콘텐츠 타입에 사용할 수 있다. 이 글은 이 가운데 실무 문의가 가장 많은 이커머스 상품(Product)과 서비스업 홈페이지 관점에 초점을 맞춘다.

Review와 AggregateRating, 언제 뭘 써야 하나

둘은 역할이 다르다. Review는 "누가, 무엇에 대해, 몇 점을 줬다"는 개별 후기 하나를 담는 타입이고, AggregateRating은 그 후기들을 모은 평균 평점과 개수를 담는 타입이다.

실무에서 가장 흔한 선택은 다음과 같다.

상황	사용할 타입
개별 후기 텍스트를 페이지에 노출한다	Review (필요하면 AggregateRating도 함께)
후기 텍스트 없이 평균 평점·개수만 보여준다	AggregateRating 단독
여러 개별 후기를 나열하며 평균도 보여준다	Review 여러 개 + AggregateRating 하나

구글 공식 문서는 여러 개별 리뷰를 마크업한다면 그 리뷰들을 합산한 AggregateRating도 함께 넣으라고 권장한다. 반대로 개별 후기 텍스트가 없고 "4.7점, 리뷰 128개"라는 요약 정보만 있다면 AggregateRating만 단독으로 써도 된다 — 이 경우는 실무에서 매우 흔한 패턴이다.

주의할 점 하나. 화면에 보이지 않는 리뷰를 마크업해서는 안 된다. 구글은 "마크업한 리뷰 내용은 해당 페이지에서 사용자에게 곧바로 확인 가능해야 한다"고 명시한다. 코드에만 존재하고 화면 어디에도 보이지 않는 리뷰는 정책 위반이다.

Review에 꼭 넣어야 하는 속성은 무엇인가

Review 타입의 필수 속성은 author와 reviewRating 두 가지다. 나머지는 상황에 따라 생략하거나 추가한다.

속성	필수 여부	설명
author	필수	작성자(Person 또는 Organization). 이름은 유효한 이름이어야 하며 100자를 넘을 수 없다
reviewRating	필수	Rating 객체. 그 안에 ratingValue가 실제 평가 점수
itemReviewed	조건부 필수	리뷰가 다른 스키마(Product 등) 안에 중첩돼 있지 않다면 반드시 넣어야 한다
datePublished	권장	ISO 8601 형식 날짜(예: 2026-09-10)
reviewBody	권장	실제 후기 본문 텍스트

author를 "익명" 같은 모호한 값으로 채우면 안 된다. 실제 작성자를 특정할 수 있는 이름이어야 하며, 리뷰 시스템에서 닉네임을 쓴다면 그 닉네임을 그대로 넣는 것이 안전하다.

itemReviewed는 헷갈리는 부분이다. Product 페이지 안에서 review 필드로 리뷰를 중첩해 넣었다면 itemReviewed를 또 넣을 필요가 없다 — 이미 부모 객체가 무엇인지 알기 때문이다. 반대로 리뷰만 독립적으로 마크업한다면 itemReviewed에 무엇을 평가한 리뷰인지 명시해야 한다.

AggregateRating에 꼭 넣어야 하는 속성은 무엇인가

AggregateRating의 필수 속성은 ratingValue, 그리고 ratingCount 또는 reviewCount 중 최소 하나다. 평점만 있고 몇 명이 매겼는지 없는 마크업은 불완전한 것으로 처리된다.

속성	필수 여부	설명
ratingValue	필수	평균 평점(숫자·분수·백분율 가능)
ratingCount	둘 중 하나 필수	평점을 매긴 사람 수
reviewCount	둘 중 하나 필수	작성된 리뷰 개수
itemReviewed	조건부 필수	상위 객체에 중첩되지 않았다면 필수
bestRating·worstRating	권장	척도 범위. 생략하면 기본값 5점 만점·1점 최저로 해석

숫자 표기에서 실수가 잦다. 소수점은 반드시 마침표로 써야 한다. 예를 들어 4.4처럼 써야 하고, 쉼표를 넣은 4,4는 잘못된 값으로 처리된다. 한국어 콘텐츠에서는 소수점에 쉼표를 쓸 일이 드물지만, 다국어 쇼핑몰이나 엑셀에서 값을 복사해 붙여넣을 때 이 실수가 종종 나온다.

ratingValue가 5점 만점이 아니라 100점 만점이나 10점 만점 체계라면 bestRating과 worstRating을 명시적으로 넣어야 한다. 생략하면 구글은 기본값인 5점 만점으로 해석하므로, 실제로는 "10점 만점에 8.5점"인데 표기하지 않으면 엉뚱하게 "5점 만점에 8.5점"으로 오해될 수 있다.

권장 속성까지 채우면 무엇이 달라지나

필수 속성만 채워도 마크업 자체는 유효하지만, 권장 속성을 함께 채우면 리치 결과의 완성도와 신뢰도가 올라간다. 대표적으로 datePublished를 넣으면 최신 리뷰인지 오래된 리뷰인지 구분할 근거가 생긴다.

reviewBody(후기 본문)를 함께 마크업하면 AI 검색이 "이 상품을 산 사람들이 실제로 뭐라고 했는가"를 인용할 때 더 구체적인 문장을 가져갈 수 있다. 평점 숫자만 있는 것과 "배송이 빠르고 포장이 꼼꼼했다"는 실제 문장이 있는 것은 AI 인용 관점에서 완전히 다른 재료다.

필수 속성은 "마크업이 깨지지 않기 위한 최소 조건"이고, 권장 속성은 "그 마크업이 실제로 쓸모 있어지는 조건"이라고 이해하면 정확하다.

이미지 관련 속성도 챙길 만하다. 리뷰에 첨부 사진이 있다면 image 속성으로 함께 넣을 수 있다. 다만 리치 결과 화면에 이미지가 직접 노출되는지는 콘텐츠 타입과 노출 지면에 따라 달라지므로, 사진을 넣었다고 반드시 화면에 뜨는 것은 아니라는 점은 감안해야 한다.

전환율 관점에서도 권장 속성은 의미가 있다. 검색결과 단계에서부터 "리뷰 128개, 4.7점"이라는 구체적인 숫자가 보이면, 클릭 전에 이미 신뢰가 어느 정도 형성된 상태로 유입된다. 반대로 필수 속성만 겨우 채운 "리뷰 3개, 5.0점"은 오히려 신뢰도를 낮춰 보일 수 있으므로, 리뷰 수가 어느 정도 쌓인 뒤 마크업을 적용하는 편이 실무적으로 유리하다.

내 상품에 달린 내 리뷰, 마크업해도 되나

된다. 다만 무엇을 평가하는 리뷰인지에 따라 규정이 완전히 갈린다. 상품(Product) 리뷰는 자사 판매 페이지에 마크업해도 문제가 없다. 반면 회사나 매장 자체(LocalBusiness·Organization)에 대한 평점을 자사 사이트에 직접 넣으면 리치 결과 자격을 잃는다.

구글은 2019년 리뷰 리치 결과 정책을 개편하면서 평가 대상이 스스로 자기 평점을 통제하는 경우를 자체 평가(self-serving review)로 규정하고 제외했다. "이 회사 평점 4.9점"처럼 회사 전체를 자기 사이트에서 스스로 매기면 안 되지만, "이 원피스 리뷰 128개, 평균 4.7점"처럼 개별 상품에 대한 리뷰는 자사 페이지에 있어도 정상 노출 대상이다.

스키마 유형	자사 페이지에 마크업	리치 결과 자격
Product(개별 상품)	가능	정상 노출
LocalBusiness·Organization(회사·매장 전체)	코드는 넣을 수 있으나	리치 결과 제외

이 제한은 서드파티 위젯을 통해 넣은 경우에도 그대로 적용된다. "우리 위젯이 자동으로 스키마를 넣어준다"는 안내만 믿고 매장 전체 평점을 자사 홈페이지에 노출시키면, 코드가 문법적으로 완벽해도 리치 결과에서 제외된다. 이 부분은 위젯 자체보다 어떤 대상을 평가하는 리뷰인지가 기준이라는 점을 알아야 실수를 줄일 수 있다.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "OO 무선 이어폰",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.7",
    "reviewCount": "128"
  }
}

위 예시처럼 평가 대상을 회사가 아니라 개별 상품으로 좁히는 것이 자사 페이지에서 안전하게 별점을 노출시키는 핵심 원칙이다. 매장 전체 평판을 보여주고 싶다면 자사 사이트 대신 구글 비즈니스 프로필이나 네이버 지도 리뷰처럼 제3자 플랫폼에 쌓인 평판을 활용하는 편이 규정에 맞는다. 이 주제는 이커머스 리뷰 위젯과 검색 신뢰도의 관계를 다룬 리뷰 위젯이 SEO에 실제로 도움되는지 정리한 글에서 좀 더 자세히 다뤘다.

위젯을 쓰는데도 왜 별점이 검색에 안 뜨나

가장 흔한 원인은 지연 로딩(lazy load)이다. 리뷰 위젯이 페이지가 어느 정도 스크롤되거나 사용자가 상호작용해야 리뷰 데이터를 불러오도록 설계돼 있으면, 구글이 페이지를 렌더링하는 시점에 아직 리뷰 데이터가 없는 빈 스키마만 보게 된다.

두 번째 원인은 테마 커스터마이징 과정에서 위젯 코드가 통째로 빠지는 경우다. 쇼핑몰 플랫폼에서 디자인을 바꾸거나 다른 테마로 이전하면서 위젯은 화면에 그대로 남아 있는데, 그 위젯이 내보내던 구조화 데이터 스크립트만 함께 사라지는 사례가 실무에서 자주 발견된다.

화면 확인만으로는 이 문제를 발견할 수 없다. 브라우저에서 페이지 소스를 열어 application/ld+json 스크립트 안에 실제 숫자가 들어 있는지 직접 확인해야 한다.

세 번째는 리뷰 개수가 너무 적거나 플랫폼 기본 설정에서 구조화 데이터 삽입 옵션이 꺼져 있는 경우다. 크리마·요트포(Yotpo) 같은 국내외 리뷰 위젯 대부분은 관리자 설정에 "검색엔진 구조화 데이터 자동 삽입" 같은 옵션을 따로 두고 있으므로, 위젯 설치만으로 끝내지 말고 이 옵션이 켜져 있는지 확인하는 순서가 필요하다.

실무에서 자주 마주치는 사례를 하나 들면 이렇다. 한 쇼핑몰이 위젯을 새 테마로 옮기면서 리뷰 목록 UI는 그대로 잘 보였지만, 개발자 도구로 페이지 소스를 열어보니 aggregateRating 스크립트 블록 자체가 통째로 빠져 있었다. 화면 테스트만으로는 이런 문제를 절대 잡아낼 수 없고, 반드시 소스 코드나 리치 결과 테스트로 직접 확인해야 하는 이유가 여기에 있다. 이런 경우 위젯 설정을 다시 저장하거나, 테마 코드에 스니펫을 수동으로 재삽입하는 방식으로 복구한다.

가짜 리뷰·인센티브 리뷰는 어디까지 괜찮은가

실제 경험에 기반하지 않은 리뷰나, 대가를 받았다는 사실을 명확히 알리지 않은 리뷰를 마크업에 포함하면 안 된다. 구글 공식 가이드라인은 이 부분을 구체적으로 짚는다 — 상품이나 서비스를 실제로 써보지 않고 작성된 리뷰, 그리고 금전·할인·무료 제품 같은 대가를 받았으면서 그 사실을 눈에 띄게 밝히지 않은 리뷰는 둘 다 허용되지 않는다.

리뷰 이벤트나 체험단 운영 자체가 문제는 아니다. "체험단으로 제공받아 작성한 후기입니다"처럼 대가 관계를 명확히 표시하기만 하면 정상적인 리뷰 운영 방식이다. 실제로 국내외 이커머스 대부분이 이런 방식의 리뷰 이벤트를 운영하고 있고, 이는 리뷰 수집의 일반적인 관행이다.

한 가지 더 짚을 규정이 있다. 다른 웹사이트에 쌓인 리뷰나 평점을 긁어와 자사 스키마에 합산해서는 안 된다. 예를 들어 오픈마켓이나 다른 쇼핑몰에 달린 리뷰를 그대로 가져와 자사 사이트의 aggregateRating에 포함시키는 방식은 정책 위반이다. 마크업하는 리뷰는 반드시 해당 페이지에서 실제로 수집·관리하는 리뷰여야 한다.

서치 콘솔에서 자주 보는 오류는 무엇을 뜻하나

발행 후 구글 서치 콘솔의 "리뷰 스니펫" 보고서를 열어보면 몇 가지 오류·경고가 반복적으로 나타난다. 미리 뜻을 알아두면 당황하지 않는다.

메시지	의미	대응
필드 누락 "itemReviewed"	리뷰가 무엇을 평가하는지 명시가 안 됨	독립 마크업이면 itemReviewed 추가, 중첩이면 상위 구조 확인
"itemReviewed" 필드의 개체 유형이 잘못됨	itemReviewed에 넣은 값의 @type이 부적절	Product·LocalBusiness 등 올바른 타입으로 수정
offers, review, aggregateRating 중 하나가 지정돼야 함	Product 스키마에 가격·리뷰·평점 정보가 전부 없음	셋 중 최소 하나는 반드시 포함
평점 값 형식 오류	ratingValue가 숫자가 아니거나 범위를 벗어남	bestRating·worstRating 범위 안의 숫자로 수정

"itemReviewed" 필드 누락은 실무에서 가장 자주 보이는 오류다. 워드프레스 플러그인이나 자체 개발 코드에서 리뷰를 Product 안에 중첩하지 않고 독립적으로 뿌리면서 이 필드를 빠뜨리는 경우가 많다. 블로그 포스트 페이지에 상품 리뷰 스키마를 잘못 심었을 때도 같은 오류가 뜬다.

오류가 아니라 경고로만 뜨는 항목도 있다. 예를 들어 권장 속성인 reviewBody나 datePublished가 없으면 경고가 뜨지만, 이것만으로 리치 결과가 아예 막히지는 않는다. 다만 경고가 쌓여 있다는 것은 마크업이 최소 조건만 겨우 충족한 상태라는 신호이므로, 시간이 될 때 권장 속성을 채워 넣는 편이 좋다.

리치 결과 테스트로 어떻게 검증하나

발행 전에는 반드시 리치 결과 테스트로 검증해야 한다. 구글 서치 센트럴이 제공하는 이 도구는 실제 페이지 URL을 입력하거나 코드를 직접 붙여넣어 마크업이 올바르게 인식되는지 즉시 확인해준다.

검증 순서는 다음과 같다.

1. 리치 결과 테스트 페이지에 상품 상세 URL을 입력한다.
2. 결과 화면에서 Product와 그 안의 review·aggregateRating이 감지됐는지 확인한다.
3. "오류" 항목이 없는지 먼저 본다 — 오류가 있으면 그 항목은 리치 결과에서 아예 제외된다.
4. "경고" 항목을 확인한다 — 경고는 리치 결과 자체는 뜨지만 완성도가 떨어진다는 신호다.
5. 화면에 미리보기로 별점이 표시되는지 최종 확인한다.

리치 결과 테스트에서 통과했다고 실제 검색결과에 즉시 별점이 뜨는 것은 아니다. 구글이 페이지를 다시 크롤링하고 신뢰할 만하다고 판단하기까지 며칠에서 몇 주가 걸릴 수 있다.

서치 콘솔의 리뷰 스니펫 보고서는 사이트 전체를 대상으로 한 번에 오류를 모아 보여주므로, 개별 페이지 점검은 리치 결과 테스트로, 사이트 전체 현황 파악은 서치 콘솔 보고서로 병행하는 것이 효율적이다.

AI 검색은 리뷰 스키마를 어떻게 활용하나

챗GPT·제미나이·퍼플렉시티 같은 AI 검색은 "이 상품 어때?" 같은 질문에 답할 때 본문에 흩어진 후기 문장보다 명확하게 구조화된 평점·리뷰 데이터를 더 안정적으로 참고한다. 평점 숫자와 리뷰 개수가 구조화 데이터로 명시돼 있으면, AI가 "평균 4.7점, 리뷰 128개"처럼 구체적인 수치를 답변에 그대로 인용하기 쉬워진다.

이 효과를 대규모로 정량 검증한 공식 연구는 아직 부족하지만, 구조화된 사실이 애매한 산문보다 기계가 파싱하기 쉽다는 점은 기술적으로 당연하다. 스키마 마크업이 AI 검색 시대에 갖는 의미는 리치 결과 이야기를 다룬 AI가 인용하는 스키마 마크업 가이드에서 FAQ·HowTo·Product를 아우르며 정리했다.

reviewBody(후기 본문)를 함께 마크업해두면 AI가 평점 숫자만이 아니라 "배송이 빠르다", "포장이 꼼꼼하다" 같은 실제 문장까지 인용 재료로 쓸 수 있다는 점도 챙길 만하다. 숫자와 문장을 함께 구조화해두는 습관이 AI 인용 관점에서 더 유리하다.

리뷰 스키마 전체 예시는 어떤 모습인가

아래는 개별 리뷰 여러 개와 평균 평점을 함께 마크업한 완성형 예시다.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "OO 무선 이어폰",
  "image": "https://example.com/product.jpg",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.7",
    "reviewCount": "128"
  },
  "review": [
    {
      "@type": "Review",
      "author": { "@type": "Person", "name": "김OO" },
      "datePublished": "2026-08-14",
      "reviewBody": "배송이 빠르고 착용감이 좋습니다.",
      "reviewRating": {
        "@type": "Rating",
        "ratingValue": "5",
        "bestRating": "5",
        "worstRating": "1"
      }
    }
  ]
}

이 구조에서 리뷰는 Product 안에 중첩돼 있으므로 각 Review 항목에 itemReviewed를 따로 넣지 않아도 된다. 이렇게 필수 속성만 정확히 채운 최소 구성으로도 리치 결과 요건을 충족할 수 있다는 점을 확인할 수 있다.

지금까지의 내용을 실제 홈페이지에 적용하려면 상품 페이지 구조 자체를 스키마 친화적으로 설계하는 작업이 함께 필요할 때가 많다. 신규로 홈페이지 제작을 준비 중이라면 상품·리뷰 구조를 설계 단계부터 반영하는 편이 이후 수정보다 훨씬 적은 품이 든다. 이미 운영 중인 사이트라면 검색엔진최적화 서비스를 통해 기존 코드의 리뷰 스키마 오류부터 점검받는 방법도 있다.

리뷰 스키마는 한 번 정확히 세팅해두면 이후 리뷰가 쌓일수록 저절로 효과가 커지는 구조화 데이터입니다. 직접 코드를 붙였는데도 별점이 뜨지 않거나 서치 콘솔 오류가 반복된다면, 이루웹에 상담을 요청해 주시면 현재 마크업 상태를 점검해 드리고 있습니다. 상품 페이지 구조 설계부터 검증까지 함께 살펴보시고 실제 검색결과에 별점이 뜨는 시점까지 확인해 드리겠습니다.

자주 묻는 질문

리뷰가 5개 미만인데도 AggregateRating을 넣어도 되나?

넣어도 된다. 구글 공식 가이드라인에 최소 리뷰 개수 기준은 명시돼 있지 않다. 다만 리뷰 수가 너무 적으면 평균 평점의 신뢰도가 낮아 보일 수 있으므로, 실무에서는 리뷰가 어느 정도 쌓인 뒤 노출하는 경우가 많다.

별점 5개 만점이 아니라 10점 만점 체계면 어떻게 표기하나?

reviewRating이나 aggregateRating 안에 bestRating과 worstRating을 명시하면 된다. 예를 들어 10점 만점에 8.5점이라면 "ratingValue": "8.5", "bestRating": "10", "worstRating": "1"처럼 넣는다. 생략하면 구글은 기본값인 5점 만점으로 해석하므로 반드시 명시해야 한다.

리치 결과 테스트를 통과했는데 검색결과엔 왜 안 뜨나?

마크업 통과와 실제 노출은 별개 단계다. 구글이 페이지를 다시 크롤링하고 신뢰할 만한 데이터라고 판단하는 데 시간이 걸리며, 상품 카테고리나 검색 지면에 따라 리치 결과 자체가 노출되지 않는 경우도 있다. 며칠에서 몇 주 정도 기다린 뒤 서치 콘솔 리뷰 스니펫 보고서로 재확인하는 것이 정상적인 절차다.

LocalBusiness 평점은 자사 사이트에 아예 못 넣나?

코드 자체는 넣을 수 있지만 리치 결과(검색결과 별점 노출) 대상에서는 제외된다. 매장·회사 전체 평판을 검색결과에 노출시키고 싶다면 구글 비즈니스 프로필처럼 제3자가 관리하는 플랫폼에 쌓인 리뷰를 활용하는 것이 규정에 맞는 방법이다.

AggregateRating과 개별 Review를 같이 넣으면 오히려 손해 보나?

아니다. 오히려 구글 공식 문서가 권장하는 방식이다. 개별 리뷰 여러 개를 마크업할 때는 그 리뷰들을 합산한 AggregateRating도 함께 넣는 것이 정상적인 구성이며, 중복으로 불이익을 받는 구조가 아니다. 다만 두 데이터의 숫자가 서로 어긋나면(예: 평균은 4.7인데 실제 리뷰 점수를 합산하면 3점대) 신뢰도 판단에 불리하게 작용할 수 있으므로 숫자의 정합성은 항상 맞춰야 한다.