Review·AggregateRating 스키마의 제한

리뷰 대상과 사이트 운영 주체

이 제한을 판단하려면 누가 평가를 받는지와 누가 리뷰를 수집하는지를 먼저 나눠야 합니다. 운영자는 리뷰 대상 사업자명, 사이트 운영 사업자명, 리뷰를 접수하고 게시하는 주체를 기재합니다. 리뷰 작성자가 외부 이용자라는 사실만으로 리뷰를 수집하는 사이트까지 외부 사업자의 사이트가 되는 것은 아닙니다.

구글의 지역 비즈니스 문서는 aggregateRating과 review를 각각 권장 속성으로 설명하면서 같은 권장 대상 조건을 제시합니다. 따라서 개별 리뷰를 표현하는지, 여러 리뷰를 집계한 평점을 표현하는지에 앞서 사업자 사이의 관계를 정리해야 합니다. 운영자가 자사 소개 페이지에 후기를 게시했다면, 그 후기의 작성 경로만으로 해당 조건을 충족했다고 결론 내리지 않습니다.

이 표는 적용 가능성을 판단하기 위한 출발점이며 모든 리뷰 유형의 허용 목록은 아닙니다. 운영자는 관계가 불명확한 항목을 외부 리뷰로 임의 분류하지 말고, 사업자 정보와 서비스 운영 자료를 개발 담당자에게 전달합니다.

권장 대상과 허용 판단의 차이

권장 대상에 관한 설명만으로 자사 리뷰의 금지 범위 전체를 확정할 수는 없습니다. 외부 리뷰 위젯을 사용하면 허용되는지 역시 지역 비즈니스 문서의 해당 설명만으로 결정할 수 없습니다. 위젯의 공급 주체와 리뷰 대상 사업자의 관계를 별도로 기록하고, 리뷰 스니펫의 구체적인 조건을 추가로 확인해야 합니다.

또한 Review와 AggregateRating이라는 유형 이름이 같다고 해서 모든 페이지에 동일한 판단을 적용해서는 안 됩니다. 지역 비즈니스 속성의 권장 대상 조건에 해당하더라도 구조화된 데이터의 일반 품질 요건과 리뷰 스니펫의 기능 요건을 충족하는지 추가로 판단해야 합니다. 개발 담당자는 적용하려는 검색 기능과 대상 유형을 명시하고, 필요한 속성 목록은 해당 기능 문서에서 따로 대조합니다.

적용 결정 전 자료 준비 순서

운영자는 사업자 관계 자료를 먼저 준비하고, 개발 담당자는 그 관계를 근거로 기능 요건을 대조합니다. 점수나 리뷰 문구부터 전달하면 구현할 데이터만 논의하고 적용 대상 판단은 생략하기 쉽습니다. 작업 요청서에는 판단이 끝난 내용과 아직 결론을 내리지 않은 내용을 따로 기재합니다.

1. 운영자가 리뷰 대상 사업자와 사이트 운영 주체를 구분하고, 리뷰 접수·게시 업무를 누가 수행하는지 기록합니다.
2. 개발 담당자가 앞에서 정한 기준에 따라 지역 비즈니스 문서의 권장 대상과 실제 운영 관계를 대조합니다.
3. 개발 담당자가 리뷰 스니펫 가이드라인과 해당 속성 목록을 확인하고, 운영자와 함께 일반 품질 요건을 검토합니다.

리뷰 스니펫 문서의 세부 내용이 확보되지 않았다면 담당자는 구현 가능 여부를 확정하지 않습니다. 필요한 문서 이름과 해결할 질문을 남기고, 자료를 확보한 뒤 판단을 이어갑니다. 운영자는 검토 중인 값을 확정 데이터로 취급해 전체 페이지에 일괄 반영하지 않습니다.

개발 담당자에게 전달할 판단 요청

개발 요청은 스키마 추가 지시보다 적용 여부를 결정할 질문으로 작성합니다. 운영자는 어떤 사업자의 어떤 리뷰를 표현하려는지 설명하고, 개발 담당자에게 권장 대상 충족 여부와 리뷰 스니펫의 남은 요건을 나눠 답하도록 요청합니다. 필요한 속성을 빠짐없이 갖췄는지와 운영 관계가 조건에 해당하는지를 같은 답변으로 처리하지 않습니다.

자료 묶음에는 리뷰가 게시된 페이지 식별 정보, 수집 경로 설명, 집계에 포함한 리뷰의 범위를 포함합니다. 집계 방식이나 삭제 처리의 책임자가 서로 다르면 각 담당자의 업무도 기재합니다. 개발 담당자는 판단 근거로 사용한 문서 이름과 검토한 항목을 남겨, 이후 변경 요청에서 같은 질문을 처음부터 반복하지 않도록 합니다.

자료가 서로 충돌하면 운영자는 원본 기록을 관리하는 담당자에게 사실관계를 묻습니다. 개발 담당자가 부족한 사업자 관계 정보를 코드에서 추정하거나, 마케팅 담당자가 기술 검사 결과만으로 적용을 승인하는 방식은 피합니다.

문법 검사와 별개인 품질 판단

기술 검사에서 오류가 발견되지 않았어도 리뷰의 품질 판단은 남습니다. 구글은 리치 결과 테스트와 URL 검사 도구로 대부분의 기술 오류를 찾을 수 있지만, 품질 가이드라인은 자동화된 도구만으로 간편하게 검사하기 어렵다고 설명합니다. 운영자는 기술 검사 결과와 콘텐츠 검토 기록을 별도 항목으로 관리합니다.

구글의 일반 가이드라인은 최신 정보와 원본 콘텐츠를 요구하며, 독자에게 표시되지 않는 내용이나 페이지 주제와 관계없는 가짜 리뷰를 마크업하지 않도록 안내합니다. 또한 구조화된 데이터로 이용자를 오해하게 하거나 혼란스럽게 해서는 안 된다고 설명합니다. 콘텐츠 담당자는 리뷰 원문과 게시 내용을 대조하고, 페이지가 실제로 설명하는 대상에 대한 평가인지 판단합니다.

품질 요건을 위반하면 구문이 올바르더라도 구글 검색에서 리치 결과로 표시되지 않거나 스팸으로 표시될 수 있습니다. 따라서 운영자가 해결해야 할 콘텐츠 문제가 있다면 개발 담당자에게 코드 수정만 요청하지 않습니다. 원본을 관리하는 담당자가 잘못된 리뷰 내용이나 집계 자료를 먼저 정정하고, 개발 담당자가 그 변경을 구조화된 데이터에 반영합니다.

리뷰 변경에 따른 판단 기록

리뷰 적용 후에는 콘텐츠 변경이 기존 판단에 영향을 주는지 기록합니다. 운영자는 리뷰 삭제, 평가 대상 변경, 집계 범위 수정이 발생했을 때 어떤 데이터가 달라졌는지 개발 담당자에게 전달합니다. 별도의 실무 관리 절차로 변경 사유와 반영 상태를 함께 기재할 수 있습니다.

리뷰 본문을 수정했는데 집계 자료가 그대로 남거나, 수집 경로가 변경됐는데 이전 설명을 계속 사용하는 경우에는 담당 업무를 나눠 처리합니다. 콘텐츠 담당자는 원본과 게시 자료의 차이를 정리하고, 데이터 담당자는 집계에 포함된 항목을 추적합니다. 개발 담당자는 전달받은 변경 사항이 해당 마크업에 반영됐는지를 검사합니다.

기록에는 결정한 사항뿐 아니라 미해결 질문도 남깁니다. 리뷰 스니펫의 조건을 아직 대조하지 못했다면 그 상태를 명시하고, 기술 오류가 없다는 결과로 대신 승인하지 않습니다.

집계 대상이 다른 평점의 처리

같은 사업자에 관한 평점이라도 수집 경로나 집계 대상이 다르면 하나의 값으로 합칠 근거를 먼저 마련해야 합니다. 운영자는 어떤 리뷰를 포함했고 어떤 리뷰를 제외했는지 설명할 수 있는 자료를 준비합니다. 이 절차는 실무상 데이터 관리 기준이며, 특정 합산 방식이 구글에서 허용된다는 뜻은 아닙니다.

게시 화면의 평점과 내부 자료의 평점이 다를 때는 더 높은 값을 선택하지 않습니다. 데이터 담당자가 차이가 생긴 원인을 조사하고, 콘텐츠 담당자가 독자에게 안내할 집계 범위를 정합니다. 필요한 설명이 정리되지 않았다면 임의의 값으로 마크업을 완성하기보다 해당 항목의 적용 결정을 유보합니다.

이어서 읽을 주제

병원 플레이스 등록을 이어 읽으면 리뷰 데이터의 적용 판단과 별개로 사업자 정보 등록에 필요한 준비 사항을 정리할 수 있습니다. 등록 업무와 사이트의 구조화된 데이터 업무를 누가 관리할지 정할 때도 참고할 수 있습니다.