歯科医院ホームページの構造化データ入門――Dentist・MedicalClinic・診療時間・予約情報を機械可読に整える

歯科医院で構造化データが必要な理由：ページ内容を検索エンジンに理解させる

歯科医院の構造化データは、医院名・住所・電話番号・診療時間など、ページ上にすでに書かれている情報を標準形式で記述し、検索エンジンによるページ理解を補助するための記述です。地図サービスや各種AI検索への反映、露出の向上が保証されるものではありません。

Google Search Central の LocalBusiness ガイドでは、ローカルビジネス向けに営業時間、部門、クチコミなどを構造化データで伝達できるとしています。一方で、構造化データの一般ガイドラインでは、リッチリザルトテストに沿って正しくマークアップしても検索結果への表示は保証されないと明記され（「Google does not guarantee that your structured data will show up in search results」）、マークアップはページ上でユーザーに見える内容と一致し、最新であることが前提とされています。

AI検索への表示や引用を構造化データだけで保証する公式仕様はありません。できるのは、医院の名称・所在地・診療時間・サービス・予約ページの所在を、ページ本文と矛盾しない形で機械可読に記述することまでです。サイト全体の患者導線設計とあわせて考えると効果が出やすく、歯科医院ホームページ改善の考え方で扱う情報設計・予約導線の見直しと一体で進めるのが実務的です。

まず統一する5項目：医院名・住所・電話番号・診療時間・予約URL

構造化データを書く前に、医院サイト・Googleビジネスプロフィール（GBP）・予約システムで表記をそろえるべき5項目があります。これは検索順位の要件ではなく、更新漏れと患者の混乱を防ぐための運用上の統一です。Google の LocalBusiness 仕様では、name と address が必須プロパティで、URL や診療時間などの推奨プロパティを追加できます（LocalBusiness の構造化データ）。

• 医院名（name）：正式名称をサイト表示・構造化データ・GBPで一致させる
• 住所（address）：PostalAddress で可能な限り詳細に記述する
• 電話番号（telephone）：ハイフン有無を含め院外公開番号を統一する（表記ゆれによる患者の誤解を防ぐため）
• 診療時間（openingHoursSpecification）：曜日・開始・終了を同じ内容で公開する
• 予約URL：実際に予約を完了できる拠点専用ページへ直結させる

位置情報を入れる場合、Google の LocalBusiness 仕様は緯度経度について「The precision must be at least 5 decimal places.」として小数点以下5桁以上の精度を求めています（LocalBusiness の構造化データ）。住所表記が「〇丁目」と「-」混在、電話が院内内線、診療時間が「午前／午後」だけで時刻がない、といったズレは、構造化データの前に直すべき表記ゆれです。

予約URLはサイト内のボタン文言だけでなく、到達先ページの中身まで揃えます。途中離脱が多いフォームや空き枠の見せ方は、Web予約の途中離脱を減らす設計とあわせて点検すると、構造化データの「正しいURL」を活かせます。

DentistとMedicalClinicの使い分け：歯科医院サイトの基本設計

実在する歯科医院の拠点を表す基本タイプは、schema.org の Dentist です。Dentist は LocalBusiness・MedicalBusiness・MedicalOrganization を継承し、「歯科医」を表すタイプとして定義されています。

歯科以外も含む診療施設を表す場合は、MedicalClinic の利用余地があります。MedicalClinic も LocalBusiness・MedicalBusiness・MedicalOrganization を継承し、診断・医療提供に特化した施設を表します。なお availableService は、domainIncludes として Hospital・MedicalClinic・Physician が定義されており、Dentist は含まれていません。

型は診療メニューの多さや訴求内容ではなく、そのページが表す実在の組織・施設の種類に合わせて選びます。単独の歯科医院であれば Dentist を基本型にし、name・address・telephone・診療時間・URL を正確に載せる方が実態に合います。タイプ選定より先に、ページ上の事実と一致しているかが重要です。

実装する構造化データの項目：診療メニュー・医師・口コミ・予約情報まで

基本5項目を固めたら、次に拡張する実装項目を整理します。以下は優先順位ではなく実装例で、形式は Google が推奨する JSON-LD が扱いやすいです。テスト合格＝表示保証ではない点は、実装前にチームで共有しておきましょう。

1. @type（Dentist または MedicalClinic）：施設実態に合う型を選ぶ
2. name / address / telephone / url：基本の識別情報（name・address は必須）
3. geo：緯度経度を小数点以下5桁以上で
4. openingHoursSpecification：曜日・opens・closes
5. specialOpeningHoursSpecification：臨時休診・祝日・年末年始
6. 診療メニュー（availableService 等）：MedicalClinic 利用時は MedicalProcedure 等
7. 医師・スタッフ情報：ページ上に公開している内容と同じ事実に限る（掲載可否は医療広告ガイドラインで別途確認）
8. 口コミ（aggregateRating）：自院サイトでの付与は慎重に扱う

診療時間の書き方

OpeningHoursSpecification では、dayOfWeek・opens・closes で診療時間を表現できます。validFrom / validThrough を使えば期間限定の時間も記述できます。昼休みで午前・午後が分かれる医院は、同じ曜日に複数の時間帯を並べる設計が一般的です。

臨時休診や祝日診療は、Dentist 定義上、specialOpeningHoursSpecification が通常の openingHoursSpecification（または openingHours）を明示的に上書きする用途です。休診のお知らせをブログやお知らせ欄に出しただけでは、構造化データ側は古いまま残ることがあるため、告知と同時更新が必要です。

診療メニューと医師情報

MedicalClinic の availableService は MedicalProcedure・MedicalTest・MedicalTherapy を値に取れます。MedicalProcedure は診断・治療・予防・緩和のための医療プロセスとして定義されます。保険診療・自費の区別を構造化データだけで過度に訴求せず、ページ本文の説明と一致する範囲で「何を提供している医院か」を示す補助的な記述に留めます。

医師・スタッフ情報を載せる場合も、記述はページ上の公開プロフィールと同じ事実に揃えます。構造化データはページ上の広告可能事項を超えてよいものではなく、効果保証や誇大な表現は避ける必要があります（厚生労働省・医療広告規制の資料では、絶対安全な手術等は医学上あり得ないため虚偽広告として取り扱うとされています）。資格・専門性の表示や比較優良表現、治療前後写真、限定解除要件などは論点が多いため、掲載可否は厚生労働省の医療広告ガイドラインおよびウェブサイト事例解説書に照らして個別に確認してください。

予約情報の載せ方

ScheduleAction や potentialAction は schema.org 語彙上の任意の記述で、予約ページURLを関連付けること自体は可能です。ただし Google Search Central の LocalBusiness 仕様には、これらが必須・推奨プロパティとして掲載されておらず、Google検索やGBP上での表示効果は確認されていません。同ページは、検索結果から直接予約や注文をさせたい場合は Maps Booking API を使うよう案内しています。

また、「Google上で予約が完結する仕組み」と「GBPから外部の予約ページへ遷移するリンク」は別機能です。前者・後者いずれも Actions Center の統合が関わり、たとえば Appointments Redirect は、利用者がGoogle検索・マップで事業者を見つけ、予約自体は事業者側のサイトで行う方式と説明されています。参加は医院単独ではなく予約システム側のパートナー単位で、対象要件として事業者情報がGoogleマップのデータと一致することなどが挙げられ、稼働する国やカテゴリも限定されています。予約プロバイダを使わない場合の予約リンクは、GBPの管理画面から追加する運用機能です。

口コミ（aggregateRating）の注意

医院が自院サイトに口コミを掲載するだけの場合、LocalBusiness の aggregateRating をリッチリザルト目的で付与することは慎重に扱うべきです。Google は当該プロパティを、他のローカルビジネスの口コミを収集するサイト向けとして整理しています。あわせて、医療広告ガイドラインでは、患者その他の者の主観又は伝聞に基づく治療等の内容・効果に関する体験談の広告が禁止事項とされています。自院サイトへの体験談掲載は「誇大でなければ安全」とは言えないため、掲載可否は同ガイドラインとウェブサイト事例解説書に照らして個別に確認してください。

Googleビジネスプロフィールと予約システムの整合性を確認するチェックリスト

構造化データ単体を整える前に、「サイト × GBP × 予約システム」の三点で情報が一致しているかを点検します。

• 医院名の正式表記（法人名併記の有無を含む）が三者で一致しているか
• 住所の番地・建物名が省略なく一致しているか
• 公開電話番号が予約システムや自動音声案内と矛盾していないか
• 診療時間・休診日がサイト本文・JSON-LD・GBPで同時更新されているか
• 予約URLが「医院・拠点専用」かつ予約完了まで到達できるか
• ログイン必須・CAPTCHA・クローラー遮断・エラーページになっていないか

Googleビジネスプロフィールの予約リンク案内では、プロフィールに予約リンクを追加でき、同一カテゴリに複数リンクがある場合は優先リンクを指定できるとされています。また、ビジネスリンクのポリシーでは、リンクは医院・拠点専用ページへ遷移し、予約行為を完了可能で、Google の検証クローラーがログイン・CAPTCHA・アクセス遮断なしに到達できる必要があるとされています。検証は最大で1日1回行われる場合があり、要件を満たさないリンクは削除される可能性があります。

リッチリザルトテストで検証する手順と、よくある5つのエラー

実装後は、公開前に検証ツールで確認します。Google Search Central の構造化データ案内では、Google 固有のリッチリザルト適格性は Rich Results Test、schema.org 全般の語彙上の妥当性は Schema Markup Validator を使うと整理されています。前者はGoogleが対応する機能としての適格性検査、後者は語彙の検証であり、役割が違うため片方だけで「完了」にしないことがポイントです。

検証の実務手順

1. ステージングまたは公開URLで JSON-LD を配置する
2. Rich Results Test にURLまたはコードを投入し、Google が対応するリッチリザルトとして検出されるか、エラーがあるかを確認する
3. Schema Markup Validator で型やプロパティの記述ゆれを確認する
4. ページを目視し、マークアップ内容が画面上の主コンテンツと一致するか確認する
5. Search Console のURL検査で取得状況を必要に応じて確認する
6. GBPの予約リンク・NAP・診療時間を再照合する

よくある5つのエラー

1. 必須プロパティ不足：name または address が欠けている、住所が PostalAddress として分解されていない
2. 表示内容との不一致：ページは土曜午後休診なのに構造化データが終日診療のまま
3. geo の精度不足：小数点以下5桁未満、または別住所の座標を流用
4. 予約URLの到達不可：ログイン壁・CAPTCHA・医院一覧のハブページ止め
5. 口コミ・評価の不適切な付与：自院サイトだけで aggregateRating をリッチリザルト目的に付ける

テストに合格しても表示は保証されません。ガイドライン上も、構造化データはユーザーに見える主コンテンツを正確に表し、最新情報であることが求められます。エラーゼロはゴールではなく、公開情報とマークアップが一致しているかの確認です。

更新漏れを防ぐ運用ルール：休診・診療時間変更・ページ改修時の対応

構造化データは一度入れて終わりではなく、診療体制の変更に追随する運用物です。特に specialOpeningHoursSpecification は、臨時休診・祝日・年末年始の告知とセットで見直す対象になります。

更新が発生するタイミング

• 週の診療時間・休診日の恒常変更
• 臨時休診、学会出張、設備工事
• 年末年始・ゴールデンウィークの特別日程
• 電話番号・移転・医院名変更
• 予約システム変更・予約URL変更
• サイトリニューアルやテンプレート改修（JSON-LD が消える事故が起きやすい）

院内で回す簡易ルール（運用例）

1. 正本を決める：診療時間の正本を「受付マニュアル1枚」または院内スプレッドシートに固定する
2. 更新チェックリストを共通化する：サイト本文 / JSON-LD / GBP / 予約システム / 自動応答電話の5点
3. 担当を分ける：内容決定は院長・事務長、反映はWeb担当または制作パートナー
4. 変更発生時は再テスト：診療時間や予約URLを変更・改修した直後に Rich Results Test を再実行する
5. 定期棚卸し：NAP・診療メニュー・医師情報・予約到達性をまとめて確認する（頻度は変更の起こりやすさに応じて医院ごとに決める）

内製で回しやすいのは、お知らせ更新・診療時間の反映・GBPの情報確認です。一方、JSON-LD の型設計、テンプレートへの埋め込み、リニューアル時の情報設計は、医療・歯科サイトの実績があり公開後の計測まで伴走できる制作パートナーに任せる選択肢もあります。

ブランディングや自費説明のトーンをサイト全体でそろえる話は、選ばれる理由を院内で揃える設計とも接続します。構造化データが担うのは記述の正確さであり、訴求内容の設計とは役割が異なります。

まずは自院サイトの医院名・住所・電話・診療時間・予約URLを印刷し、GBPと予約画面と並べて差分がないか確認してください。差分がなくなってから Dentist の JSON-LD を載せ、Rich Results Test と予約リンクの到達性を確認する。この順番で進めるのが確実です。