医療実践スキーママークアップ: すべての医師専門職向けJSON-LD
多くの場所を持つ医療システム、単独の皮膚科診療所、そしてその間のすべてについて、医師ディレクトリサイトを構築してきました。医療ウェブサイト全体で見かける最大の見落とされた機会は構造化データです。汎用的なLocalBusinessの種類ではなく、医師が何をするのか、どこで診療するのか、患者がなぜ彼らを信頼すべきなのかを正確にGoogleに伝えるPhysicianとMedicalSpecialtyスキーマタイプについて話しています。
ほとんどの医療診療所ウェブサイトはスキーママークアップなしで公開されるか、さらに悪いことに、心臓病学診療所をピザ屋と同じに扱うWordPressプラグインによって生成された不正なマークアップが付属しています。このガイドは、心臓病学、小児科、泌尿器科、整形外科など実際の医療専門職向けの本番環境対応のJSON-LDを提供します。また、すべての属性選択の背景にある理由も説明します。
目次
- 2026年に医療スキーママークアップが重要な理由
- 医療実践向けのSchema.orgタイプ
- MedicalSpecialty列挙値の理解
- 基本的な医師JSON-LDテンプレート
- 専門職別JSON-LDの例
- MedicalOrganizationとMedicalClinicスキーマ
- 医師を組織に接続する
- E-E-A-Tを構築する属性
- 検証とテスト
- 避けるべき一般的な間違い
- よくある質問
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を経由して参照するか、別ページで参照します。
何をどんなときに使うか
| あなたのセットアップ | プライマリタイプ | セカンダリタイプ |
|---|---|---|
| ソロドクター、1つの場所 | Physician |
MedicalOrganization(オプション) |
| グループ診療、1つの場所 | 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 |
GI専門医 |
| 内分泌科 | Endocrine |
糖尿病、甲状腺など |
| 眼科 | Optometric |
眼科ケア |
| 精神医学 | Psychiatric |
メンタルヘルス医師 |
完全なリストはschema.org/MedicalSpecialtyで利用可能です。一部の専門職は予想より広いカテゴリーにマップされています。例えば、「介入心臓病学」の個別値がなく、Cardiovascularを使用して医師のdescriptionまたはknowsAbout属性で専門分科について説明します。
基本的な医師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: 検証済みのサードパーティプロフィールにリンクします。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が走査できる接続されたグラフを作成します。
医師を組織に接続する
ほとんどの実装がここで崩壊します。双方向参照が必要です:
- 組織→医師: 組織ページで
memberを使用 - 医師→組織: 医師ページで
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"
}
]
複数の場所での診療の場合は、practicesAt(配列)を使用します。各場所が独自の@idを持つMedicalClinicまたはHospitalエンティティの配列の代わりに。複数の場所で診療する医師を複製しないでください。1つの正規のPhysicianエンティティを作成し、複数の診療場所にリンクしてください。各場所のスキーマはmemberを経由して医師も参照する必要があります。
複数の場所の診療所を使用してサイトを構築している場合、このような関連データモデリングはSanityまたはContentfulのようなシステムのコンテンツ参照に完全にマップされます。スキーマ.orgエンティティグラフをミラーリングするCMSコンテンツモデル。
E-E-A-Tを構築する属性
Googleの品質レーターは、YMYLコンテンツ(あなたのお金またはあなたの人生)について、経験、専門知識、権威、信頼を評価します。医療は典型的な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の構造化データガイドラインに違反しています。最初にコンテンツを追加し、次にマークアップしてください。
検証とテスト
本番環境にプッシュする前に:
- Googleリッチリザルトテスト(search.google.com/test/rich-results): リッチリザルト対象かどうかを検証
- スキーママークアップバリデーター(validator.schema.org): Schema.orgボキャブラリへの構文とコンフォーマンスをチェック
- 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で構築している場合、これらのJSON-LDブロックをCMSデータから動的に生成できます。両フレームワークは<script type="application/ld+json">注入をクリーンに処理します。Next.jsは<Script>コンポーネントまたはnext/headを経由、Astroは<head>スロットを経由。
避けるべき一般的な間違い
医師の代わりに汎用LocalBusinessを使用する。 すべての医療固有の属性を失います。PhysicianはLocalBusinessなので、LocalBusinessが提供するすべてと それ以上を取得します。
自由形式のmedicalSpecialty値を使用する。 適切な列挙値(Cardiovascular)の代わりに"medicalSpecialty": "Cardiology"を書く場合、Googleは専門職を正しく理解できない可能性があります。
地理座標の緯度経度を見逃す。 Lat/longデータは、Googleが診療所を位置情報ベースのクエリに関連付けるのに役立ちます。スキップしないでください。
異なるエンティティ全体で重複する@id値。 すべてのエンティティには一意の@idが必要です。すべての医師が同じ@idサフィックスを共有する実装を見ました。それはエンティティグラフを完全に壊します。
ページに表示されていないコンテンツをマークアップする。 これは繰り返す価値があります。Googleのガイドラインは明確です: 構造化データのすべてはページの目に見えるコンテンツに対応する必要があります。違反は手動操作につながる可能性があります。
isAcceptingNewPatientsを無視する。 これは高い意図信号です。患者はそれでフィルターします。含めて更新し続けてください。
よくある質問
医師とMedicalBusinessスキーマタイプの違いは何ですか?
PhysicianはMedicalBusinessのサブタイプです。個々のプロバイダーページにはPhysicianを使用し、実践自体にはMedicalBusiness(より具体的にはMedicalClinic)を使用してください。PhysicianはMedicalBusinessからすべての属性を継承し、hospitalAffiliation、availableService、isAcceptingNewPatientsのような医師固有のものを追加します。
1つの医師に複数の医療専門職をリストできますか?
はい。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エンティティの配列で使用してください。複数の場所で医師エンティティを複製しないでください。1つの正規のPhysicianエンティティを作成し、複数の診療場所にリンクしてください。各場所のスキーマもmemberを経由して医師を参照する必要があります。
医師スキーマに患者レビューを含める必要がありますか?
医師ページに表示されている場合のみ。医師タイプにaggregateRating属性を使用し、ratingValue、reviewCount、bestRatingを含めます。Google はこれを真摯に受け取ります。非表示または虚偽のレビューをマークアップすると、手動ペナルティが発生する可能性があります。Healthgrades のようなサードパーティプラットフォーム経由でレビューを収集する場合は、代わりにsameAsを経由してリンクしてください。
医療診療スキーママークアップはどのくらいの頻度で更新する必要がありますか?
スキーマは基になる情報が変更されたときは常に更新してください: 新しい営業時間、医師が去るまたは参加する、プロバイダーが新規患者を受け入れなくなった、または連絡先情報が変わった場合。ヘッドレス CMS で動的スキーマ生成を使用する診療所は、コンテンツ編集者が CMS を更新すると自動的に発生します。JSON-LD をハードコーディングしている場合は、最低でも四半期のレビューサイクルを設定してください。古い構造化データ、特に不正確なisAcceptingNewPatientsまたはtelephone値は、Google と患者の両方からの信頼を低下させます。