Schemaとは何をするためのものか

Schemaは、ページに書かれている情報を機械が解釈できる形で補足し、「これは何か」「誰の情報か」「どんな関係か」を明確にする仕組みです。

• 企業情報が分散しない
• ページ同士の関係性が崩れない
• 発信主体の一貫性が保たれる

こうした状態を作ることで、検索エンジンだけでなく、AIによる情報取得・要約・表示でも誤解が起きにくくなります。
図は、Schemaの種類を紹介するためのものではなく、企業サイト全体が「1つの企業像」として理解される構造を示すための図です。

LocalBusinessを起点に全体を接続する

FHWでは、LocalBusinessを企業情報のハブとして設定し、Webサイトや各ページ、各種コンテンツのSchemaを、LocalBusinessへ接続します。

• LocalBusiness
  企業情報の基底（発信主体）
• WebSite
  公式サイトとしての位置づけ
• WebPage
  各ページの役割・主題の明示
• BreadcrumbList
  階層構造の正確な伝達（トップページ以外）

これらを @id で接続し、「ページ単体」ではなく「サイト全体」として理解される状態を作ります。

各種コンテンツをLocalBusinessに紐づける

サービス、事例、記事、採用、FAQなどのコンテンツは、それぞれ適切な @type を持ちながら、発信主体としてLocalBusinessを参照する構造で実装します。
例：

• Service / Offer（サービス）
• BlogPosting（記事）
• FAQPage（FAQセクション）
• JobPosting（採用）
• Event（セミナー・イベント）
• Product（扱う製品や商品がある場合）

これにより、コンテンツが増えても、「誰が語っている情報か」が一貫して伝わる構造を保てます。

ナレッジパネル・リッチリザルト・AI表示を見据えた考え方

Schemaは、表示内容を直接コントロールするものではありません。
しかし、企業情報・ページの役割・関係性を正確に伝えることで、結果として

• 企業情報の解釈が安定する
• ページ同士の位置づけが明確になる
• 誤認や分断が起きにくくなる

という“土台”を作れます。
AI OverviewsやAIモードのような表示でも、機械が参照できる一貫した構造は重要になります。

複数ドメイン／サブドメインを持つ場合の Schema実装（横断設計）

企業が複数のドメインやサブドメインを持つ場合、Schemaは“各サイトで別々に完結させる”のではなく、発信主体（企業）を共通化した上で整合性を取ることが重要です。
FHWでは以下の考え方で設計します。

• 企業の @id（LocalBusiness）を共通の基点として固定する
  どのドメインでも同じ企業を参照する
• 各ドメインはWebSite / WebPage をそれぞれのURLで持つ
  公式サイトが複数ある前提で、サイト単位の構造を崩さない
• about / isPartOf / publisher などの関係を、矛盾なく接続する
  「どのサイトが、どの企業の公式情報か」を明確にする
• コンテンツが跨る場合は、参照関係（@id）を使って同一性を維持する
  重複定義で別物に見せない
• 役割が異なるサイト（コーポレート／サービス／採用等）は、サイトごとの目的に合わせたSchemaの粒度を調整する
  全部を同じにしない

この横断設計により、ドメインが分かれていても、企業情報やコンテンツの位置づけが分断されにくくなり、検索・AI双方での解釈が安定します。

このページで伝えたいこと

Schemaは、ページを飾るための設定ではありません。
企業・Webサイト・各ページ・各コンテンツを、一貫した構造として機械に伝えるための実装です。
FHWでは、全ページにSchemaを実装し、JSON-LDと@idの一貫性を軸に、将来の拡張やドメイン横断まで見据えた「伝達基盤」を整えます。