ArticleやBlogPostingの構造化データを付けるときは、先にページに表示する記事情報を確定します。コード内だけに著者や実績を追加せず、読者が見る内容と一致させます。
Googleは記事の構造化データで、著者や日付などの情報を説明しています。ただし、適切に記述したことだけで検索結果の特別な表示が保証されるわけではありません。GoogleのArticle仕様
表示する内容から値を決める
| 情報 | 確認すること |
|---|---|
| 著者 | 実際の制作・確認に関わる人や組織を示す |
| 見出し | ページのタイトルと内容を合わせる |
| 公開日 | 実際に公開した日時を使う |
| 更新日 | 記事の更新と表示を整合させる |
| 画像 | 利用できる画像と正しいURLを使う |
| ページURL | 正規URLと整合させる |
下書きを作った日を公開日として登録しないようにします。未公開原稿では公開日は未確定とし、実際の公開工程で入力します。複数記事をまとめて公開する際も、原稿の作成日を一律に流用しません。
テンプレートの誤りを一件で終わらせない
同じテンプレートから生成した記事では、前の記事の著者、画像、URLが残ることがあります。新しい記事だけでなく、代表的な複数ページを比較し、可変項目が正しく切り替わっているかを確認します。
本文にない評価、レビュー、FAQを、検索表示のためだけに追加しません。構造化データは本文の代わりにはならず、内容の一貫性が必要です。
公式の検証と公開後の確認を行う
実装後は公式のリッチリザルトテスト等で構文と対応項目を確認し、実際の公開ページでも取得できるかを点検します。必須・推奨項目や対応機能は変わるため、実装時の公式資料を参照してください。
検証記録にはURL、テンプレートの版、検証日、エラー、修正内容を残します。エラーがないことと、記事が検索に登録されることは別に確認します。
新規記事と既存記事の更新で、日付を分ける
架空例として、9月1日に公開した記事を9月20日に改稿した場合、公開日を9月20日へ置き換えるのではなく、元の公開日と更新日を分けます。公開日が確認できない既存ページへ、下書きの作成日を推測で入れることもしません。
| 検査する組合せ | 確認内容 |
|---|---|
| headlineとh1 | 同じ記事を説明している |
| authorと制作表記 | 実際に関わる人・組織と整合する |
| datePublishedと公開記録 | 初回公開の日時に根拠がある |
| dateModifiedと更新記録 | 本文の変更と表示が一致する |
| mainEntityOfPageとcanonical | 公開先が別の記事を指していない |
空欄を埋めるために架空の著者・監修者を作る必要はありません。推奨プロパティがあることと、根拠のない値を追加してよいことは違います。
記事を更新するたびに、表示内容と構造化データの確認が必要になっている場合は、使っている公開環境と対象URLをご相談ください。更新・確認の手順を整理します。 コンテンツ運用の実装を相談