「構造化データを入れると良いと聞いたけれど、何をどこに設定すればよいか分からない」。Search Consoleのエラーに戸惑った方もいるかもしれません。
結論から言うと、構造化データはページの内容を検索エンジンに正確に伝えるための追加情報です。入れるだけで順位が上がる仕組みではありません。SWELLなどのテーマやSEOプラグインがすでに出力していることも多いため、追加する前に、何が出力されているかを確認することが最初の一歩です。
本記事は2026年11月6日時点のGoogle公式情報をもとに、内容を公式で確認した事実、筆者の整理（公式資料の読み解き）、実務上の推奨（順位への効果は公式で確認できていない施策）に書き分けます。
1. 構造化データとは？HTMLとの違いを整理
構造化データとは、ページに書かれた情報が何を表すのかを、決まった形式で検索エンジンに伝えるデータです。
1-1. 定義と仕組み
Googleは構造化データを、ページに関する情報を提供し、内容を分類するための標準化されたデータ形式と説明しています（公式で確認）。
人間は「2026年1月15日」を見れば、文脈から公開日だと分かります。検索エンジンも本文を読み取りますが、「これは公開日」と明示されていれば、手がかりが増えます。Googleも、明確な手がかりで理解を助けられると説明しています（公式で確認）。
1-2. HTMLとの関係
HTMLは、見出しや段落など、ページの構造と表示を指定する言語です。構造化データは、そのHTMLに表示されている内容が何を意味するのかを補足する情報です。ユーザーに見えない情報は、たとえ正確でも構造化データにしないよう、Googleは求めています（公式で確認）。
1-3. 構造化データがない場合との違い
| 項目 | ない場合 | ある場合 |
|---|---|---|
| 日付・著者・種類 | 本文から推測される | 明示できる |
| 検索結果 | 通常の表示が中心 | 条件次第でリッチリザルトの対象 |
ない場合が不利という意味ではなく、ないと掲載されない、とする記述も今回確認した公式資料に見つかりませんでした。
2. 構造化データとSEOの関係
結論として、役割は「ページ理解の補助」と「リッチリザルトの対象になる可能性」であり、順位の上昇を保証するものではありません。次の3点を分けて考えます。
| 区分 | 内容 | 根拠 |
|---|---|---|
| ①ページ理解の助け | Googleが意味を理解する手がかりになる | 公式で確認 |
| ②リッチリザルトの対象 | 条件を満たせば対象になり得る。表示は保証されない | 公式で確認 |
| ③順位の上昇 | 保証されない。上がるという公式の記述は確認できなかった | 確認できず |
なお、構造化データの問題で手動による対策を受けると、リッチリザルトとして表示されなくなりますが、ウェブ検索での掲載順位には影響しない、とGoogleは説明しています（公式で確認）。順位に効果がないと断定する根拠も、確認していません。
2-1. クリック率（CTR）への影響の可能性
Googleは、構造化データで検索結果がより魅力的になり、ユーザーの操作を促せる可能性があるとしています。CTR向上を報告する企業の事例も公式資料にありますが、個別の事例であり、他のサイトでも同じ結果になる根拠ではありません（公式で確認）。Googleは、数ページで導入前後を比べる確認方法を案内しています。
2-2. 設定は必須なのか
記事ページのArticleには必須プロパティがなく、ページに当てはまるものを追加する形です（公式で確認）。「入れないと困る」ではなく、ページに合うものを正確に入れると考えると、判断を誤りにくくなります（実務上の推奨）。構造化データはE-E-A-Tを自動で高める機能でもありません。考え方はE-E-A-Tの解説記事をご覧ください。
3. リッチリザルトとは？表示されない場合もある
リッチリザルトとは、標準的な青いリンクだけでなく、画像や評価など、テキスト以外の要素を含む検索結果の表示です。
3-1. 具体例
Googleの検索ギャラリー（日本語版の最終更新日は2026年10月19日）には、次のような機能が載っています（公式で確認）。
- パンくずリスト：サイト階層での位置の表示。パソコン版に対応するとされています
- 商品・レシピ：価格、在庫、評価、調理時間などの表示
- 求人情報・イベント：求人の詳細、日時と場所のあるイベントの表示
- 記事：タイトル、画像、日付の表示に役立つ可能性があります
3-2. 設置しても表示されるとは限らない
Googleは、構造化データは機能が表示される可能性を作るもので、表示を保証しないと明記しています。検索履歴や場所、端末で結果が変わるほか、ページ内容と合わない場合やガイドライン違反でも表示されません（公式で確認）。
3-3. Schema.orgで定義されていることと、Googleの対応は別
Schema.orgは多くの種類を定義していますが、Google検索でリッチリザルトに使えるのは一部です。Google検索の動作はSearch Centralの資料が基準だと、Googleも説明しています（公式で確認）。FAQPageはSchema.orgに今もありますが、Google検索では終了しています。
4. 構造化データの主な種類と対応状況
すべてのサイトにすべての種類が必要なわけではありません。ページの内容に合うものだけを選びます。
4-1. 比較表
| 名称 | 対象ページと役割 | サイト例 | Google検索での対応（2026年11月6日確認） |
|---|---|---|---|
| Article | 記事。タイトル・画像・日付・著者 | ブログ、メディア | 一覧に掲載。必須プロパティなし |
| BlogPosting | ブログ記事。Articleのサブタイプ | ブログ | 記事ガイドの対象の型の一つ |
| BreadcrumbList | 下層ページ。サイト内の位置 | 全般 | 一覧に掲載。パソコン版に対応 |
| Organization | トップや会社概要。名称・ロゴ・連絡先 | 企業サイト | 一覧に掲載。必須プロパティなし |
| LocalBusiness | 店舗情報。住所・営業時間 | 店舗、地域密着 | 一覧に掲載。nameとaddressが必須 |
| Product | 商品。価格・在庫・評価 | ECサイト | 一覧に掲載。商品スニペットはnameと、review等のいずれかが必須 |
| Event | イベント告知。日時・場所 | 主催者、施設 | 一覧に掲載 |
| Recipe | レシピ。材料・調理時間 | 料理ブログ | 一覧に掲載 |
4-2. FAQPageとHowToの現在の状況
結論として、一般的なブログにFAQPageやHowToを追加しても、FAQやHowToのリッチリザルトは表示されません。公式の記録は次のとおりです（公式で確認）。
| 種類 | 経緯 | 2026年11月6日時点 |
|---|---|---|
| FAQPage | 2023年8月8日：表示を、よく知られた政府・健康分野の権威あるサイトに限定。2026年5月8日：廃止を告知（5月7日以降は表示されない）。6月15日：公式ドキュメントを削除 | 終了。検索ギャラリーの一覧にもない |
| HowTo | 2023年8月8日：表示をパソコンのみに限定。9月14日：パソコンでも表示終了（9月13日以降）、公式ドキュメントを削除 | 終了。同上 |
2023年の説明では、すでに入っているマークアップは削除不要で、検索に問題は起きないが見た目への効果もないとされています。2026年の廃止に伴う削除の推奨は確認できていません。新規には入れず、既存分は更新のついでに整理するのが現実的です（実務上の推奨）。
記事内に「よくある質問」を載せることと、FAQPageのマークアップは別です。
5. サイト別の構造化データ早見表
必須の設定はありません。優先して確認したい種類の目安です（筆者の整理）。
| サイトの種類 | 優先して確認したい種類 |
|---|---|
| 個人ブログ | Article（BlogPosting）、BreadcrumbList |
| 中小企業のコーポレートサイト | Organization（トップ）、BreadcrumbList、Article |
| 店舗・地域密着型 | LocalBusiness、Organization、BreadcrumbList |
| ECサイト | Product、BreadcrumbList、Organization |
| メディアサイト | Article、BreadcrumbList、ProfilePage（著者ページ） |
どの型も、まずテーマの出力を確認し、足りない点だけ補います。住所や価格などは、サイトの表示と一致させてください。
6. JSON-LD・Microdata・RDFaの違いとSchema.org
3つは「書き方」の違いで、GoogleはJSON-LDを推奨しています。Schema.orgは「何と書くか」を決める語彙で、書き方そのものではありません。
6-1. 3つの記述形式
| 形式 | 書き方の特徴 |
|---|---|
| JSON-LD | scriptタグの中に、本文と分けてまとめて書く |
| Microdata | 本文のHTMLタグに属性（itemscope、itempropなど）を付ける |
| RDFa | HTMLタグに属性を付ける。HTML5の拡張 |
Googleは、3形式とも正しく実装されていれば同等としたうえで、サイトの構成が許すならJSON-LDを推奨しています。実装・保守がしやすく、ミスが起きにくいためです。本文と混ざらず、JavaScriptで後から挿入されたものも読み取れます（公式で確認）。
6-2. Schema.orgとは
Schema.orgは、構造化データで使う用語（語彙）を定義する取り組みで、Google、Microsoft、Yahoo、Yandexが設立し、RDFa、Microdata、JSON-LDなどで使えます（公式で確認）。単語帳がSchema.org、文の書き方がJSON-LDなど、と考えると分かりやすいでしょう（筆者の整理）。
7. JSON-LDの記述例：BlogPostingの基本形
結論として、記事ページの基本形は、タイトル・画像・日付・著者を伝える短いコードです。以下は説明用の架空データです。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "サンプル記事のタイトル",
"image": [
"https://example.com/images/sample-1x1.jpg",
"https://example.com/images/sample-4x3.jpg",
"https://example.com/images/sample-16x9.jpg"
],
"datePublished": "2026-01-15T09:00:00+09:00",
"dateModified": "2026-02-20T10:30:00+09:00",
"author": {
"@type": "Person",
"name": "サンプル 太郎",
"url": "https://example.com/author/sample-taro/"
}
}
</script>このコードは、JSONとしての構文を機械的に確認しています。リッチリザルトテストにはかけていないため、使う場合はご自身のページでテストしてください。
7-1. 各項目の意味と変更点
- @context・@type：語彙（Schema.org）とデータの種類の指定です。種類はArticleやNewsArticleにも変えられます
- headline：記事タイトルです。長いと一部の端末で省略される場合があります
- image：記事を代表する画像です（ロゴは避ける）
- datePublished・dateModified：初回の公開日時と最終更新日時です。更新のたびにdateModifiedを変えます
- author：著者です。nameは名前だけ、urlは著者を識別できるページにします
変更が必要なのは、@context以外のすべての値です。Googleの記事ガイド（日本語版の最終更新日は2026年9月12日）では、必須プロパティはなく、推奨プロパティはauthor、dateModified、datePublished、headline、imageです（公式で確認）。
7-2. 日付・URL・一致・構文の注意
- 日付：ISO 8601形式で、日本なら「+09:00」のようにタイムゾーンを付けます。省略するとGooglebotのタイムゾーンとして扱われます
- URL：「https://」から始まる完全なURLにします
- 一致：表示している日付、著者と同じ内容にします。見せ方は情報発信プロセスの記事をご覧ください
- 構文：閉じ忘れ、最後のカンマ、全角の引用符が代表的な誤りです。コメントは書けません
SWELLやプラグインがすでに適切なデータを出力している場合、同じコードを追加する必要はありません。二重にすると、内容が食い違う原因になります。
8. WordPressで設定する3つの方法
順番は「①テーマの出力を確認、②プラグインを確認、③足りない場合だけ手動」です。
| 方法 | 向く場面 | 注意点 |
|---|---|---|
| ①テーマ | 出力機能があるテーマ | 内容はテーマ次第 |
| ②プラグイン | 管理機能を持つもの | 機能は製品ごとに違う |
| ③手動追加 | どちらにもない種類 | ミス・重複・保守の負担 |
8-1. 方法①：SWELLなどテーマの機能を使う
SWELL公式サイトの機能紹介（資料⑧）には、リッチスニペット表示に必要な構造化データのマークアップを自動で行え、方式はGoogle推奨のJSON-LDと記載されています（公式で確認）。種類やプロパティの詳細は分かりません。
AFFICAMPのサイトで確認した範囲（2026年11月6日）では、公開記事ページに、SWELLがJSON-LDを1つのscriptにまとめて出力していました。内容はOrganization、WebSite、WebPage、Article、BreadcrumbListで、Articleは1つだけです。Articleには、headline、image、datePublished、dateModified、author（名前とURL）、publisher、mainEntityOfPageが含まれていました。
- アイキャッチ未設定の記事では、Articleのimageに、SWELL共通の代替画像が入ります
- author.nameは、WordPressユーザーの表示名から出ており、表示名を変えると構造化データも変わりました
- 構造化データの設定は、「外観」→「カスタマイズ」ではなく、管理画面の「SWELL設定」ページの「構造化データ」タブにあります。「JSON-LDを自動生成する」の設定と、運営組織（publisher）の名前・URL・ロゴなどを入力する欄、設立者の情報欄がありました。必須項目が空のときはサイト情報が使われる、という説明も画面に出ています
他の環境やバージョンでは異なる可能性があります。基本設定はSWELL導入後の初期設定の記事もご覧ください。
8-2. 方法②：プラグインを使う
Googleは、CMSでHTMLを直接編集しにくい場合、設定ページやプラグインで構造化データを指定できることがあると説明しています（公式で確認）。ただし機能はプラグインごとに違い、メタタグ・OGPの設定と構造化データの設定は別物です。
SEO SIMPLE PACKは、WordPress.orgの説明ページにメタタグとOGPの機能が案内されており、構造化データの記載は確認できませんでした。AFFICAMPのサイトでは、投稿編集画面の「SEO SIMPLE PACK 設定」に、robotsタグ、タイトルタグ、ディスクリプション、og:image、canonical URL、キーワードがあり、構造化データの項目はありませんでした。プラグイン全体の設定画面は未確認です。導入前は、公式説明に構造化データの出力があるかを確認してください。
8-3. 方法③：JSON-LDを手動で追加する
テーマとプラグインの出力を確認したうえで、足りない種類があるときだけ行います。重複や矛盾を避け、記事ごとの情報とサイト全体の情報（会社情報など）を分け、バックアップを取り（できればテスト環境で試し）、公開後に検証します。
記事ごとの追加には、本文のカスタムHTMLブロックにscriptを入れる方法が考えられますが、権限や環境によって保存時に除去される場合があります。本記事では検証していないため、保存後にページのソースで出力を確認してください。
functions.phpの直接編集は、初心者にはおすすめしません。記述ミスでサイトが表示されなくなる恐れがあり、親テーマに加えた内容はテーマの更新で消えると、WordPress公式の子テーマの説明にもあります（公式で確認）。必要な場合は、子テーマなどを使い、バックアップを取ってから行います（実務上の推奨）。
9. SWELLで確認する手順
確認にコードは不要です。公開済みの記事URLで、次の6つを順に行います。
- サイトを開く：自分のWordPressサイトの、公開済みの記事を開きます
- URLを取得する：アドレスバーからURLをコピーします。下書きは検査できません
- リッチリザルトテストを開く：https://search.google.com/test/rich-results を開きます
- URLを入力して検証する：URLを貼り付けて、テストを実行します。端末の初期値はスマートフォンです
- 検出された項目を確認する：検出された種類を見ます
- 問題があれば内容を見る：項目を開くと、エラーや警告の詳細が分かります
9-1. ページのソースで確認する方法
ページ上で右クリックし、ページのソースを表示して「application/ld+json」を検索すると、JSON-LDのscriptが見つかります。SWELLでは1つのscriptの中に「@graph」という枠でまとまっていました（AFFICAMPで確認した範囲）。headlineや日付が、画面の表示と合っているかを見ます。
9-2. 検出されなくても、ないとは限らない
リッチリザルトテストは、Google検索でサポートされる機能向けの検証ツールです。一覧に出ない種類があっても、構造化データが存在しないとは言えません。出ないときは、ソースと次章のSchema Markup Validatorでも確認します。本記事では、AFFICAMPのソースで出力を確認しましたが、リッチリザルトテストの検出結果は確認していません。
10. 構造化データをテストする2つのツール
結論として、Google検索での扱いはリッチリザルトテスト、一般的なSchema.orgの確認はSchema Markup Validatorで見ます。
| 項目 | リッチリザルトテスト | Schema Markup Validator |
|---|---|---|
| 役割 | Google検索のリッチリザルトの検証 | Schema.orgの構文・語彙の検証 |
| 向く場面 | 検索機能の対象になる型の確認 | Googleが対象としない型や構文の確認 |
Googleのページでも、一般的な検証はSchema Markup Validator、Google固有のエラーはリッチリザルトテストと案内されています（公式で確認）。
10-1. リッチリザルトテストの使い方
URL入力のほかに「コード」を選んで貼り付ける検証もでき、公開前にコードを試せます。URLは誰でもアクセスできる必要があり、robots.txtやnoindexでブロックしたページはテストできません。
エラーと警告の違い：エラー（重大な問題）は、リッチリザルトの対象から外れる原因になります。警告（重大でない問題）は、品質向上に役立ちますが、対象になるために必須ではありません（記事ガイドの案内）。テストに通っても、検索結果への表示は保証されません。
10-2. Schema Markup Validatorの使い方
https://validator.schema.org/ を開き、入力欄に検証対象を入れて実行します。旧ツールのSchema.org部分を移行したもので、Google固有の要件は見ません。FAQPageのようにGoogleが対象外にした型の確認にも使えます。
11. Search Consoleでの確認方法
Search Consoleは、公開後にGoogleがどう見ているかを確認する場所です。導入はSearch Consoleの導入方法の記事をご覧ください。
- URL検査ツール：対象URLの状態を確認します。リッチリザルトが検出されていれば、種類や警告・エラーも見られます。[ライブテスト]で現在のページを確認できます
- リッチリザルト関連のレポート：[拡張機能]の中に、検出された種類ごとに表示されます。有効なマークアップがあり、対応する種類のときだけ表示されるため、サイトによって一覧は変わり、すべてのSchema.orgの型が並ぶわけではありません
- 有効・無効：重大な問題がないものが有効、1つ以上あるものが無効です。「アイテムが無効な理由」と「検索での見え方を改善できるアイテム」の表で、重大な問題とそうでない問題を分けて見ます。数字は項目数で、一覧はサンプルです
- 修正後：コードを直し、ライブテストで確認し、問題の詳細ページで検証状況を見ます。反映には再クロールの時間がかかります
- パフォーマンス：URLで絞り、導入前後を数か月比べます
名称や対応種類は変更されます。ヘルプには終了した機能の名前も残っているため、実際の画面で確かめてください。
12. よくあるエラーと対処法
エラーの多くは、入力の不足や誤り、表示との不一致、重複管理です。
| 問題 | 原因 | 確認方法 | 改善方法 |
|---|---|---|---|
| 必須項目の不足 | 必須プロパティがない | テストのエラー詳細 | 該当機能のガイドで確認して追加 |
| 推奨項目の不足 | 推奨プロパティが未設定 | 警告の詳細 | 当てはまるものだけ追加 |
| URLが正しくない | 相対パス、誤字 | URL検査ツール | 完全なURLにする |
| 日付の形式の誤り | ISO 8601でない、時差がない | テストの詳細 | 「2026-01-15T09:00:00+09:00」の形に |
| 構文エラー | カンマや括弧、全角引用符の誤り | テストや検証ツール | 構文を直す |
| 内容の不一致 | 表示と内容が違う | 画面とソースを比較 | 表示を正としてデータを合わせる |
| 二重管理 | テーマとプラグインで同じ情報を設定 | ソースで@typeを検索 | 出力元を1つに整理 |
| 対象外のタイプ | Googleが対応しない型を使用 | 検索ギャラリーの一覧 | 目的を見直す |
| クロールできない | robots.txt、noindex、ログイン | URL検査ツール | ブロックを解除 |
構造化データが複数あること自体はエラーではありません。Googleは、1ページにレシピ、動画、パンくずなど複数の項目があってよく、入れ子でも個別でも理解できると説明しています（公式で確認）。問題になるのは、矛盾する内容、意図しない重複、不要な二重管理です。
警告は改善の目安で、順位が下がるという公式の説明は確認できていません。エラーは、放置すると対象外になる可能性があります。
13. 設定時の注意点と実装前チェックリスト
結論として、守るべき原則は「ページの内容と一致していること」です。
- ページ内容と一致する情報にする
- 架空の評価やレビューを設定しない
- ページと無関係な構造化データを追加しない
- Googleの一般的なガイドラインを守る
- 必須項目と推奨項目を区別する
- テーマ・プラグインの出力を確認する
- 検証ツールで確認する
- 公開後も定期的に確認する
不正な使い方は手動による対策につながり得ます。大量に追加してもSEOは強くなりません。
13-1. 実装前チェックリスト
□ テーマの構造化データ出力を確認した
□ プラグインの出力内容を確認した
□ 対象ページに適した種類を選んだ
□ ページの表示内容と一致している
□ URLや日付の情報が正しい
□ 検証ツールで確認した
□ エラーや警告の意味を確認した
□ Search Consoleで公開後の状態を確認した
14. 構造化データとAI検索の関係
結論として、AI検索のための特別な構造化データは不要とされています。
公式で確認：Googleの生成AI機能向け最適化ガイド（英語版の更新日は2026年7月10日）は、構造化データは生成AI検索に必須ではなく、追加すべき特別なSchema.orgマークアップもないとしています。そのうえで、リッチリザルトの対象になるため、SEO全体の一部として使うのはよい、とも述べています。
筆者の整理：役割は従来どおり「ページ理解の補助」です。AI Overviewsに引用されやすくなるという根拠は、確認できていません。仕組みと対策はAI Overviewsの解説記事をご覧ください。
15. よくある質問
Q. 構造化データとは何ですか？
ページの情報が何を表すかを、検索エンジンに伝えるデータです。
Q. 設定すると順位は上がりますか？
保証されません。上がるという公式の説明は確認できていません。
Q. WordPressに設定は必要ですか？
必須ではありません。まず出力を確認し、足りない場合だけ追加します。
Q. SWELLには標準搭載されていますか？
公式サイトでJSON-LDの出力機能が案内されています。AFFICAMPのサイトでは、Articleなどの出力を確認しました。
Q. JSON-LDとは何ですか？
構造化データの記述形式の一つで、Googleが推奨しています。
Q. 設定しなくても問題ありませんか？
問題が起きるとは限りませんが、リッチリザルトの対象になる機会は減る場合があります。
Q. エラーは修正すべきですか？
エラーは対象外の原因なので、修正をおすすめします。警告は内容を見て判断します。
Q. どこで確認できますか？
リッチリザルトテスト、Schema Markup Validator、Search Consoleです。
Q. AI検索にも効果がありますか？
特別な構造化データは不要とGoogleは説明しており、効果の有無は確認できていません。
16. まとめ
- 構造化データは、ページの内容を伝える追加情報で、順位の上昇を保証しません
- 最初はテーマとプラグインの出力の確認です。確認はリッチリザルトテスト、ソース、Search Consoleで行います
- FAQPageとHowToは、2026年11月6日時点の公式情報では、検索機能として終了しています
- 表示内容と一致する情報を、必要な範囲だけ設定します
WordPressの設定や運用に不安がある方、SEOを意識したWebサイトを作りたい方は、ご相談ください。AFFICAMPは、WordPressを活用したホームページ制作、ブログ制作、SEOを意識したWebサイト設計を行っています。