AEO·GEO

병원 FAQ 스키마, 2026년에도 계속 넣어야 할까?

2026-10-01 · 메디리바이브

결론부터 말하면, 병원 홈페이지의 질문·답변 콘텐츠는 계속 운영할 가치가 있지만 Google FAQ 리치 결과를 기대하며 FAQPage를 모든 글에 붙이는 방식은 중단해야 합니다. Google은 2026년 5월 7일부터 FAQ 리치 결과를 더 이상 검색결과에 표시하지 않으며, 6월에는 관련 개발 문서도 제거했습니다. 따라서 예전 화면 캡처나 플러그인 점수를 근거로 “FAQ 스키마를 넣으면 검색결과가 넓어진다”고 안내하면 현재 정책과 맞지 않습니다.

FAQPage는 Schema.org 어휘로는 여전히 존재합니다. 다만 Schema.org 타입이 존재한다는 사실과 Google 검색에서 별도 리치 결과를 지원한다는 사실은 다릅니다. 병원 사이트 운영자는 “마크업이 유효한가”와 “Google 검색 기능이 현재 지원되는가”를 분리해서 봐야 합니다.

이 글은 치료 정보가 아니라 병원 홈페이지의 검색·콘텐츠 운영을 다룹니다. 공개 전에는 실제 질문과 답변, 구조화 데이터, 플러그인 출력, Google 최신 문서를 같은 날 기준으로 확인합니다.

1. 2026년에 바뀐 것은 FAQ 콘텐츠가 아니라 검색 표시 기능입니다

Google Search Central 업데이트 기록에 따르면 FAQ 리치 결과는 2026년 5월 7일부터 검색결과에 더 이상 표시되지 않습니다. 6월 15일에는 FAQ 리치 결과 기능 문서도 제거됐습니다. 이는 FAQ 문장을 홈페이지에서 삭제하라는 뜻이 아니라, FAQPage 마크업으로 얻던 별도 검색 표시 기능이 종료됐다는 뜻입니다.

과거에는 일부 권위 있는 정부·건강 사이트에 한정해 FAQ 리치 결과가 표시됐지만, 현재는 그 기능 자체가 검색 갤러리에서 빠졌습니다. 병원 홈페이지가 의료기관이라는 이유만으로 예전 FAQ 표시가 유지된다고 가정하지 않습니다.

플러그인 화면에 FAQ 스키마 선택 메뉴가 남아 있을 수 있습니다. 플러그인 기능의 존재는 Google의 현재 지원을 뜻하지 않습니다. 검색 갤러리와 업데이트 기록을 우선 확인하고, 플러그인 안내 날짜가 오래됐다면 운영 기준으로 사용하지 않습니다.

운영 문서에는 변경일과 확인 출처를 적습니다. “FAQ 스키마 사용” 같은 고정 규칙 대신 “Google 검색 지원 여부 확인 후 적용”으로 바꾸면 다음 기능 변경에도 대응하기 쉽습니다.

실무 점검은 페이지 단위로 시작합니다. FAQ가 있는 URL을 한 줄씩 적고, 질문이 화면에 보이는지, 답변을 누가 확인했는지, 마지막 수정일이 언제인지 기록합니다. 같은 페이지에서 개발자 도구나 공개 HTML을 열어 FAQPage가 실제로 출력되는지도 적습니다. 관리자 설정 화면의 상태와 공개 결과가 다르면 공개 결과를 기준으로 원인을 찾습니다.

우선순위는 검색 노출 기대치보다 정보가 틀렸을 때의 불편으로 정합니다. 예를 들어 휴진일과 접수 마감 시간은 잘못 안내되면 방문 실패로 이어질 수 있으므로 먼저 확인합니다. 반면 오래된 블로그 글의 일반적인 정의 설명은 담당자 검토 후 순차적으로 고쳐도 됩니다. 페이지별 위험과 수정 담당자를 한 표에 두면 스키마 정리도 함께 진행할 수 있습니다.

2. 질문·답변 형식은 여전히 이용자와 답변 엔진에 유용합니다

리치 결과가 사라져도 이용자가 자주 묻는 질문을 짧고 정확하게 정리하는 일은 중요합니다. 진료시간, 예약 방법, 주차, 준비물, 서류 발급처럼 운영 사실을 질문형 제목과 직접 답변으로 제공하면 사용자가 필요한 정보를 빠르게 찾을 수 있습니다.

질문은 검색량만 보고 늘리지 않습니다. 실제 전화·상담·접수 과정에서 반복되는 질문을 우선합니다. 답변에는 적용 범위, 기준 날짜, 예외, 확인 경로를 포함하고 확인되지 않은 치료 효과나 진단 판단을 넣지 않습니다.

한 문장 답변 뒤에는 필요한 조건을 설명합니다. “주차가 가능한가요?”라면 가능 여부만 적지 않고 위치, 이용 시간, 등록 방법, 변동 가능성과 확인 연락처를 보이는 본문으로 제공합니다.

AI 검색도 결국 공개되고 색인 가능한 본문을 바탕으로 정보를 찾습니다. 별도 FAQ 스키마보다 정확한 운영 정보, 고정 URL, 내부링크, 수정일 관리가 먼저입니다.

작성 예시를 보겠습니다. “토요일에도 진료하나요?”에 “네, 가능합니다”만 쓰면 어느 토요일인지, 접수가 몇 시에 끝나는지 알 수 없습니다. 실제 병원 정보를 확인한 뒤 “토요일 진료시간은 ○시부터 ○시까지이며 접수는 ○시에 마감합니다. 공휴일 일정은 공지 페이지에서 확인해 주세요”처럼 조건과 확인 경로를 함께 적습니다. 여기의 시간은 설명용 빈칸이며 실제 사이트에 그대로 게시하지 않습니다.

질문 하나에 서로 다른 답변이 여러 URL에 생기면 최신 정보가 무엇인지 판단하기 어려워집니다. 운영 FAQ의 대표 URL을 정하고 관련 진료·오시는 길 페이지에서는 그 URL로 연결합니다. 수정이 발생했을 때 대표 페이지부터 고치고, 그 내용을 인용한 블로그 문단과 카드 이미지까지 함께 점검하는 방식이 안전합니다.

3. FAQPage를 남기려면 보이는 내용과 정확히 일치시킵니다

Schema.org FAQPage를 내부 의미 표현이나 다른 시스템 호환을 위해 유지할 수는 있습니다. 이 경우 JSON-LD의 질문과 답변은 사용자가 화면에서 볼 수 있는 문장과 일치해야 합니다. 숨겨진 키워드 질문이나 본문에 없는 답변을 추가하지 않습니다.

한 페이지에 보이는 질문 중 일부만 선택적으로 과장해 마크업하지 않습니다. 구조화 데이터는 페이지의 실제 주제를 설명해야 하며 광고 문구, 근거 없는 비교, 존재하지 않는 서비스 정보를 넣어서는 안 됩니다.

Rank Math가 이미 BlogPosting을 출력한다면 같은 글에 Article을 다시 수동 추가하지 않습니다. FAQPage를 쓰더라도 BlogPosting과 역할을 구분하고 하나의 JSON-LD 그래프에서 중복 엔터티가 생기지 않는지 확인합니다.

Google 리치 결과 미지원 상태에서는 FAQPage 추가가 검색 노출을 보장하지 않습니다. 유지 비용이 크거나 실제 콘텐츠와 자주 어긋난다면 보이는 질문·답변만 남기고 마크업을 제거하는 선택도 가능합니다.

마크업을 유지하기로 했다면 세 가지를 비교합니다. 첫째, 화면의 질문 문장과 JSON-LD의 name이 같은가. 둘째, 화면의 답변과 acceptedAnswer.text가 같은 의미인가. 셋째, 페이지 개편으로 삭제된 질문이 JSON-LD에 남아 있지 않은가. 이 비교는 관리자 미리보기가 아니라 방문자가 보는 최종 URL에서 해야 캐시와 플러그인 중복을 찾을 수 있습니다.

FAQPage가 없다고 해서 질문형 콘텐츠가 검색에 보이지 않는 것은 아닙니다. 반대로 FAQPage가 유효하다고 해서 검색 기능이 다시 제공되는 것도 아닙니다. 구조화 데이터 검증 도구의 “문법상 유효” 표시와 실제 검색결과의 표시 여부를 별도 항목으로 기록하면 팀 내부에서 잘못된 성과 보고를 줄일 수 있습니다.

4. 기존 FAQ 글은 삭제보다 점검표로 정리합니다

기존 글을 일괄 삭제하지 않습니다. 먼저 URL, 질문 수, 마지막 확인일, 담당자, 운영 정보 출처, FAQPage 유무를 표로 만듭니다. 검색 기능 종료와 콘텐츠 품질은 별개의 문제이므로 유용한 답변은 그대로 유지합니다.

예약·주차·진료시간처럼 변동이 잦은 답변은 최신 운영 정보와 대조합니다. 오래된 답변을 수정하면 화면의 수정일과 BlogPosting dateModified가 같은 변경을 말하는지 확인합니다.

구조화 데이터는 공개 HTML에서 직접 파싱합니다. 관리자 화면에서 스위치가 꺼져 있어도 캐시나 다른 플러그인이 FAQPage를 출력할 수 있고, 반대로 설정이 켜져 있어도 공개 페이지에 반영되지 않을 수 있습니다.

변경 뒤에는 URL 검사에서 Googlebot이 받은 HTML을 확인합니다. 리치 결과 종료와 색인 가능 여부를 혼동하지 말고 canonical, robots, HTTP 200, 본문 가시성을 함께 봅니다.

수정 순서는 공개 화면의 틀린 답변을 바로잡고, 같은 답변을 담은 카드·공지·플레이스 정보를 확인한 다음, 필요할 때 구조화 데이터를 수정하는 것입니다. FAQPage만 지우고 본문을 오래된 상태로 두면 사용자 문제는 해결되지 않습니다. 반대로 본문만 고친 채 캐시에 남은 JSON-LD를 방치하면 서로 다른 답변이 동시에 전달될 수 있습니다.

검증 기록에는 URL, 확인 날짜, 변경 전후 질문, 담당자, 공개 HTML 확인 결과를 남깁니다. Search Console에서 검사한 URL이 실제 대표 URL과 같은지도 확인합니다. 색인 생성 요청을 눌렀다는 사실은 수집 요청이 접수됐다는 뜻이며, 즉시 검색결과에 반영됐다는 뜻으로 보고하지 않습니다.

5. 병원 FAQ 운영 목표를 검색 장식에서 정보 관리로 바꿉니다

FAQ의 성과를 리치 결과 노출 횟수 하나로 평가하지 않습니다. 같은 질문의 전화 문의 감소, 예약 준비 안내 도달, 관련 페이지 이동, 운영 정보 오류 감소처럼 실제 이용 흐름을 봅니다.

새 글을 만들기 전에 기존 질문이 이미 다른 URL에 있는지 검색합니다. 같은 답변을 여러 글에 복제하면 수정 시점이 달라져 서로 다른 운영 정보가 노출될 수 있습니다.

질문마다 담당 부서와 확인 주기를 연결합니다. 콘텐츠팀이 답변을 작성하더라도 진료시간·주차·서류 발급 같은 사실은 실제 운영 담당자가 확인해야 합니다.

현재 기준의 실무 결론은 단순합니다. FAQ 콘텐츠는 유지하되, FAQ 리치 결과를 약속하지 않고, FAQPage를 남길 때는 보이는 질문·답변과 일치시키며, 지원 기능은 Google 검색 갤러리에서 다시 확인합니다.

운영 지표도 질문의 목적에 맞춰 나눕니다. 예약 안내는 해당 안내 페이지에서 예약 페이지로 이동하는지, 주차 안내는 위치 확인이 쉬운지, 서류 발급 안내는 전화 문의 전에 필요한 준비물을 찾을 수 있는지 살펴봅니다. 문의 수 변화는 영업일과 방문 규모가 달라지면 함께 달라질 수 있으므로 한 숫자만으로 FAQ의 효과를 단정하지 않습니다.