검색 결과에 별점을 띄워달라는 요청을 받았습니다 — 리뷰 스니펫이 안 뜨는 진짜 이유

"경쟁사는 검색 결과에 별 다섯 개가 뜨는데 우리는 왜 안 뜨나요." 상담에서 가장 자주 나오는 요청 중 하나입니다. 그리고 대부분은 마크업을 안 넣어서가 아닙니다. 리뷰 스니펫은 코드를 심으면 켜지는 스위치가 아니라, 구글이 페이지의 성격과 리뷰의 출처를 보고 표시 여부를 정하는 기능입니다. 2026년 7월 24일에는 여기에 대가성 리뷰 관련 문구까지 추가됐습니다. 순서대로 짚겠습니다.

별점은 아무 페이지에나 붙일 수 있는 것이 아닙니다

구글 문서가 리뷰 스니펫 대상으로 지정한 콘텐츠 유형은 정해져 있습니다. 책, 강의, 이벤트, 지역 비즈니스, 영화, 상품, 레시피, 소프트웨어 앱, 그리고 Organization을 포함한 일부 schema.org 유형입니다. 목록에 없는 페이지 유형이면 마크업이 문법적으로 완벽해도 별점은 나오지 않습니다.

실무에서 이 지점이 자주 어긋납니다. 병원의 시술 소개 페이지, 인테리어 업체의 시공 사례 페이지, 학원의 커리큘럼 페이지는 상품(Product)도 강의(Course)도 아닌 일반 서비스 소개글인 경우가 많습니다. 여기에 AggregateRating을 얹어 달라는 요청을 받으면, 저희는 먼저 이 페이지가 어떤 유형으로 성립하는지부터 정리합니다. 유형이 성립하지 않으면 마크업은 리치 결과 테스트만 통과하고 검색 결과에는 끝내 반영되지 않습니다. 구조화 데이터를 어디에 먼저 투자할지는 구조화 데이터, 무엇부터 넣어야 실제로 표시되나에서 유형별로 정리해 두었습니다.

가장 많이 걸리는 함정 — 자기 자신에 대한 리뷰

구글은 검토 대상 주체가 자기에 대한 리뷰를 스스로 통제하는 경우, 그 페이지의 LocalBusiness나 그 밖의 Organization 구조화 데이터는 별점 기능 대상에서 제외된다고 명시합니다. 쉽게 말해 "우리 회사 홈페이지에, 우리가 받은 후기를, 우리가 올려서, 우리 회사 평점으로 마크업하는" 구성은 원칙적으로 표시되지 않습니다.

많은 사이트가 정확히 이 구성을 하고 있습니다. 고객 후기 게시판을 만들고 평균 별점을 계산해 홈에 AggregateRating으로 넣는 방식입니다. 악의가 없어도 구글 기준으로는 자기 참조 리뷰이고, 그래서 아무리 기다려도 별점이 붙지 않습니다. 여기에 더해 다른 사이트의 리뷰나 평점을 끌어와 집계하는 것, 지역 비즈니스 평점을 사람이 편집해 만들어 넣는 것도 허용되지 않습니다.

2026년 7월에 추가된 문장 — 대가성 리뷰의 표시 의무

구글은 7월 24일 리뷰 스니펫 문서에 가짜 리뷰와 미표시 대가성 리뷰에 대한 항목을 넣었습니다. 금지 대상은 두 가지입니다. 상품이나 서비스를 실제로 경험하지 않고 쓴 리뷰, 그리고 금전·할인·상품권·무료 제공 같은 혜택의 대가로 작성됐는데 그 사실을 명확하고 눈에 띄게 밝히지 않은 리뷰입니다.

문장을 정확히 읽는 것이 중요합니다. 대가성 리뷰 자체를 전면 금지한 것이 아니라, 밝히지 않은 대가성 리뷰를 금지한 것입니다. 리뷰 이벤트를 하지 말라는 뜻이 아니라 표시를 하라는 뜻입니다. 국내 사업자에게는 오히려 익숙한 요구입니다. 공정거래위원회의 추천·보증 심사지침도 경제적 이해관계를 소비자가 알아볼 수 있게 표시하도록 요구하고 있으니, 두 기준을 따로 관리할 필요 없이 한 번에 맞추면 됩니다. 후기 이벤트를 운영 중이라면 해당 후기에 대가 제공 사실을 본문 안에 남기고, 그 표기가 마크업 대상 리뷰에도 그대로 노출되게 하십시오.

마크업 자체가 미달인 경우

유형과 출처가 문제없는데도 안 나오는 경우가 남습니다. 이때는 필수 속성을 봅니다. Review에는 작성자(author), 검토 대상(itemReviewed)과 그 이름, 그리고 평점값(reviewRating.ratingValue)이 필요합니다. AggregateRating에는 검토 대상과 ratingValue, 그리고 ratingCount 또는 reviewCount 중 최소 하나가 필요합니다. 5점 척도가 아니라면 bestRating과 worstRating을 함께 넣어 척도를 알려주는 편이 안전합니다.

author를 사이트 이름으로 넣어둔 사례가 특히 흔한데, 이건 리뷰를 쓴 사람이 아니라 리뷰를 게시한 주체를 적은 것이라 자기 참조 판정으로 이어지기 쉽습니다. 실제 작성자 이름을 넣을 수 없는 구조라면 그 리뷰는 마크업 대상이 아니라고 보는 편이 맞습니다.

그래서 우리 업종은 무엇을 해야 하나

서비스업 대부분은 자사 사이트의 별점을 포기하는 편이 현실적입니다. 대신 별점이 실제로 노출되는 자리를 관리합니다. 지역 업종이면 구글 비즈니스 프로필과 네이버 플레이스의 평점이 검색 화면에 뜨는 별점이고, 그쪽 후기 관리가 곧 별점 관리입니다. 판매 상품이 있으면 Product, 유료 강의가 있으면 Course처럼 유형이 성립하는 페이지에서만 리뷰 마크업을 씁니다.

그리고 별점이 아니어도 검색 결과에서 확보할 수 있는 자리는 남아 있습니다. 제목과 설명이 어떻게 다시 쓰이는지는 검색 결과 제목이 내가 쓴 제목과 다릅니다에서 다뤘습니다. 표시 결과는 마크업이 아니라 구글의 판단이라는 점에서 별점과 같은 원리입니다.

점검 순서 요약

별점 요청을 받으면 이 순서로 확인하십시오.

1) 이 페이지가 리뷰 스니펫 대상 유형(상품·강의·레시피·앱·이벤트 등)으로 성립하는가. 아니면 여기서 멈춥니다.
2) 리뷰의 출처가 우리 자신인가. 우리가 통제하는 자사 리뷰라면 LocalBusiness·Organization 별점은 나오지 않습니다.
3) 다른 사이트 평점을 긁어오거나 사람이 편집해 만든 점수가 섞여 있지 않은가.
4) 대가를 준 후기가 있다면 그 사실이 리뷰 본문에 명확히 표시돼 있는가.
5) author·itemReviewed·ratingValue·ratingCount 같은 필수 속성이 빠지지 않았는가.
6) 위를 정리한 뒤 서치콘솔의 리치 결과 보고서에서 항목이 유효로 잡히는지, 그리고 실제 검색 화면에 반영되는지 몇 주 간격으로 확인합니다. 정기적으로 볼 보고서는 매주 이 리포트 3개만 확인하면 됩니다에 정리해 두었습니다.

마크업이 유효하다는 것과 검색 결과에 표시된다는 것은 다른 말입니다. 구글은 유효한 구조화 데이터에도 표시를 보장하지 않습니다. 별점은 특히 그렇습니다. 코드부터 심고 기다리기 전에 위 1)번과 2)번을 먼저 보면, 들일 필요 없는 작업을 상당 부분 걸러낼 수 있습니다.