병원 홈페이지에 환자 후기를 올리고 별점 구조화 데이터를 붙이면 Google 검색 결과에 별이 표시될까요? 병원이 자기 병원을 소개하는 페이지의 자체 후기를 표시하거나 외부 후기 위젯을 삽입해도, Google의 자체 평가 후기 기준에 따라 그 병원에 대한 별점 리뷰 리치 결과는 대상이 아닙니다. 구조화 데이터 문법이 맞는지와 검색 기능의 표시 자격은 다른 문제입니다. 따라서 별을 얻기 위해 점수를 만들어 넣는 작업보다, 실제 방문자가 필요로 하는 진료 정보와 후기의 출처·맥락을 정확히 설명하는 일이 먼저입니다.
이 글은 병원 운영자와 홈페이지 담당자가 리뷰 영역을 점검할 때 쓰는 실무 안내입니다. Google 비즈니스 프로필에 표시되는 실제 고객 리뷰, 병원 자체 홈페이지의 후기, 검색 결과의 별점 리치 결과를 서로 다른 영역으로 분리합니다. 의료광고와 개인정보 검토가 필요한 환자 경험담은 별도 기준으로 확인해야 하며, 이 글은 개별 후기의 게시 적법성을 판정하지 않습니다.
1. 별점이 표시되는 세 곳을 구분합니다
첫째, Google 검색이나 지도에 나오는 비즈니스 프로필 리뷰는 사용자가 해당 플랫폼에 남긴 평가입니다. 병원이 홈페이지에 붙이는 JSON-LD 코드로 그 점수를 직접 결정하지 않습니다. 둘째, 병원 홈페이지의 후기 영역은 병원이 편집하고 운영하는 자체 콘텐츠입니다. 환자가 읽을 수 있는 설명 자료가 될 수 있지만, 화면에 보인다는 사실만으로 Google의 별점 리치 결과 자격이 생기지 않습니다. 셋째, 검색 결과의 리뷰 스니펫은 Google이 지원하는 종류와 지침을 충족할 때 표시될 수 있는 검색 기능입니다. 코드가 검사 도구에서 통과해도 실제 표시를 보장하지 않습니다.
운영표에는 이 세 항목을 별도 열로 만드세요. 예를 들어 “지도 프로필 평점”, “홈페이지 후기 공개 여부”, “해당 URL의 리뷰 구조화 데이터”를 구분해 기록합니다. 담당자가 세 숫자를 하나로 섞으면 홈페이지 코드를 고쳤는데 지도 평점이 달라질 것이라고 기대하거나, 외부 위젯만 달면 검색 별이 생긴다고 오해하기 쉽습니다. 변경 전에는 화면 주소와 현재 보이는 위치를 함께 적어야 수정 후 비교가 가능합니다.
정상 예시는 지도에 실제 사용자 평가가 별도로 있고 홈페이지에는 운영 정책에 따라 승인된 후기만 출처와 시점을 명확히 표시하는 상태입니다. 오류 예시는 지도 평점의 숫자를 홈페이지 스키마에 그대로 복사해 병원 소개 페이지의 검색 별점을 만들겠다고 계획하는 상태입니다. 후자의 경우 숫자 복사의 정확성과 별개로 자격 문제를 해결하지 못합니다.
2. 자체 평가 후기 기준을 정확히 읽습니다
Google의 리뷰 스니펫 문서는 LocalBusiness 또는 Organization의 자체 평가 후기에 대해 명확한 제한을 둡니다. 평가 대상 업체가 자기 자신에 관한 후기를 통제하는 경우, 그 업체의 페이지는 별점 리뷰 기능 대상이 아닙니다. Google은 병원 사이트에 직접 입력한 후기뿐 아니라 Google 또는 다른 플랫폼의 평가를 외부 위젯으로 가져와 보여주는 예도 자체 평가 범위에 포함한다고 설명합니다. 병원이 의료기관이라는 사실 때문에 자동으로 예외가 되는 것이 아닙니다.
이 기준은 “환자 경험담을 홈페이지에서 무조건 삭제하라”는 뜻이 아닙니다. 검색 결과의 별점 기능 자격에 관한 규칙과 이용자에게 보여주는 콘텐츠의 적정성은 다른 판단입니다. 후기 페이지가 있다면 먼저 게시 목적, 사실 확인, 당사자 동의, 노출 범위, 개인정보, 현재 유효성을 점검해야 합니다. 코드만 제거하면 모든 콘텐츠 문제가 해결된다고 말할 수도 없습니다. 특히 치료 효과와 결과를 일반화하는 표현은 신중하게 검토해야 합니다.
리뷰 스니펫 문서는 허위 또는 공개되지 않은 대가성 후기를 구조화 데이터에 넣지 말라고 안내합니다. Google 비즈니스 프로필 역시 리뷰를 받거나 바꾸거나 부정적 리뷰를 제거하도록 유도하는 대가 제공을 금지합니다. 병원은 후기 확보 캠페인을 설계할 때 문구와 보상 여부를 따로 검토해야 합니다. 이 규칙은 별점 코드와 별개로 실제 고객 경험의 신뢰를 지키기 위한 기준입니다. 임의의 평균 점수, 가상의 평가 건수, 편집자가 만든 평점을 넣는 일은 피하세요.
3. 기존 구조화 데이터를 점검합니다
먼저 병원 소개 페이지와 후기 페이지의 공개 URL을 하나씩 열고 HTML에 들어간 JSON-LD를 확인합니다. WordPress에서는 SEO 플러그인, 리뷰 플러그인, 테마, 수동 코드가 각각 구조화 데이터를 만들 수 있습니다. 한 화면에 Hospital 또는 LocalBusiness 정보와 AggregateRating, Review가 여러 번 들어가 있다면 어느 구성요소가 생성했는지 소유자를 찾아야 합니다. 플러그인을 무작정 끄면 이름·주소·전화·영업시간 등 다른 정보까지 사라질 수 있으므로 변경 범위를 좁힙니다.
점검표의 첫 열은 URL, 둘째 열은 화면에서 실제로 보이는 후기·평점, 셋째 열은 JSON-LD의 평가 대상과 점수, 넷째 열은 코드 생성 주체로 만듭니다. 평점이 보이지 않는데 코드에만 숫자가 있거나, 병원 소개 본문에는 별점 4.8이라고 써 놓고 스키마에는 5.0을 넣었다면 불일치입니다. 후기 건수의 기준 기간이 바뀌었는데 정적 코드가 오래된 경우도 확인합니다. 도구에서 초록색 결과가 나와도 실제 내용과 규칙을 따로 읽어야 합니다.
수정 방향은 해당 병원의 자체 리뷰 별점 표시를 목적으로 추가한 Review 또는 AggregateRating 코드만 검토해 제거하거나 목적에 맞게 재설계하는 것입니다. 홈페이지의 기본 Organization 또는 LocalBusiness 정보와 개별 글의 BlogPosting을 모두 삭제하라는 뜻은 아닙니다. 실제 콘텐츠에 없는 항목을 새로 만들지 말고, 공개 화면의 사업자 정보가 정확한지 확인하세요. 구조화 데이터는 보이는 사실을 기계가 이해하도록 돕는 수단이지 새 평판을 만들어 주는 장치가 아닙니다.
4. 후기 콘텐츠의 출처와 동의를 확인합니다
후기를 계속 운영한다면 작성 주체와 수집 경로를 문서화하세요. 환자가 직접 작성한 것인지, 상담 후 인터뷰를 편집한 것인지, 외부 플랫폼에서 인용한 것인지에 따라 확인해야 할 사항이 다릅니다. 실명·얼굴·진료 내용·방문 시점은 개인을 알아볼 수 있는 정보가 될 수 있습니다. 공개 동의가 확인되지 않은 내용을 카드뉴스나 대표 이미지로 재가공하지 않습니다. 외부 리뷰를 가져올 때는 원 출처의 이용 조건과 공개 범위를 확인해야 합니다.
운영자가 “좋은 후기만 골라 올린다”는 작업과 “검색엔진에 이 병원의 전체 평균 평점이라고 알린다”는 작업을 혼동해서는 안 됩니다. 일부 선정된 경험담은 전체 이용자의 평균을 대표하지 않습니다. 후기 설명을 쓸 때도 특정 결과를 모든 환자에게 기대할 수 있는 것처럼 표현하지 않고, 실제 서비스 과정의 설명과 개인 경험을 구분합니다. 문제 제기가 들어왔을 때 수정·삭제 요청을 처리할 담당자와 확인 절차를 정해 두면 오래된 후기가 방치되는 일을 줄일 수 있습니다.
후기가 없는 페이지에 숫자만 보이게 하거나 생성형 이미지로 가상의 병원 평가 장면을 만드는 것은 방문자에게도 도움이 되지 않습니다. 실제 문의를 줄이는 정보는 대개 위치, 예약 절차, 진료 범위, 진료시간, 준비물, 비용 안내의 기준처럼 방문 전에 확인할 수 있는 내용입니다. 후기 영역을 손보는 동안 이런 기본 정보가 최신인지 함께 점검하는 편이 더 실용적입니다.
5. 별점 대신 도움이 되는 병원 정보로 답합니다
병원 이름과 진료 분야를 묻는 검색에는 홈페이지가 먼저 기본 질문에 답해야 합니다. 예를 들어 “어떤 진료를 하나요?”, “초진 예약은 어떻게 하나요?”, “검사 전 준비가 필요한가요?”, “진료시간이 바뀌었나요?” 같은 질문은 한 문장으로 답한 뒤 적용 조건과 예외를 설명합니다. 후기가 많다는 문구보다 실제 운영 정보가 이용자의 다음 행동을 결정하는 데 더 도움이 될 수 있습니다. 페이지마다 고유한 질문을 정하고 답이 들어 있는 문단으로 연결하세요.
Google의 AI 검색 관련 안내도 검색 결과에 등장하기 위해 별도의 AI 전용 구조화 데이터가 필요하다고 말하지 않습니다. 따라서 별점 스키마를 GEO 또는 AEO의 필수 설치 항목처럼 판매하거나, 제거하면 AI 인용이 떨어진다고 단정해서는 안 됩니다. 웹페이지가 읽히는지, 답이 명확한지, 출처와 작성 주체가 보이는지, 공개 정보와 실제 서비스가 일치하는지가 우선 점검 항목입니다. 후기 역시 경험담이라는 성격과 제한을 표시하면 사람이 내용을 해석하기 쉽습니다.
내부 링크는 독자의 다음 질문에 맞춰 둡니다. 병원 소개 페이지에서 진료 안내로, 진료 안내에서 예약 방법으로 이동할 수 있게 하고 링크 문구에 목적지를 설명합니다. 메디리바이브의 관련 글인 병원 로컬 검색 정보 일치 점검과 답변의 근거를 점검하는 기준도 별점보다 기본 정보와 근거가 왜 중요한지 다룹니다. 다만 내부 링크 자체가 별점 표시를 보장하지는 않습니다.
6. 수정 후 검색과 화면을 검증합니다
변경 뒤에는 비로그인 창에서 해당 URL을 다시 열어 실제 후기 문구와 링크가 정상인지 확인합니다. 소스의 JSON-LD를 살펴 의도하지 않은 AggregateRating 또는 Review가 남아 있지 않은지, Organization과 BlogPosting이 중복 생성되지 않았는지 점검합니다. 리치 결과 테스트는 지원되는 형식과 오류를 살피는 도구이며, 결과가 통과해도 검색에 별이 실제로 보이는지는 별도의 관찰 항목입니다. 캐시가 있으면 최종 공개 HTML에 수정 사항이 반영됐는지도 확인합니다.
검색 결과는 사용자 위치와 시점, 검색어에 따라 달라질 수 있습니다. “오늘 별이 없다”는 관찰만으로 색인 오류라고 결론 내리지 말고 페이지의 공개·색인 상태를 따로 확인합니다. Search Console 접근 권한이 있다면 URL 검사를 사용해 실제 색인 상태와 마지막 크롤링 정보를 살펴봅니다. 접근이 없다면 권한 확인을 기다리면서 공개 HTML과 내부 링크 검증까지 먼저 완료합니다. 제출된 색인 요청은 요청 수락이지 별점 노출 약속이 아닙니다.
실무 종료표는 URL / 후기 출처 / 동의 확인 / 화면 표시 / Review·AggregateRating 생성 위치 / 수정 내용 / 공개 HTML 검증 / 검색 관찰 날짜 순서로 남기면 좋습니다. 비정상 예시를 발견했다면 코드 생성 주체와 화면 불일치를 함께 기록한 뒤 담당자에게 수정 범위를 전달하세요. 정상 예시는 병원 정보가 사실에 맞고, 후기가 실제 출처와 맥락을 갖추며, 자체 리뷰에 대한 별점 리치 결과를 보장한다고 말하지 않는 상태입니다.
결론
자체 병원 후기의 별점 스키마는 검색 결과의 별을 얻기 위한 지름길이 아닙니다. 자체 평가 후기의 표시 자격을 먼저 확인하고, 실제 후기의 출처·동의·표현을 정리한 뒤, 병원 방문자가 궁금해하는 운영 정보를 정확하게 제공하세요. 홈페이지의 유용성과 검색 기능 자격을 별도 항목으로 관리하면 불필요한 코드 추가와 잘못된 성과 보고를 줄일 수 있습니다.