意味と範囲
Schema.orgのWebSiteタイプでは、サイト名やURLなどの情報を構造化データとして表せます。これは語彙の定義であり、検索エンジンが特定の機能を表示するという約束ではありません。構造化データを検索結果の表示にいつ、どう使うか（使うかどうかも含めて）はGoogleが決めます。対応する機能も時間とともに変わります。
実践の流れ
記述するのは、変わりにくく、ページ上で見えるか、別の方法で確認できる情報だけです。正規のトップページURL、ユーザーが目にするサイト名を使います。Organizationとの関係は、同じエンティティを正確に表す場合にだけ付けます。JSON-LDはよく使われる記述形式ですが、構文が正しくても、別サイトの情報や古い設定が混ざったグラフは誤解を招きます。
確認する項目
デプロイ後に、レンダリング後のページソースを確認し、グラフをパースします。識別子が想定どおりに解決されるか、値が表示上のサイトの同一性と一致するか、サイト単位のグラフが重複・矛盾していないかを見ます。語彙と構文を検証したら、対応機能の現状はGoogleの最新ドキュメントで確認します。古い解説記事には頼らないでください。
限界とよくある間違い
提供終了した、または未対応の表示機能を狙ってSearchActionを追加してはいけません。別名、運営者との関係、検索エンドポイントを作り上げるのも避けます。構造化データは既存の事実を明確にするもので、内容の弱さ、アクセスできないページ、混乱したcanonical設定を直すことはできません。
WebSiteエンティティを慎重に設計する
まず、リダイレクト後にユーザーとクローラーが実際にたどり着くトップページを出発点にします。最終的な正規URL、表示されているサイト名、表示されている別名を記録します。Organizationとの関係は、両者が同じ公的なエンティティを指す場合だけ記録します。CMSの設定に残っているからといって、別のホスト、ステージング環境の名前、古い法人名をWebSiteのグラフに載せてはいけません。矛盾するノードが並ぶ大きなグラフより、安定した識別子のほうが役に立ちます。
{ "@context": "https://schema.org", "@type": "WebSite", "name": "Example", "url": "https://example.test/" }エディターのプレビューではなく、レンダリング後のHTMLを確認します。JSON-LDのscriptをすべてパースし、@id、@type、name、url、alternateName、OrganizationやWebPageノードとのつながりを一覧にして、ページ上で見える情報と照合します。検証ツールは構文や語彙の問題を見つけられますが、古いサイト名、期限切れのURL、実態と合わない記述が事業の現実を反映しているかどうかまでは判断できません。
グラフはトップページ、言語バリエーション、主要なテンプレートにわたって確認します。サイト単位のマークアップは全体に挿入されることが多く、変更によってノードが重複したり、ロケールごとにURLが食い違ったりします。地域別・言語別のサイトが別のエンティティなら、WebSiteの宣言を丸ごとコピーせず、関係を意図的に記述します。グラフ内の正規URLが直接、一貫して解決されることも確認します。
古い解説記事に「検索機能が出る」と書かれているからといって、プロパティを追加しないでください。Schema.orgが定義するのは語彙で、Googleが現在対応している構造化データの機能は別途ドキュメントで示され、変更されることもあります。有効なWebSiteエンティティは機械可読な情報の一貫性を高めますが、サイト名の表示、サイトリンク、その他の検索表示の強化を保証するものではありません。