aggregateRating 올바른 설정: 구글이 조용히 거부하는 필드

aggregateRating에 실제로 필요한 필드는 무엇입니까?

aggregateRating은 비교적 단순한 객체이며, 실제로 중요한 필드는 몇 가지에 불과합니다. 필수 항목은 ratingValue(평균 평점)와 해당 평점이 산출된 평가의 수입니다. 이 수치는 reviewCount(실제 텍스트가 작성된 리뷰 수)나 ratingCount(텍스트 없이 별점만 남긴 평가를 포함한 총 수)로 표현할 수 있으며, 둘 중 하나는 반드시 포함해야 합니다.

나머지 필드는 모두 선택 사항입니다. bestRating과 worstRating의 기본값은 각각 5와 1이므로, 사용하는 척도가 표준(5점 만점)과 다른 경우에만 명시적으로 선언하면 됩니다. 5점 척도를 사용하는 대부분의 쇼핑몰은 이 두 필드를 생략해도 무방합니다.

• ratingValue: 평균 평점, 예를 들어 "4.6".
• reviewCount 또는 ratingCount: 둘 중 하나는 필수입니다.
• bestRating: 선택 사항, 기본값은 5.
• worstRating: 선택 사항, 기본값은 1.

reviewCount와 ratingCount: 어느 것을 사용해야 합니까?

텍스트 없이 별점만 남긴 평가가 총 수치에 포함된 경우 ratingCount를 사용하고, 총 합산 수치가 모두 실제 작성된 리뷰인 경우 reviewCount를 사용합니다. 이 구분이 중요한 이유는 두 수치가 종종 다르기 때문이며, 잘못된 필드를 선언하면 총계가 부풀려져 문제를 쉽게 발견할 수 있습니다.

예를 들어, 100명이 별점을 남기고 그 중 40명이 텍스트 리뷰를 작성했다면, reviewCount는 40이고 ratingCount는 100입니다. 두 수치를 모두 선언할 수도 있습니다. 단, 40개의 리뷰만 존재하는 상황에서 reviewCount에 100을 입력해서는 안 됩니다. 필드 이름 자체가 해당 수치가 무엇을 나타내는지에 대한 선언이기 때문입니다.

수치와 표시 리뷰가 일치해야 한다는 규칙은 무엇입니까?

구글의 구조화된 데이터 가이드라인에 따르면, aggregateRating은 사용자가 해당 페이지에서 실제로 볼 수 있는 리뷰를 반영해야 합니다. 마크업의 수치와 페이지에 렌더링된 리뷰는 동일한 집합을 가리켜야 합니다. 두 값이 어긋나면 해당 마크업은 페이지를 대표하지 않는 것으로 간주되며, 이것이 별점 스니펫이 표시되지 않는 근거가 됩니다.

이 문제는 제품 페이지에 10개의 리뷰를 표시하면서 schema에는 200이라는 수치를 선언하는 쇼핑몰에서 흔히 발생합니다. 의도 자체는 정직할 수 있습니다. 제품에 실제로 200개의 리뷰가 다른 곳에 존재하는 경우가 그 예입니다. 하지만 페이지가 10개만 보여준다면, 해당 마크업은 페이지 내용을 과장하는 것입니다.

사이트 전체 평점이나 부풀린 집계가 거부되는 이유는 무엇입니까?

흔한 거부 사례 중 하나는 단일 전체 평점을 모든 제품에 적용하는 것입니다. 쇼핑몰이 전체 리뷰의 단순 평균을 계산하여 각 제품 페이지에 동일하게 적용하면, 신규 제품도 베스트셀러의 평판을 그대로 상속받게 됩니다. 구글은 Product의 aggregateRating이 해당 제품에 대한 선언임을 전제하므로, 이를 오해의 소지가 있는 것으로 판단합니다.

수치 부풀리기도 마찬가지입니다. 수치를 인위적으로 늘리거나, 단종된 옵션의 평점을 이월하거나, 더 이상 표시되지 않는 리뷰를 집계에 포함하는 경우, 표시되는 페이지와 선언된 마크업이 일치하지 않게 됩니다. 이 불일치가 스니펫이 제거되는 원인입니다.

• 모든 제품 페이지에 재사용되는 단일 사이트 전체 평균
• 페이지에 렌더링되는 리뷰보다 큰 수치
• 다른 제품이나 옵션에서 이월된 평점
• 숨겨진, 삭제된, 또는 비공개 리뷰가 포함된 수치

aggregateRating이 유효한지 어떻게 확인합니까?

widget이 아닌 렌더링된 HTML을 직접 확인해야 합니다. 제품 페이지를 열고 소스를 확인하거나 Rich Results Test를 사용하여 서버 HTML에 ratingValue와 count가 포함된 aggregateRating 객체가 있는지 확인합니다. 그런 다음 페이지에 실제로 표시되는 리뷰 수를 세어 두 수치가 일관된 내용을 전달하는지 검토합니다.

Rich Results Test는 누락된 필수 필드를 표시하지만, 페이지를 과장하는 정직해 보이는 수치는 잡아내지 못합니다. 이 부분은 직접 확인해야 합니다. 해당 도구는 형식(shape)은 검증하지만 사실 여부(truthfulness)는 검증하지 않습니다. 12개의 리뷰가 표시되는 페이지에서 수치가 300이어도 유효성 검사는 통과하지만, 수동 거부의 위험은 여전히 존재합니다.

마크업이 검증되어도 별점이 표시되지 않는 이유는 무엇입니까?

검증은 구문(syntax)을 확인하는 것이지 적격성(eligibility)을 확인하는 것이 아닙니다. aggregateRating이 완벽하게 구성되어 있어도, 수치가 표시되는 페이지와 모순되거나, 마크업이 크롤러가 실행하지 않는 스크립트에 의해 삽입되거나, 구글이 해당 검색어에 대해 스니펫을 표시하지 않기로 결정한 경우 별점이 나타나지 않을 수 있습니다. 처음 두 가지는 수정 가능하지만, 세 번째는 구글의 결정 사항입니다.

스크립트 삽입 문제는 조용한 장애물입니다. 많은 리뷰 앱이 평점을 페이지 로드 후 JavaScript widget에 렌더링하므로, 쇼핑객에게는 보이는 aggregateRating이 크롤러가 읽는 HTML에는 포함되지 않습니다. 필드 자체는 올바르지만, 크롤러가 확인하는 위치에 없는 것입니다.

매번 올바른 aggregateRating을 갖추려면 무엇이 필요합니까?

올바른 aggregateRating은 서버 렌더링, 제품별 설정, 그리고 정직한 수치라는 세 가지를 갖추어야 합니다. ratingValue와 count는 스크립트가 실행되기 전에 페이지 HTML에 포함되어 있어야 하고, 쇼핑몰 전체가 아닌 해당 제품에 대한 내용을 담아야 하며, 수치는 페이지의 리뷰와 일치해야 합니다. 대부분의 리뷰 앱은 페이지 방문자를 위해 설계되었기 때문에 별점을 widget에 렌더링합니다. 눈으로 보기엔 올바르지만 크롤러에게는 잘못 읽힙니다. 이미 보유한 평점을 읽기 가능한 제품별, 정확한 수치를 가진 마크업으로 렌더링하여 검색 스니펫을 획득하고 AI에서도 인용될 수 있도록 하는 것이 BeyondReviews가 해결하는 과제입니다.