構造化データのテスト方法｜2種類の検証とWordPress記事の確認例

こんにちは。バナナデスクです。

構造化データのテストで緑色のチェックが出たら、ひとまず安心しますよね。ただ、古い記事タイトルや著者名が混ざっていても、テストを通る場合があります。

今回、同じ架空記事のコードを3通り作って実際に試したところ、本文と異なる古い題名・著者を含む2件目のデータも、有効な記事として検出されました。構文を読めることと、そのページを正しく説明していることは別なのです。

構造化データは、2種類の検証ツールで確認した後、ページに見える題名・著者・日付と照合するところまでを一組にします。この記事では、入力したコードと実際の結果、WordPressで二重出力を調べる順序を説明します。

執筆：バナナデスク｜WEBビジネスの設計・集客・改善

Schema.orgの検証とGoogleのテストは、見ている範囲が違う

構造化データは、記事、著者、商品などを機械が理解しやすい形で記述した情報です。JSON-LDでは、HTML中のapplication/ld+jsonというscript要素に、型や項目をまとめます。

確認先	主に確認すること	それだけでは決まらないこと
Schema Markup Validator	Schema.orgの語彙として読み取れる型・項目や、検出されたデータ	Google固有の検索機能への適格性や実際の表示
Googleリッチリザルトテスト	Googleが対応するリッチリザルトの型、エラーや推奨項目の指摘	検索に必ず表示されるか、本文とすべて一致するか、AIが引用するか
公開ページと出力コードの照合	題名、著者、画像、日付、同一記事の重複や食い違い	Googleが実際に採用した表示や検索成果

片方で問題がないから、もう片方も同じとは限りません。また、同じページにArticle、WebSite、BreadcrumbListがあること自体は、すべてが重複という意味ではありません。何を表すデータなのかを分けて見ます。

Articleの推奨項目を、すべて「必須」と呼ばない

2026年10月1日に確認したGoogleのArticle資料は、必須プロパティはなく、コンテンツに当てはまる推奨プロパティをできるだけ追加する方針を示しています。authorやheadlineなどが載っていますが、「抜けたらすべて重大なエラー」という意味ではありません。

古い手順の必須項目一覧だけを見て、画面の「任意」という指摘と食い違うことがあります。現在の型の資料と、テストに出た重大・非重大の区分を照合してください。指摘を消すために、実在しない著者や画像を補うのは避けます。

比較した3ケースの入力

架空記事の題名は「教室の案内ページで参加条件を伝える方法」、著者は「架空の教室編集室」です。HTML本文にも同じ題名と著者、公開・更新日時を記載しました。AのJSON-LDは次のとおりです。

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://example.com/class-guide/#article",
  "mainEntityOfPage": "https://example.com/class-guide/",
  "headline": "教室の案内ページで参加条件を伝える方法",
  "image": [
    "https://example.com/images/class-guide-16x9.png"
  ],
  "datePublished": "2026-10-01T09:00:00+09:00",
  "dateModified": "2026-10-01T09:00:00+09:00",
  "author": {
    "@type": "Organization",
    "name": "架空の教室編集室",
    "url": "https://example.com/about/"
  }
}

ドメインと画像URLはexample.comを使った架空値です。画像の実在や外部からの到達性を確認した例ではありません。実サイトへそのまま貼らず、自分のページの情報と一致させる必要があります。

A：上のBlogPostingを1件だけ含める。
B：Aからauthorの項目だけを削除する。見えるHTML本文の著者は残す。
C：Aに、別の@idを持つBlogPostingをもう1件追加する。その題名を「古い案内の題名」、著者を「旧編集名義」にする。

Cは、テーマとプラグインなど別の出力元が、同じ記事について異なる情報を出している状態を考える教材です。特定のWordPressテーマがこのコードを出したという実測ではありません。

3ケースのHTMLとJSON-LDをダウンロード（ZIP）

2つのツールへコードを入力して得た結果

2026年10月1日、編集担当が各HTML全体を2つのツールのコード入力へ貼り付け、計6回の検証結果を確認しました。公開URLをクロールするテストではありません。

入力ケース	Schema Markup Validator	Googleリッチリザルトテスト	本文との照合
A：本文と一致する1件	BlogPosting 1件。エラーなし・警告なし	記事1件が有効。指摘なし	題名・著者が見える本文と一致
B：authorだけ省略	BlogPosting 1件。エラーなし・警告なし	記事1件が有効。重大ではない問題1件。「author」がない（任意）	本文に著者はあるが、マークアップには入っていない
C：古い情報を含む2件	BlogPosting 2件。各エラーなし・警告なし	記事2件が有効。指摘なし	2件目の題名・著者が本文と不一致。この食い違いは直す

3ケースとも有効な記事が検出されたが、Bは著者の任意項目に指摘、Cは古い題名と著者が本文と不一致という結果 — 2026年10月1日、Googleリッチリザルトテストへの架空HTMLコード入力の結果。Cの不一致は本文との照合で判断。

Bでは、Schema.org側はエラーも警告もありませんでした。Google側では有効な記事1件として扱われつつ、authorの任意項目がないという非重大の指摘が1件ありました。こうした違いを、どちらかが間違っていると決めつけないことが大事です。

Cでは、2件目も含めGoogle側に指摘は出ませんでした。しかし、本文の題名と著者は1組だけです。テストの判定だけで終えると、古いデータが残っていることを見落とします。出力内容を本文に戻って確かめる理由はここにあります。

この結果は、今回の3つのコードを検証した記録です。どんな二重出力でも必ず有効になる、著者情報がなくても実務上支障がない、という一般的な保証にはできません。

WordPressで同じ記事の出力を点検する

プラグインの設定画面が正しく見えても、読者に返されるHTMLへ反映されているかは別です。公開ページのソースを開き、application/ld+json、Article、BlogPostingなどを検索します。文字列の検索は入口で、最終的にはデータの型と対象ページを確認します。

公開URLと、画面に見える題名・著者・公開日・更新日を記録する。
出力されたJSON-LDを確認し、その記事を表すデータがいくつあるか調べる。
それぞれのheadline、author、mainEntityOfPage、@idを比較する。
食い違いがあれば、テーマ、SEOプラグイン、独自コードのどこが出力しているかを特定する。
出力元の設定を修正し、公開ページを再取得して同じ項目を照合する。

@idが違うから別々の記事だと決めるのではなく、実際に何のページを説明しているかを見ます。反対に、複数の型があるからとまとめて削除すると、パンくずなど必要なデータまで消す可能性があります。変更する対象を絞ってください。

キャッシュがあるサイトでは、設定を保存した直後でも古いHTMLが返ることがあります。設定画面の表示だけで完了とせず、再取得した公開側の内容を確認します。検証環境で直せる場合は、まずそちらで出力の変化を確かめます。

エラー、非重大の指摘、内容の不一致を分けて直す

JSONの構文が壊れていれば、そもそもデータを読めません。カンマや引用符の位置などを直して再検証します。Googleの対象機能で重大なエラーが出ていれば、該当する型の公式要件を確認します。

非重大の指摘なら、実際のページに当てはまる情報を補います。今回のBでは本文に著者がいるため、その著者を適切に記述することができます。指摘が出なかったCも、本文と異なる題名や著者を修正する対象です。

見えた状態	直す判断
構文を解析できない	生成元やJSONの書式を修正して再検証
重大なエラー	その型の要件と実際のページ情報を照合して修正
任意項目の指摘	内容に当てはまる情報があれば正確に補う
有効だが本文と不一致	出力元を特定し、題名・著者・日付などを本文へ合わせる
有効で本文とも一致	公開URLでも取得状態を確認し、検索上の表示は別に観測する