構造化データを書く前に、対象ページの種類と、現在の出力元を確認します。この記事ではArticleのJSON-LDを例に、必要な情報の整理、WordPressへの反映、公開後の検証までを扱います。基本用語は構造化データの基礎をご覧ください。
1．現在のHTMLを調べる
ページのHTML内でapplication/ld+jsonを検索し、テーマやSEOプラグインがすでに出力していないかを確認します。同じ記事を異なる著者・URL・日付で二重に記述しないようにします。すでに適切な出力がある場合は、新しいコードを貼るより既存の設定を修正します。
2．画面にある情報をそろえる
| 項目 | 確認する内容 |
|---|---|
| headline | 実際の記事見出し。検索用のキーワードを追加しない。 |
| author | 実際の著者。個人ならPerson、組織が制作主体ならOrganizationを検討する。 |
| publisher | 記事を発行する組織等。著者と同じとは限らない。 |
| datePublished / dateModified | 実際の公開日時と、内容を更新した日時。 |
| image | 記事内容を表す取得可能な画像。存在しない画像を設定しない。 |
| mainEntityOfPage | 記事の正規URL。プレビュー用URLを使わない。 |
3．Articleの記述例
以下は構文を説明するためのサンプルです。ドメイン・名称・見出し・日時・画像は架空の値なので、そのまま公開しないでください。著者を組織名義にできるかも、実際の制作・確認体制に合わせて判断します。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "公開する記事の見出し",
"author": {
"@type": "Organization",
"name": "実際に記事を制作する組織名",
"url": "https://example.com/about/"
},
"publisher": {
"@type": "Organization",
"name": "実際の発行者名",
"url": "https://example.com/"
},
"datePublished": "2026-09-01T09:00:00+09:00",
"dateModified": "2026-09-30T09:00:00+09:00",
"image": [
"https://example.com/images/article.jpg"
],
"mainEntityOfPage": "https://example.com/articles/sample/"
}
</script>推奨項目や対応条件は更新されるため、実装時にGoogleのArticleドキュメントを確認します。項目を埋めるために、未確認のプロフィールや実績を作らないことが重要です。
4．WordPressでは共通の出力元で管理する
まずテーマとSEOプラグインの対応を確認し、見出し・著者・日付・アイキャッチ画像から自動出力する方針を検討します。独自実装が必要なら、保守担当者が子テーマや専用プラグインで管理し、投稿本文への貼り付けを乱立させないようにします。
動的にJSONを作る際は、文字列を手で連結せずJSONエンコードを使います。引用符、改行、日本語を含むタイトルでも壊れないかを検証します。管理画面で本文を更新したとき、マークアップにも同じ変更が反映されることを確認してください。
5．二つの検証と、画面との照合を行う
- Schema Markup Validatorで構文と語彙を確認する。
- Googleのリッチリザルトテストで対応する形式を確認する。
- 実画面の見出し、著者、日付、画像と出力値を照合する。
- PC・スマートフォンで本文が正しく表示され、リンクが機能するか確認する。
- 公開URLでも再検証し、Search Consoleの該当レポートを確認する。
テストで有効になっても、リッチリザルトやAI回答への掲載が約束されるわけではありません。Googleが対応しない型がリッチリザルトテストに出ないことと、JSON自体が壊れていることも区別します。
FAQPageを追加する前に
FAQがあるという理由だけで、検索表示を増やす目的のコードを追加しないでください。GoogleのFAQリッチリザルトは終了しています。質問と回答を本文で読みやすく整理することと、特定サービス向けのマークアップの必要性は別に判断します。