構造化データを足す前に、テーマやSEOプラグインがすでに何を出しているかを確認します。Articleは記事の情報、BreadcrumbListはパンくずの並びを伝えるためのデータです。
両方のJSONが読み取れても、内容が本文と違えば確認は終わりません。記事の見出し、著者、日付、実際の階層と対応するかを見ます。
公開HTMLから出力を探す
記事のソースを表示し、application/ld+json、Article、BlogPosting、BreadcrumbListを検索します。JSON-LD以外の記法もあるため、該当の文字列が見つからないだけで未設定と決めないようにします。
見つかったデータは出力元も控えます。テーマとプラグインが別々に出している場合、同じ記事の著者名や日付が食い違っていないかを調べます。複数の型があること自体と、同じ対象の矛盾した出力は分けて扱います。
Articleの値を本文と照合する
GoogleのArticle資料では、該当する推奨項目を加える考え方が示されています。項目を埋めるためだけに著者や日付を作りません。表示上の更新日を新しくするだけの運用と、実際の内容変更を記録する運用も区別します。
| 項目 | 確認する内容 |
|---|---|
| headline | 記事の見出しを表す内容か |
| author.name・author.url | 実際の著者名と、その人を識別できるページか |
| datePublished | 最初の公開日時と対応するか |
| dateModified | 最後の内容変更と対応する日時か |
| image | 記事を代表する画像か |
BreadcrumbListの順序とリンク
パンくずの各項目はListItemで表し、positionが順序、nameが名前、itemがURLです。positionは先頭から1、2、3と対応させます。最後の項目でitemを省いた場合は、そのパンくずを含むページのURLが使われるという説明があります。
たとえば「ホーム→Python→CSVの集計」という架空の階層なら、画面のリンクも同じ意味になるかを確かめます。URLの文字列を切り分けただけで、読者が戻るカテゴリの階層になるとは限りません。
構文・要件・表示を分けた確認
構文が正しいことやテストの合格は、リッチリザルトの掲載や順位を保証しません。修正する場合は出力元を決め、手書きのJSONを重ねる前に既存設定を確認します。この原稿では実サイトの構造化データ設定やGoogleへのテスト送信は行っていません。
- JSONを読み取れるかを確認する。括弧、引用符、カンマの誤りを調べる。
- 現在の公式資料と項目を照合し、本文の情報と一致するかを見る。
- 保存した公開HTMLを読み直し、意図した出力が残っているか確認する。
- Googleの対応するテストで問題を確認し、検索表示は別の判断として扱う。
