構造化データを入れる時の基本
構造化データは、ページ本文の内容を補助的に説明するものです。CodexでschemaやJSON-LDを扱う時は、本文にない内容を盛らず、古い情報や危険な断定表現を残さないことを優先します。
FAQPage以外のschemaも、ページ内容に合っている場合だけ検討します。よく分からないschemaを安全確認なしに入れないようにします。
確認するポイント
- script type="application/ld+json" が壊れていない。
- JSONとして読み込める。
- 本文と構造化データの内容が大きくずれていない。
- 料金、仕様、効果、順位、安全を断定しすぎていない。
- 公開前に SEOタグ と robots/canonical も確認する。
まずどの型を入れるか決める
構造化データは種類が多く、全部入れようとすると破綻します。個人が運営する解説サイトで実際に意味があるのは、次の範囲に絞られます。
| 型 | どんなページ向きか | 入れる価値 |
|---|---|---|
Article / BlogPosting | 解説記事・ニュース記事 | 高い。著者と公開日を機械に伝えられる |
BreadcrumbList | 階層のあるサイト全般 | 高い。検索結果のパンくず表示に使われる |
FAQPage | 本当にQ&A形式のページだけ | 条件付き。注意点は別ページ |
Organization / WebSite | トップページに1つ | 中。運営者情報を明示できる |
HowTo, Product, Review | 該当する実体がある場合のみ | 実体が無いなら入れない |
最後の行が重要です。商品を売っていないのに Product を、レビューしていないのに Review を入れると、内容と一致しないマークアップになります。効果が無いだけでなく、ガイドライン違反として扱われる可能性があります。
Codexに書かせた JSON-LD を信じる前に
JSON-LDは書式が決まっているので生成自体は得意な領域ですが、そのまま公開すると次のような取り違えが起きます。実際に確認すべき点を挙げます。
- 1. 本文に無い情報が入っていないか。著者名、公開日、評価点など、ページに書かれていない値が埋められていることがあります。構造化データは本文の要約であって、追加情報を足す場所ではありません。
- 2. 日付の形式と実際の日付が合っているか。
datePublishedが生成日になっていて、記事の実際の公開日とずれることがあります。 - 3. URLが絶対パスになっているか。相対パスで書かれていると正しく解釈されません。
- 4. 1ページに同じ型が重複していないか。テンプレート側で既に入っている型を、記事側でもう一度入れてしまう事故が起きます。
- 5. 公式のテストツールに通したか。目視で正しく見えても、構文エラーで丸ごと無視されていることがあります。
5番は必ず実施してください。構造化データは間違っていても画面上は何も起きないため、テストツールを通さない限り壊れていることに気づけません。
FAQ
schema.orgとは何ですか
構造化データの語彙を整理するための仕組みです。ページ本文と矛盾しない範囲で使います。
JSON-LDの確認では何を見ますか
構文、本文との一致、古い情報、危険な断定表現、Secretsやローカルパスの混入を確認します。
構造化データを入れればSEO順位は上がりますか
順位は約束できません。内容を機械に伝えやすくする補助として確認します。