組織、サービス、記事の構造化データ

構造化データは見える事実を説明します。名称、日付、URL、提供内容を一致させます。架空の個人経歴を作らず、Orvunwebを組織の著者とできます。偽の評価、支店、受賞を追加しないでください。

ページに実在する主題を選ぶ

構造化データは公開事実を整理して説明します。組織、サービス、記事は異なる主題です。すべての型を全ページへ入れるより、その違いを保つ方が有用です。

サービスを、別の表示形式を狙って物理製品のように偽装しません。組織はブランドと確認済み事実、記事は題名、日付、言語、発行者、住所など、実際の本文に対応する情報を示します。

プロパティは本当にあるものから選びます。マークアップを追加しても、存在しない資格や商取引関係が生まれるわけではありません。

価格は画面と同じカタログを参照し、通貨と料金の意味も一致させます。一度の制作費を月額のように読ませたり、JSONだけ別の範囲を示したりしないようにします。

日付は実際の作成と変更を表し、ビルドのたびに全記事を最新扱いにしません。著者は実在する組織でもよく、専門家の架空の個人経歴を作る必要はありません。

FAQを付けるなら、質問と答えが実際のページに必要です。構文が正しくても、検索が特別な表示を必ず出すわけではありません。

まずJSONを解析できるかを確認し、次に各値を画面と比べます。正しい構文でも、不正なURLや矛盾した料金はあり得ます。canonicalと画像の住所も調べます。

文字列のエスケープを適切にし、文章が構造を壊さないようにします。ユーザー入力や私的情報を無条件に公開マークアップへ入れません。共通データから作ることで表現のずれを減らせます。

Orvunwebの記事なら組織の著者、実日付、アクセスできる画像を示せます。プランなら実際のサービスと提供条件を記述します。偽の評価、顧客、支店、賞を足す必要はありません。

ページ種別ごとの実例を見てから、必要な自動確認を行います。目的は公開内容を正確で読みやすく表現することで、順位保証や企業情報を人工的に豪華にすることではありません。

具体例: 架空の個人経歴を作らず、Orvunwebを組織の著者とできます。

守りたい範囲: 偽の評価、支店、受賞を追加しないでください。