병원 사이트 구조화 데이터, 2026년엔 뭘 넣고 뭘 빼야 하나

핵심 요약

• 구조화 데이터는 검색과 AI가 병원의 공개 사실을 정확히 이해하도록 돕는 재료일 뿐, 순위나 리치 결과를 보장하지 않습니다. Google도 공식 문서에서 이 점을 분명히 밝힙니다.
• 2026년 5월 7일부로 Google은 FAQ 리치 결과를 검색에서 더 이상 보여주지 않습니다. "FAQ 스키마를 넣으면 검색에 박스로 뜬다"는 조언은 이제 유효하지 않습니다.
• 병원 사이트가 실제로 챙길 유형은 병원 기본정보(LocalBusiness 계열), 블로그 글(Article), 페이지 경로(BreadcrumbList) 정도로 단순합니다.
• 가장 중요한 규칙은 하나입니다. 화면에 없는 내용을 스키마에 넣지 마세요.

구조화 데이터, 병원 사이트에 꼭 필요한가?

원장님들이 GEO나 SEO를 준비하다 보면 "schema.org", "JSON-LD", "구조화 데이터" 같은 단어를 만납니다. 대행사에서 "구조화 데이터 세팅해 드립니다"라는 제안을 받기도 합니다.

먼저 개념부터 정리하겠습니다. 구조화 데이터는 화면에 이미 보이는 정보를 검색엔진과 AI가 이해하기 쉬운 형식으로 한 번 더 정리해 주는 표식입니다. 예를 들어 병원 소개 페이지에 "○○정형외과, 남양주시 ○○로 12, 전화 031-000-0000, 평일 09:00~18:00"이 적혀 있다면, 같은 사실을 기계가 헷갈리지 않게 라벨을 붙여 다시 적어 주는 것입니다.

즉 구조화 데이터는 새로운 내용을 만드는 곳이 아니라, 이미 공개한 사실을 기계가 오해 없이 읽도록 돕는 위생 작업에 가깝습니다.

먼저 짚을 오해: 순위도, 리치 결과도 보장하지 않는다

구조화 데이터를 두고 가장 흔한 오해가 "넣으면 검색에 특별하게 노출된다"는 기대입니다. Google Search Central 공식 문서는 이 부분을 명확히 선을 긋습니다.

"Google은 페이지를 올바르게 마크업했더라도 구조화 데이터가 검색 결과에 표시되는 것을 보장하지 않습니다."

정리하면 이렇습니다.

• 구조화 데이터는 특정 검색 기능(리치 결과)의 자격 조건일 뿐, 노출을 확정하는 스위치가 아닙니다.
• 순위를 올려 주는 장치도 아닙니다. Google은 구조화 데이터를 순위 요소로 설명하지 않습니다.
• 문법이 맞아도 품질 기준을 어기면 리치 결과가 막히거나, 심하면 스팸으로 분류될 수 있습니다.

그래서 병원 마케팅 관점에서 구조화 데이터는 "노출을 사는 도구"가 아니라, "우리 병원의 공개 사실을 검색·AI에 정확히 전달하는 기본기"로 보는 편이 정확합니다.

2026년에 달라진 것: FAQ 리치 결과가 사라졌다

여기서 반드시 짚어야 할 최신 변화가 있습니다. 오래된 GEO/SEO 자료에는 "FAQ 스키마(FAQPage)를 넣으면 검색 결과에 질문·답변 박스가 펼쳐진다"는 설명이 많습니다. 이제 그 조언은 맞지 않습니다.

• Google은 2023년 8월, FAQ 리치 결과를 정부·의료 등 일부 권위 있는 사이트로 제한했습니다. 같은 시기 HowTo 리치 결과도 축소됐고, HowTo는 이후 검색에서 완전히 사라졌습니다.
• 그리고 2026년 5월 7일부로 Google은 FAQ 리치 결과를 모든 사이트에서 더 이상 보여주지 않습니다. 2026년 6월 15일에는 관련 공식 문서까지 제거됐습니다.

이 변화의 의미는 분명합니다.

• FAQPage 스키마를 넣는다고 검색 화면에 질문·답변 박스가 뜨지 않습니다. 이 목적만으로 FAQ 스키마를 급하게 세팅할 이유는 사라졌습니다.
• 반대로 FAQ 콘텐츠 자체가 쓸모없어진 것은 아닙니다. 환자가 실제로 묻는 질문을 페이지에 잘 정리하는 일은 여전히 중요합니다. 사람에게도 유용하고, 검색·AI가 병원의 답변을 이해하는 재료가 되기 때문입니다. 달라진 것은 "리치 결과 박스"라는 겉포장이 사라졌다는 점뿐입니다.

리치 결과 하나를 노리고 스키마를 붙이는 접근이 얼마나 흔들리기 쉬운지 보여 주는 사례입니다. 검색 기능은 Google 정책에 따라 언제든 바뀝니다. 그래서 특정 박스를 노리기보다, 바뀌어도 손해가 없는 기본 사실 정리에 무게를 두는 편이 안전합니다.

그럼 병원 사이트는 무엇을 넣어야 하나

2026년 기준으로 병원 사이트가 검토할 만한 구조화 데이터는 생각보다 단순합니다.

유형	쓰임	병원 적용 예
Organization	운영 주체·브랜드 정보	병원 이름, 로고, 대표 URL
LocalBusiness 계열	병원 기본정보	주소, 전화, 진료시간, 지역 (세부적으로 Hospital·Dentist·MedicalClinic 등 하위 유형)
Article / BlogPosting	블로그·가이드 글	제목, 작성일, 본문 요약
BreadcrumbList	페이지 경로	홈 > 진료안내 > 도수치료

핵심은 "많이 붙이기"가 아닙니다. 병원의 정체(누구인가), 위치·연락(어디서 어떻게 상담하나), 콘텐츠(무엇을 다루나)를 기계가 헷갈리지 않게 표시하는 것으로 충분합니다.

특히 병원 기본정보(이름·주소·전화·진료시간)는 화면에도 명확히 있어야 하고, 그 사실이 스키마와 일치해야 합니다. 리치 결과 여부와 별개로, 검색과 AI가 "이 병원은 어디에 있고 어떻게 연락하는가"를 정확히 파악하는 데 직접 도움이 되는 정보이기 때문입니다.

아래는 병원 기본정보를 JSON-LD로 표시할 때의 최소 형태 예시입니다. 실제 값은 반드시 화면에 보이는 내용과 같아야 합니다.

{
  "@context": "https://schema.org",
  "@type": "MedicalClinic",
  "name": "○○정형외과의원",
  "address": "경기도 남양주시 ○○로 12",
  "telephone": "+82-31-000-0000",
  "url": "https://example-clinic.kr",
  "openingHours": "Mo-Fr 09:00-18:00"
}

Google이 정한 구조화 데이터 규칙

Google Search Central의 구조화 데이터 일반 가이드라인은 길지 않습니다. 병원 사이트에 중요한 항목만 추리면 다음과 같습니다.

1. 화면에 없는 내용을 넣지 마라. 가이드라인은 "페이지 독자에게 보이지 않는 콘텐츠를 마크업하지 말라"고 못 박습니다. 화면에는 없는 진료시간이나 수상 이력을 스키마에만 적어 넣으면 안 됩니다.

2. 크롤러 접근을 막지 마라. robots.txt, noindex 같은 방법으로 구조화 데이터가 든 페이지를 Googlebot이 못 읽게 막으면 안 됩니다. GEO를 말하면서 정작 페이지를 막아 두는 경우가 실제로 있습니다.

3. 오해를 부르는 마크업을 하지 마라. 가짜 리뷰, 페이지 내용과 무관한 정보처럼 실제와 다른 표시는 금지입니다. 마크업은 페이지 내용을 그대로 대표해야 합니다.

4. 필수 속성을 빠짐없이 채워라. 각 유형에 요구되는 필수 속성이 비어 있으면 애초에 리치 결과 대상이 되지 않습니다.

이 규칙을 어기면 어떻게 될까요? Google은 "품질 가이드라인을 위반하면, 문법이 맞는 구조화 데이터라도 리치 결과로 표시되지 못하거나 스팸으로 분류될 수 있다"고 설명합니다. 병원처럼 신뢰가 중요한 사이트에서는 무리한 마크업이 오히려 위험합니다.

병원 사이트에서 자주 나오는 실수

현장에서 반복해서 보이는 패턴을 정리했습니다.

• 화면과 스키마가 다르다. 리뉴얼하면서 화면 진료시간은 바꿨는데 스키마 값은 예전 그대로 남는 경우입니다. 사람과 기계가 서로 다른 정보를 받게 됩니다.
• 리치 결과만 노리고 붙인다. FAQ 박스처럼 사라질 수 있는 기능 하나를 위해 스키마를 급조하는 접근입니다. 정책이 바뀌면 그대로 무너집니다.
• 효과를 단정하는 표현을 넣는다. "무조건 좋아진다", "1위 병원" 같은 표현은 의료광고 리스크이자, 검색 품질 기준에서도 위험합니다. 스키마든 본문이든 마찬가지입니다.
• 막아 놓고 GEO를 기대한다. 중요한 페이지가 noindex거나 sitemap에서 빠진 채로 "왜 AI 검색에 안 나오냐"고 묻는 경우입니다.

리뉴얼·이전 때 특히 주의할 것

병원 사이트를 새로 만들거나 도메인을 옮길 때 구조화 데이터가 가장 많이 어긋납니다. 화면은 새로 그렸는데 스키마는 옛 정보가 남거나, 주소·전화·진료시간이 페이지마다 다르게 적히는 식입니다.

그래서 리뉴얼·이전 작업에서는 "어떤 URL에 어떤 사실이 있고, 그 사실이 화면과 스키마에서 일치하는가"를 함께 점검해야 합니다. URL 지도를 먼저 정리하는 이유와 같은 맥락입니다. 화면·스키마·sitemap이 같은 사실을 가리켜야 검색과 AI가 병원을 일관되게 이해합니다.

지금 바로 해볼 수 있는 점검표

• 병원명, 주소, 전화, 진료시간이 화면에 명확히 보인다
• 스키마에 적힌 값이 화면에 보이는 값과 정확히 같다
• 화면에 없는 정보를 스키마에만 넣지 않았다
• 중요한 페이지가 robots.txt·noindex로 막혀 있지 않다
• FAQ는 리치 결과가 아니라 환자 질문 정리 목적으로 유지한다
• 효과 단정·순위 보장 표현이 스키마와 본문에 없다
• 리뉴얼·이전 시 화면·스키마·sitemap이 같은 사실을 가리킨다

3개 이상 비어 있다면, 스키마를 더 붙이기 전에 화면과 사실부터 맞추는 편이 낫습니다.

결론: 스키마는 꼼수가 아니라 사실 정리다

구조화 데이터는 병원 노출을 사 주는 마법이 아닙니다. 순위도 리치 결과도 보장하지 않고, 2026년 FAQ 사례처럼 기능은 언제든 바뀝니다.

그래서 병원 사이트에서 구조화 데이터의 역할은 단순합니다. 우리 병원의 공개 가능한 사실을 사람과 기계 모두에게 오해 없이 전달하는 것입니다. 화면과 스키마가 같은 사실을 가리키고, 크롤러가 그 페이지를 읽을 수 있으면 기본기는 갖춰진 셈입니다.

CodeShift는 병원 콘텐츠를 발행량이 아니라, 검색·AI가 읽을 수 있는 구조와 매월 다시 확인하는 운영 루프로 봅니다. 구조화 데이터도 한 번 붙이고 끝내는 세팅이 아니라, 화면과 사실이 어긋나지 않는지 계속 점검하는 항목으로 관리합니다.

---

병원 사이트의 구조화 데이터와 원본 HTML이 검색·AI에 제대로 읽히는지 점검하고 싶다면, CodeShift에 문의해 주세요. 스키마를 얼마나 붙였는지보다, 화면과 사실이 일치하는 구조인지부터 확인합니다.