AEO（Answer Engine Optimization）という言葉を目にする機会が増えてきました。
Google検索だけでなく、ChatGPT、Gemini、Claude、Perplexityなどの生成AIやAI検索に、自社・自院について正確に理解してもらうための取り組みとしても注目されています。
CREDISTA™では、Webサイトの公開一次情報を確認し、SEOやSchema（構造化データ）の状態を検証したうえで、必要なAEO設定を行っています。
その中で大切にしていることの一つが、
「Schemaは、多く入れればよいというものではない」
という考え方です。
今回は、実際の病院WebサイトのTOPページでAEOの設定と検証を行った際に確認した事例をご紹介します。
Schemaを追加する前に、公開一次情報を確認する
AEO設定で最初に確認するのは、Schemaではありません。
まず、そのWebサイトに何が公式情報として公開されているのかを確認します。
今回の病院サイトでは、病院名、所在地、電話番号、診療科目、運営法人、責任者などを確認しました。
さらに、公的な医療情報データベースの情報とも照合しました。
ここで重要なのは、単に情報量を増やすことではありません。
「このページは、誰について、何を伝えているページなのか」
を明確にすることです。
AEOのためにSchemaだけを追加しても、元になるWebページの情報が曖昧だったり、実際の情報と異なっていたりすれば意味がありません。
そのためCREDISTA™では、まず公開一次情報を確認し、ページの主題や本文、SEO設定との整合性を確認してからSchemaを見ていきます。
すでに生成されているSchemaを先に確認する
今回のWebサイトではSEOプラグインが使用されており、TOPページにはすでに複数のSchemaが生成されていました。
確認すると、WebPage、WebSite、BreadcrumbList、ImageObject、Hospitalなどが存在していました。
そこで、新しいHospital Schemaを別に作るのではなく、すでに存在するHospitalの情報を活用し、必要な情報だけを補強する方針としました。
今回、確認・補強したのは、たとえば郵便番号、責任者情報、運営法人との関係、公的な医療情報との関連などです。
AEO設定では、
「何を追加できるか」ではなく、「すでに何があり、何が不足しているのか」を先に確認する。
この順序を大切にしています。
同じ病院を示す情報を重複して作るのではなく、既存の情報構造を確認したうえで、必要な部分だけを補うためです。
診療科目を追加すると、Validatorでエラーが出た
今回の設定・検証で、特に確認しておきたい事例がありました。
診療科目のSchemaです。
病院の公式サイトには、複数の診療科目が正式な日本語名称で掲載されています。
そこで、Hospital Schemaの medicalSpecialty に正式な日本語の診療科名を設定し、Schema.orgの「Schema Markup Validator」で検証しました。
すると、エラーが表示されました。
内容を確認すると、medicalSpecialty は、病院が公式に使用している日本語の診療科名称を自由な文字列としてそのまま設定すればよいものではなく、Schema.orgで定義されている値との整合を考える必要がありました。
ここで重要になるのが、
Schemaの仕様に合わせるために、正式な診療科名を意味の近い別のカテゴリーへ置き換えるべきか
という判断です。
今回は、それを行いませんでした。
Schema上で設定できることを優先して、病院自身が公開している正式な情報の意味を変えてしまうのは適切ではないと判断したためです。
medicalSpecialty の設定を外し、正式な診療科目については、Webページ本文やMeta Descriptionに正確な名称で掲載することを優先しました。
「入れない」こともAEO設定の一つの判断
AEOというと、Schemaを追加したり、情報量を増やしたりすることに目が向きやすいかもしれません。
しかし、今回のように、あえてSchemaへ入れない方がよい場合もあります。
正確に表現できる情報は構造化する。
一方で、正確に表現できない情報を、Schemaに合わせるためだけに別の意味へ置き換えない。
その場合は、Webページ本文など、人にもAIにも読める場所に正確な一次情報を掲載しておく。
CREDISTA™では、「設定できるか」ではなく、「一次情報を正確に表現できているか」を基準に判断しています。
Schemaを増やすこと自体が目的ではありません。
Validatorで「エラー0・警告0」を確認
medicalSpecialty の設定を見直したあと、Schema Markup ValidatorでTOPページを再度検証しました。
結果は、
エラー：0
警告：0
となりました。
ただし、Validatorでエラーがなくなれば作業終了、とは考えていません。
続いてGoogle Search Consoleの「公開URLをテスト」を行い、Googleが現在公開されているページを取得できる状態であること、インデックス登録可能な状態であることを確認しました。
その後、インデックス登録をリクエストし、再クロールを依頼しました。
今回行ったAEO設定・検証を整理すると、次の流れになります。
公開一次情報を確認する
→ ページの主題を確認する
→ 本文・SEO設定を確認する
→ 既存Schemaを確認する
→ 必要なSchemaだけを補強する
→ 本文とSchemaの整合性を確認する
→ Validatorで検証する
→ Googleが現在のページを取得できる状態か確認する
→ 再クロールを依頼する
CREDISTA™ AEO Liteでは、Schemaを設定することそのものではなく、こうした確認と検証を含めてAEO設定を進めています。
設定完了と「成果が出た」は分けて考える
今回のAEO設定は完了しました。
しかし、現時点で「AEOの成果が出た」とは判断していません。
設定を終えた直後だからです。
これからGoogleが変更されたページをどのように再認識するのか。
検索結果やGoogle Search Consoleの数値に変化が現れるのか。
また、ChatGPT、Gemini、Claude、Perplexityなどで病院について質問した際、回答にどのような変化が現れるのか。
これらは、一定期間を置いて確認する必要があります。
CREDISTA™では、こうした実際の反応を「RESPONSE」と呼んでいます。
設定して終わるのではなく、その後の反応を確認し、必要に応じて改善する。
今回の病院サイトについても、一定期間後に検索やAI回答を改めて確認し、変化があったのか、なかったのかを記録していく予定です。
結果が出なければ、それも一つの検証結果です。
そのRESPONSEを次の改善につなげていきます。
AEOの前に、信頼できる情報があること
今回の設定・検証でも、CREDISTA™がAEOで大切にしている考え方を改めて確認することができました。
AEOの前に、信頼できる情報があること。
Schemaは、その情報の意味を検索エンジンなどが理解しやすい形で示すための手段の一つです。
しかし、元になるWebページの情報が曖昧だったり、古かったり、実際の情報と違っていたりすれば、Schemaだけを整えても十分ではありません。
まず、公式の一次情報を確認する。
その情報を人にもAIにも理解できる形で公開する。
そのうえで、必要な部分を構造化する。
AEOのために情報を作るのではなく、信頼できる一次情報を、検索エンジンやAIが理解しやすい状態へ整えていく。
CREDISTA™ AEO Liteでは、この順序を大切にしながら、AEOの設定と検証を行っています。
