저는 다중 위치 의료 시스템, 단독 피부과 진료소 및 그 사이의 모든 것을 위한 의사 디렉토리 사이트를 구축했습니다. 의료 웹사이트에서 가장 큰 놓친 기회는 구조화된 데이터입니다. 일반적인 LocalBusiness 종류가 아니라 Google에 의료 제공자가 정확히 무엇을 하는지, 어디서 진료하는지, 환자들이 왜 그들을 신뢰해야 하는지를 알려주는 특정 Physician과 MedicalSpecialty 스키마 유형에 대해 이야기하고 있습니다.

대부분의 의료 진료소 웹사이트는 구조화된 데이터가 없거나, 더 나쁜 경우 심장학 진료소를 피자 가게처럼 취급하는 일부 WordPress 플러그인에서 생성한 잘못된 마크업으로 출시됩니다. 이 가이드는 심장학, 소아과, 비뇨기과, 정형외과 등 실제 의료 전문 분야를 위한 프로덕션 준비가 된 JSON-LD를 제공하며, 모든 속성 선택 뒤의 이유를 포함합니다.

목차

의료 진료소 스키마 마크업: 모든 의사 전문 분야를 위한 JSON-LD

2026년에 의료 스키마 마크업이 중요한 이유

Google의 AI Overviews가 이제 의료 검색을 지배합니다. 환자가 "내 근처에서 새 환자를 받는 심장전문의"를 검색할 때, Google은 더 이상 페이지 텍스트만 스캔하지 않습니다. 구조화된 데이터를 읽어 엔티티 관계를 구축하고, 지식 패널을 채우고, AI가 생성한 답변을 피드합니다.

적절한 의료 스키마 마크업이 트리거할 수 있는 것은 다음과 같습니다:

| 리치 결과 유형 | 트리거 요소 | 영향 || |---|---|---| | 리뷰 스니펫 | Physician의 AggregateRating | SERP의 별 평점 | | 지식 패널 | Physician + sameAs 링크 | 명명된 의사의 브랜드 존재감 | | 로컬 팩 개선 | MedicalClinic + openingHours | 지도 목록 세부정보 | | FAQ 리치 결과 | FAQPage 스키마(의료 사이트는 여전히 적격) | 확장된 SERP 실제 부동산 | | AI Overview 인용 | 완전한 엔티티 그래프 | AI 답변의 출처로 인용됨 |

2025 BrightLocal 연구에 따르면 리뷰 스니펫이 있는 의료 목록이 없는 목록보다 37% 더 높은 클릭률을 보았습니다. Schema App의 연구에서 완전한 구조화된 데이터가 있는 의사 페이지가 AI Overview 인용에 나타날 확률이 2.8배 더 높다는 것을 확인했습니다.

결론: 의사 페이지에 적절한 스키마 마크업이 없으면 가시성을 버리고 있습니다.

의료 진료소를 위한 Schema.org 유형

코드를 작성하기 전에 유형 계층 구조를 이해해봅시다. Schema.org는 의료와 관련된 여러 유형을 제공하며, 올바른 유형을 선택하는 것이 중요합니다.

Thing
└── Organization
    └── LocalBusiness
        └── MedicalBusiness
            ├── MedicalClinic
            ├── Optician
            ├── Pharmacy
            └── Physician

Physician은 MedicalBusiness의 하위 유형이며, 이는 LocalBusiness의 하위 유형입니다. 이것이 중요한 이유는 Physician 엔티티가 모든 로컬 비즈니스 속성(주소, 시간, 지리 좌표)을 상속받고 medicalSpecialty와 hospitalAffiliation 같은 의료 관련 속성을 추가로 받기 때문입니다.

단독 개업의의 웹사이트의 경우 Physician이 기본 유형입니다. 다중 제공자 클리닉의 경우, MedicalClinic 또는 MedicalOrganization을 상위 엔티티로 원하며 개별 Physician 항목이 중첩되거나 member를 통해 링크되거나 별도 페이지에서 참조됩니다.

각각을 언제 사용할지

귀사의 설정 기본 유형 보조 유형
단독 의사, 한 위치 Physician MedicalOrganization(선택사항)
그룹 진료, 단일 위치 MedicalClinic 제공자당 Physician
의료 시스템, 다중 위치 MedicalOrganization 위치당 MedicalClinic, 제공자당 Physician
병원 Hospital Physician, MedicalClinic(부서)

MedicalSpecialty 열거형 값 이해하기

medicalSpecialty 속성은 Schema.org의 MedicalSpecialty 열거형 값을 허용합니다. 이들은 자유 텍스트 필드가 아니라 특정하고 미리 정의된 값입니다. 가장 자주 사용할 값들은 다음과 같습니다:

전문 분야 Schema.org 값 주석
심장학 Cardiovascular 심장학 및 심혈관 수술 포함
소아과 Pediatric 일반 소아과
비뇨기과 Urologic 소아 비뇨기과 포함
피부과 Dermatology DermatologyLaserSurgery 변형도 있음
정형외과 Musculoskeletal 정형외과 수술이 여기에 해당
신경과 Neurological Psychiatric과는 별개
산부인과 Obstetric 및/또는 Gynecologic 둘 다 명시할 수 있음
응급의학 Emergency ER 의사
가정의학 PrimaryCare 일반진료, 가정의학
종양학 Oncologic 암 치료
폐과 Pulmonary 폐 및 호흡기
위장병학 Gastroenterologic 위장 전문의
내분비학 Endocrine 당뇨병, 갑상선 등
안과 Optometric 안과 진료
정신과 Psychiatric 정신 건강 의사

전체 목록은 schema.org/MedicalSpecialty에서 볼 수 있습니다. 일부 전문 분야는 예상보다 더 넓은 범주에 매핑됩니다. 예를 들어 별도의 "중재적 심장학" 값이 없습니다. Cardiovascular를 사용하고 의사의 description 또는 knowsAbout 속성에서 세부 전문 분야를 설명합니다.

의료 진료소 스키마 마크업: 모든 의사 전문 분야를 위한 JSON-LD - 아키텍처

기본 의사 JSON-LD 템플릿

모든 의사 페이지를 위한 견고한 시작 템플릿입니다. 주요 결정사항에 주석을 달겠습니다.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Physician",
  "@id": "https://example.com/doctors/jane-smith#physician",
  "name": "Dr. Jane Smith, MD, FACC",
  "image": "https://example.com/images/dr-jane-smith.jpg",
  "url": "https://example.com/doctors/jane-smith",
  "telephone": "+1-555-867-5309",
  "description": "Board-certified cardiologist specializing in interventional cardiology and structural heart disease with 15 years of clinical experience.",
  "medicalSpecialty": "https://schema.org/Cardiovascular",
  "isAcceptingNewPatients": true,
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "450 Heart Center Drive, Suite 200",
    "addressLocality": "Austin",
    "addressRegion": "TX",
    "postalCode": "78701",
    "addressCountry": "US"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 30.2672,
    "longitude": -97.7431
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "08:00",
      "closes": "17:00"
    }
  ],
  "sameAs": [
    "https://www.healthgrades.com/physician/dr-jane-smith",
    "https://www.doximity.com/pub/jane-smith-md",
    "https://www.linkedin.com/in/drjanesmith"
  ],
  "alumniOf": {
    "@type": "CollegeOrUniversity",
    "name": "Johns Hopkins University School of Medicine"
  },
  "hasCredential": [
    {
      "@type": "EducationalOccupationalCredential",
      "credentialCategory": "Board Certification",
      "name": "American Board of Internal Medicine - Cardiovascular Disease"
    }
  ],
  "hospitalAffiliation": {
    "@type": "Hospital",
    "name": "St. David's Medical Center",
    "url": "https://stdavids.com"
  },
  "worksFor": {
    "@type": "MedicalOrganization",
    "@id": "https://example.com/#organization",
    "name": "Austin Heart Specialists"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.8",
    "reviewCount": "142",
    "bestRating": "5"
  }
}
</script>

몇 가지를 강조하고 싶습니다:

  • @id: 이 엔티티에 대한 고유 식별자를 생성합니다. 페이지 URL과 프래그먼트를 사용하세요. 이는 페이지 전체에서 의사와 조직을 연결할 때 중요해집니다.
  • medicalSpecialty: 문자열만 사용하는 것이 아니라 전체 URL 형식(https://schema.org/Cardiovascular)을 사용합니다. 둘 다 작동하지만 URL 형식이 더 명시적입니다.
  • isAcceptingNewPatients: Physician에만 해당하는 새로운 속성입니다. 이를 사용하세요. 환자들이 끊임없이 검색합니다.
  • sameAs: 확인된 제3자 프로필로 링크하세요. 이것이 Google이 엔티티 신뢰도를 구축하고 잠재적으로 지식 패널을 트리거하는 방법입니다.
  • aggregateRating: 페이지에서 리뷰를 시각적으로 표시하는 경우에만 포함합니다. Google의 지침은 이에 엄격합니다. 숨겨진 평점은 정책을 위반합니다.

전문 분야별 JSON-LD 예제

사람들이 실제로 검색하는 전문 분야에 대한 예제를 구축해봅시다.

심장학(심혈관)

{
  "@context": "https://schema.org",
  "@type": "Physician",
  "name": "Dr. Robert Chen, MD, FACC",
  "medicalSpecialty": "https://schema.org/Cardiovascular",
  "knowsAbout": [
    "Interventional Cardiology",
    "Cardiac Catheterization",
    "Coronary Artery Disease",
    "Heart Failure Management",
    "Echocardiography"
  ],
  "availableService": [
    {
      "@type": "MedicalProcedure",
      "name": "Cardiac Catheterization",
      "procedureType": "https://schema.org/PercutaneousProcedure"
    },
    {
      "@type": "MedicalTest",
      "name": "Stress Echocardiography"
    },
    {
      "@type": "MedicalTest",
      "name": "Electrocardiogram (ECG/EKG)"
    }
  ]
}

availableService 속성은 Physician에만 해당하며 정확한 절차와 검사를 지정할 수 있게 합니다. 심장학의 경우 MedicalProcedure와 MedicalTest 사이의 이러한 구분은 중재술 대 진단 분할에 자연스럽게 매핑됩니다.

소아과

{
  "@context": "https://schema.org",
  "@type": "Physician",
  "name": "Dr. Maria Gonzalez, MD, FAAP",
  "medicalSpecialty": "https://schema.org/Pediatric",
  "knowsAbout": [
    "Well-Child Visits",
    "Childhood Immunizations",
    "Developmental Screening",
    "Adolescent Medicine",
    "Newborn Care"
  ],
  "availableService": [
    {
      "@type": "MedicalTherapy",
      "name": "Pediatric Vaccination Program"
    },
    {
      "@type": "MedicalTest",
      "name": "Developmental Milestone Assessment"
    }
  ],
  "hasCredential": [
    {
      "@type": "EducationalOccupationalCredential",
      "credentialCategory": "Board Certification",
      "name": "American Board of Pediatrics"
    }
  ]
}

소아과는 흥미로운데, MedicalSpecialty 값은 단순히 Pediatric입니다. 소아 심장학과 같은 소아 세부 전문의에 대한 별도의 값이 없습니다. 소아 심장전문의의 경우, 두 전문 분야를 모두 포함합니다:

"medicalSpecialty": [
  "https://schema.org/Pediatric",
  "https://schema.org/Cardiovascular"
]

네, medicalSpecialty는 배열을 허용합니다. 사용하세요.

비뇨기과

{
  "@context": "https://schema.org",
  "@type": "Physician",
  "name": "Dr. Michael Torres, MD, FACS",
  "medicalSpecialty": "https://schema.org/Urologic",
  "knowsAbout": [
    "Robotic-Assisted Surgery",
    "Prostate Cancer Treatment",
    "Kidney Stone Management",
    "Urinary Incontinence",
    "Male Infertility"
  ],
  "availableService": [
    {
      "@type": "MedicalProcedure",
      "name": "Robot-Assisted Laparoscopic Prostatectomy",
      "procedureType": "https://schema.org/SurgicalProcedure"
    },
    {
      "@type": "MedicalProcedure",
      "name": "Extracorporeal Shock Wave Lithotripsy (ESWL)",
      "procedureType": "https://schema.org/NoninvasiveProcedure"
    },
    {
      "@type": "MedicalTest",
      "name": "Cystoscopy"
    }
  ]
}

정형외과

{
  "@context": "https://schema.org",
  "@type": "Physician",
  "name": "Dr. Sarah Kim, MD",
  "medicalSpecialty": "https://schema.org/Musculoskeletal",
  "knowsAbout": [
    "Total Joint Replacement",
    "Sports Medicine",
    "Arthroscopic Surgery",
    "Fracture Care",
    "Rotator Cuff Repair"
  ],
  "availableService": [
    {
      "@type": "MedicalProcedure",
      "name": "Total Knee Arthroplasty",
      "procedureType": "https://schema.org/SurgicalProcedure"
    },
    {
      "@type": "MedicalProcedure",
      "name": "Arthroscopic ACL Reconstruction",
      "procedureType": "https://schema.org/SurgicalProcedure"
    }
  ]
}

medicalSpecialty 값이 "Orthopedic"이 아니라 Musculoskeletal임을 주목하세요. 이것이 사람들을 끊임없이 헷갈리게 합니다.

MedicalOrganization과 MedicalClinic 스키마

조직 수준의 스키마가 기반입니다. 모든 의사 엔티티는 이에 참조해야 합니다. 다음은 완전한 MedicalClinic 예제입니다:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "MedicalClinic",
  "@id": "https://example.com/#clinic",
  "name": "Austin Heart Specialists",
  "url": "https://example.com",
  "logo": "https://example.com/images/logo.png",
  "image": "https://example.com/images/clinic-exterior.jpg",
  "telephone": "+1-555-867-5309",
  "medicalSpecialty": "https://schema.org/Cardiovascular",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "450 Heart Center Drive",
    "addressLocality": "Austin",
    "addressRegion": "TX",
    "postalCode": "78701",
    "addressCountry": "US"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 30.2672,
    "longitude": -97.7431
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "07:30",
      "closes": "17:30"
    }
  ],
  "availableService": [
    {
      "@type": "MedicalTest",
      "name": "Cardiac Stress Testing"
    },
    {
      "@type": "MedicalProcedure",
      "name": "Cardiac Catheterization"
    }
  ],
  "member": [
    {
      "@type": "Physician",
      "@id": "https://example.com/doctors/jane-smith#physician"
    },
    {
      "@type": "Physician",
      "@id": "https://example.com/doctors/robert-chen#physician"
    }
  ],
  "sameAs": [
    "https://www.facebook.com/austinheartspecialists",
    "https://www.google.com/maps/place/?q=place_id:ChIJ_____"
  ]
}
</script>

member 배열은 @id 참조를 사용하여 개별 페이지에서 정의된 의사 엔티티로 링크합니다. 이는 Google이 탐색할 수 있는 연결된 그래프를 만듭니다.

의사와 조직 연결하기

이것이 대부분의 구현이 실패하는 부분입니다. 양방향 참조가 필요합니다:

  1. 조직 → 의사: 조직 페이지에서 member 사용
  2. 의사 → 조직: 의사 페이지에서 worksFor 사용

둘 다 같은 @id를 참조해야 합니다. 데이터베이스의 외래 키처럼 생각하세요. ID가 일치하지 않으면 Google이 그들을 연결할 수 없습니다.

// 의사 페이지에서:
"worksFor": {
  "@type": "MedicalClinic",
  "@id": "https://example.com/#clinic",
  "name": "Austin Heart Specialists"
}

// 조직 페이지에서:
"member": [
  {
    "@type": "Physician",
    "@id": "https://example.com/doctors/jane-smith#physician"
  }
]

다중 위치 진료소의 경우, 각 위치는 자체 @id가 있는 별도의 MedicalClinic 엔티티여야 하며, 여러 위치에서 진료하는 의사는 worksFor 대신 practicesAt(배열)을 사용해야 합니다.

Headless CMS 플랫폼에서 이러한 사이트를 구축하는 경우, 이러한 관계형 데이터 모델링은 Sanity나 Contentful 같은 시스템의 콘텐츠 참조에 완벽하게 매핑됩니다. 우리는 헤드리스 CMS 개발 작업에서 이 정확한 패턴을 처리합니다. CMS 콘텐츠 모델이 schema.org 엔티티 그래프를 반영합니다.

E-E-A-T를 구축하는 속성

Google의 품질 평가자들은 YMYL(Your Money or Your Life) 콘텐츠에 대해 경험, 전문성, 권위성 및 신뢰성을 평가합니다. 의료는 전형적인 YMYL 범주입니다. 이러한 스키마 속성은 E-E-A-T 신호를 직접 지원합니다:

속성 유형 E-E-A-T 신호
hasCredential EducationalOccupationalCredential 전문성
alumniOf CollegeOrUniversity 전문성
memberOf Organization 권위성
hospitalAffiliation Hospital 권위성, 신뢰
award Text 권위성
knowsAbout Text 또는 Thing 전문성
medicalSpecialty MedicalSpecialty 전문성
sameAs URL 신뢰(교차 참조 검증)
aggregateRating AggregateRating 신뢰(사회적 증명)

중요한 규칙: 페이지에 표시되는 콘텐츠만 마크업할 수 있습니다. 의사 프로필 페이지에 어디에도 표시하지 않으면서 스키마에 자격증을 나열하면 Google의 구조화된 데이터 지침을 위반합니다. 먼저 콘텐츠를 추가한 후 마크업하세요.

검증 및 테스트

프로덕션에 푸시하기 전에:

  1. Google Rich Results Test (search.google.com/test/rich-results): 리치 결과 적격성 검증
  2. Schema Markup Validator (validator.schema.org): Schema.org 어휘에 대한 구문 및 준수 확인
  3. Google Search Console: 배포 후 "Enhancements" 섹션에서 오류 모니터링

다음은 테스트 워크플로우입니다:

# 프로그래매틱으로 스키마를 생성하는 경우(Next.js, Astro 등)
# JSON을 파일로 출력하고 먼저 로컬에서 검증합니다
node -e "const schema = require('./generate-schema.js'); console.log(JSON.stringify(schema, null, 2))" > schema-output.json

# 그런 다음 validator.schema.org에 붙여넣거나 API 사용

Next.js나 Astro로 빌드하는 경우, CMS 데이터에서 이러한 JSON-LD 블록을 동적으로 생성할 수 있습니다. 두 프레임워크 모두 <script type="application/ld+json"> 주입을 깔끔하게 처리합니다. Next.js는 <Script> 컴포넌트나 next/head를 통해, Astro는 <head> 슬롯을 통해 처리합니다.

피해야 할 일반적인 실수

Physician 대신 일반 LocalBusiness 사용. 모든 의료 관련 속성을 잃게 됩니다. Physician은 LocalBusiness이므로 LocalBusiness가 제공하는 모든 것과 더 많은 것을 얻습니다.

자유 텍스트 medicalSpecialty 값 사용. 적절한 열거형 값(Cardiovascular) 대신 "medicalSpecialty": "Cardiology"를 작성하면 Google이 전문 분야를 올바르게 이해하지 못할 수 있습니다.

지리 좌표 누락. 위도/경도 데이터는 Google이 위치 기반 쿼리와 진료소를 연결하는 데 도움이 됩니다. 이를 건너뛰지 마세요.

다른 엔티티 간 @id 값 중복. 모든 엔티티에는 고유한 @id가 필요합니다. 모든 의사가 같은 @id 접미사를 공유하는 구현을 보았는데, 이는 엔티티 그래프를 완전히 끊습니다.

페이지에 없는 콘텐츠 마크업. 이것을 반복합니다. Google의 지침은 명확합니다: 구조화된 데이터의 모든 것이 표시되는 콘텐츠에 대응해야 합니다. 위반은 수동 조치로 이어질 수 있습니다.

isAcceptingNewPatients 무시. 이것은 높은 의도 신호입니다. 환자들이 필터링합니다. 포함하고 업데이트된 상태로 유지하세요.

자주 묻는 질문

Physician과 MedicalBusiness 스키마 유형의 차이점은 무엇입니까? Physician은 MedicalBusiness의 하위 유형입니다. 개별 제공자 페이지에는 Physician, 진료소 자체에는 MedicalBusiness(또는 더 구체적으로 MedicalClinic)를 사용하세요. Physician은 MedicalBusiness의 모든 속성을 상속받고 hospitalAffiliation, availableService 및 isAcceptingNewPatients 같은 의사 관련 속성을 추가합니다.

한 의사에 대해 여러 의료 전문 분야를 나열할 수 있습니까? 그렇습니다. medicalSpecialty 속성은 배열을 허용합니다. 소아과와 심혈관 전공 의사는 둘 다 나열할 수 있습니다: "medicalSpecialty": ["https://schema.org/Pediatric", "https://schema.org/Cardiovascular"]. 이는 이중 자격증을 가진 의사에게 일반적입니다.

의료 스키마 마크업이 Google 순위를 직접 향상시킵니까? 구조화된 데이터는 직접적인 순위 요소가 아닙니다. 그러나 리치 결과(별 평점, FAQ 드롭다운, 지식 패널)를 활성화하여 클릭률을 크게 향상시킵니다. 또한 Google의 엔티티 이해를 담당하며, 이는 진료소가 AI Overviews와 로컬 팩 결과에 나타나는 방식에 영향을 줍니다. 간접적인 SEO 영향은 상당합니다.

병원의 의사 디렉토리에 어떤 스키마 유형을 사용해야 합니까? Hospital을 최상위 엔티티로, MedicalClinic을 개별 부서(예: 심장학부)로, Physician을 각 제공자 페이지로 사용하세요. member, worksFor 및 department 속성으로 연결하세요. 이는 완전한 조직 그래프를 만듭니다.

JSON-LD가 의료 스키마 마크업의 유일한 형식입니까? 아닙니다. Microdata나 RDFa를 HTML에 포함시킬 수도 있습니다. 하지만 Google은 명시적으로 JSON-LD를 권장하며 모든 설명서 예제에서 사용합니다. JSON-LD는 또한 페이지 레이아웃과 분리되어 있기 때문에 유지 관리가 훨씬 쉽습니다. CMS 데이터에서 프로그래매틱으로 생성할 수 있고 템플릿을 건드릴 필요가 없습니다.

의사가 여러 위치에서 진료하는 경우를 어떻게 처리합니까? practicesAt 속성을 각각 자체 @id를 가진 MedicalClinic 또는 Hospital 엔티티의 배열로 사용하세요. 의사 엔티티를 위치 전체에 복제하지 마세요. 하나의 표준 Physician 엔티티를 생성하고 여러 진료소에 링크하세요. 각 위치의 스키마는 또한 member를 통해 의사를 참조해야 합니다.

의사 스키마에 환자 리뷰를 포함해야 합니까? 의사 페이지에 리뷰가 시각적으로 표시되는 경우에만 포함하세요. Physician 유형에 aggregateRating 속성을 사용하고 ratingValue, reviewCount 및 bestRating을 포함합니다. Google은 이를 진지하게 받아들입니다. 숨겨진 리뷰나 가짜 리뷰를 마크업하면 수동 페널티로 이어질 수 있습니다. Healthgrades 같은 제3자 플랫폼을 통해 리뷰를 수집하는 경우, sameAs를 통해 링크하세요.

의료 진료소 스키마 마크업을 얼마나 자주 업데이트해야 합니까? 기본 정보가 변경될 때마다 구조화된 데이터를 업데이트하세요: 새로운 진료 시간, 의사 퇴직 또는 입사, 제공자가 더 이상 새 환자를 받지 않음, 또는 연락처 정보 변경. Headless CMS를 사용하고 동적 스키마 생성을 하는 진료소의 경우, 편집자가 CMS를 업데이트할 때 자동으로 발생합니다. JSON-LD를 하드코딩하는 경우, 최소한 분기별 검토 일정을 설정하세요. 오래된 구조화된 데이터(특히 부정확한 isAcceptingNewPatients 또는 telephone 값)는 Google과 환자 모두와의 신뢰를 침식합니다.