構造化データSchema完全ガイド：Article／FAQ／Product／Breadcrumbの書き方
1. JSON-LDの書き方の総則
Googleが推奨するのはJSON-LD構文で、MicrodataやRDFaは使わないでください。書き方には3つの鉄則があります。
| ルール | 正しい方法 | 誤ったやり方 |
|---|---|---|
| 構文 | <script type=”application/ld+json”> | MicrodataやRDFaを使う |
| 位置 | headまたはbodyの末尾 | JSで動的に注入した後、レンダリングを待つ |
| フィールドの値 | ページ上の表示テキストと一字一句一致 | Schemaに「999ドル」、ページに「お問い合わせ」と書く |
| 複数タイプ | @type配列またはmainEntityOfPageで相互リンク | 同じページに無関係なタイプを6〜7個詰め込む |
JSON-LDが推奨される理由：HTML構造と切り離されているため、テンプレートを保守する際にDOMを変更してもマークアップが壊れません。Microdataはタグの属性に埋め込まれるため、classを1つ変えるだけで連鎖的に壊れる可能性があります。
もう2つ見落とされがちな点があります。1つ目は、すべての日付フィールドはタイムゾーンオフセット付きのISO 8601形式で書く必要があることです。例えば2026-09-21T09:00:00+08:00のように書き、「2026年9月」とは書かないでください。2つ目は、URLフィールドはGoogleが直接クロールできる必要があり、ログインしないとアクセスできない管理画面のリンクを書いてはいけません。この2種類の問題はRich Results Testでは警告が出るだけでエラーにならないため、見落とされやすいです。
2. Article：ブログとホワイトペーパーのページ
Articleは記事ページの基本マークアップで、SERPに著者の顔写真、公開日時、サムネイルのカルーセルが表示されるかどうかを左右します。
| フィールド | 必須 | 記入例 | 説明 |
|---|---|---|---|
| @type | はい | Article | ニュースにはNewsArticle |
| headline | はい | 110文字以内 | <title>と一致させる |
| author | はい | {“@type”:”Person”,”name”:”崔立姝”} | 著者ページへのリンクも併記する |
| datePublished | はい | 2026-09-21T09:00:00+08:00 | ISO 8601形式 |
| dateModified | 推奨 | datePublishedと同じか更新日時 | 記事をリニューアルしたら更新する |
| 画像 | はい | 最低1200×675ピクセル | カルーセルのサムネイルに影響 |
| publisher | 推奨 | Organizationと関連付ける | logoフィールドを含める |
事例：あるB2BブログでArticleを追加したものの、imageに600×300の小さい画像を使っていたため、Rich Results Testで「image too small」と報告されました。1200×675のカバー画像に差し替えたところ、1週間以内にSERPの記事カルーセルに表示されるようになりました。画像サイズの要件はこちらをご覧くださいメディア資産の管理。
author フィールドには会社名だけでなく、具体的な著者名を書いて著者ページにリンクさせます。Google はナレッジパネルと著者画像のカルーセルでこのフィールドを読み取ります。「crater」とだけ書いても Person にも Organization にもならず、マークアップは無視されます。著者ページ自体はサイト内でアクセス可能にし、SameAs に LinkedIn や GitHub などの外部プロフィールを登録します。
三、FAQPage：AI 回答への主要な経路
FAQPage は 2023 年以降、一般企業のブログでは SERP のリッチリザルトに表示されなくなりましたが、ChatGPT、Gemini、Google AI Overviews が Q&A を読み取る主要な経路であり続けています。
| フィールド | 必須 | 説明 |
|---|---|---|
| @type | はい | FAQPage |
| mainEntity[] | はい | Question 配列、5 から 6 個 |
| name | はい | 質問の原文、ページの summary と一致させる |
| acceptedAnswer.text | はい | 回答のプレーンテキスト、ページ上の表示テキストと一致させる |
直感に反する点：FAQPage の SERP 折りたたみブロックは 2023 年 8 月以降、権威あるフォーラムと政府サイトでのみ表示され、一般の B2B ブログでは追加しても表示されません。それでも書くことをおすすめします。AI エンジンが FAQ を読む主要な経路が mainEntity 配列だからです。FAQ コンテンツの方法論はこちらFAQ と People Also Ask。
レッドライン：mainEntity 内の Q&A はページ上に表示されている FAQ と完全に一致させる必要があり、ページに存在しない Q&A を書いてはいけません。Google の FAQ スパムマークアップに対する手動対策はこれを対象としています。
質問と回答の長さにも注意が必要です。質問は 20 から 40 文字、回答は 80 から 150 文字に収めます。質問が短すぎるとキーワードの詰め込みに見え、長すぎると SERP の折りたたみブロックの表示範囲を超えます。回答が短すぎると情報密度が足りず AI が引用せず、長すぎると切り捨てられます。
四、Product：B2B 製品ページの高収益エリア
Product マークアップは、製品カード、価格、在庫状況が SERP に表示されるかを決めます。B2B のセミカスタム製品では慎重に。
| フィールド | 必須 | B2B の注意点 |
|---|---|---|
| name | はい | 製品型番の正式名称、H1 と一致させる |
| 画像 | はい | メイン画像、製品画像は最低 3 枚あるとより確実 |
| 説明 | 推奨 | 製品ページの meta description と一致させる |
| brand | 推奨 | {“@type”:”Brand”,”name”:”…”} |
| offers.price | 明確な価格がある場合 | 見積もり依頼の製品には price を入れない |
| offers.availability | 推奨 | InStock / PreOrder、勝手に付けない |
| aggregateRating | 実際のレビューがある場合 | 実在しない評価で星を付けると手動対策の対象になる |
シナリオ例二：ある B2B 機器メーカーの製品ページに offers.price=5000 と記述したが、ページ上には「見積もり依頼」としか書かれていなかった。Rich Results Test でフィールドの不一致警告が出て、2 週間後 GSC のリッチリザルトレポートでその製品ページのリッチリザルト表示回数がゼロになった。price フィールドを削除し、availability を PreOrder に変更したところ、表示回数が回復した。
価格フィールドの不一致は Product マークアップで最も多い事故の原因です。B2B のセミカスタム製品ページで価格を公開していない場合、SERP カードのために無理に価格を入れないでください。
五、BreadcrumbList：全サイトで必須
BreadcrumbList を使うと、Google は長い URL の代わりにパンくずリストを SERP に表示します。全サイトで最もコストの低い Schema です。
| フィールド | 必須 | 説明 |
|---|---|---|
| @type | はい | BreadcrumbList |
| itemListElement[] | はい | トップページから現在のページまでの完全なパス |
| position | はい | 1 から連番 |
| name | はい | パンくずに表示するテキスト |
| item | 推奨 | その階層の絶対 URL |
item フィールドには必ず絶対 URL を指定し、相対パスは使わないでください。階層はページに表示されるパンくずと一致させます。トップ → カテゴリ → サブカテゴリ → 現在のページという順序を守り、階層を飛ばさないこと。現在のページ自体も itemListElement に含めないと、Google はパンくずがどのページを指しているのか判断できません。
6. 公開前の3ステップ検証
| ステップ | ツール | 期限 | 合格基準 |
|---|---|---|---|
| URL ごとに検証 | リッチリザルトテスト | 公開当日の前 | エラーなし、許容範囲の警告のみ |
| 公開後の抜き取り確認 | 本番 URL でもう一度実行 | 公開当日 | レンダリング結果がローカルと一致 |
| リッチリザルトレポート | Search Console | 7日目、14日目、30日目 | 表示回数が0でなく、エラーが0 |
4種類の Schema は B2B サイトの基本です。Organization と WebSite は全ページの head に必ず入れる残り2種類で、優先度の判断は構造化データSchemaをご覧ください。多言語サイトでは Schema のフィールドと多言語の数値と表のローカライズを一致させ、通貨や単位が言語をまたいで混ざらないようにします。
最後によくある事故の原因が、プラグインが自動生成する重複 Schema です。WordPress サイトに Yoast や Rank Math を入れると、プラグインが既定で Article や Organization のマークアップを出力します。そこに手書きの JSON-LD を追加すると duplicate field の警告が出ます。公開前に Rich Results Test で商品ページと記事ページを確認し、重複フィールドがあればプラグインの該当モジュールをオフにして、手書きの方を残してください。
7. Schema 公開後の月次チェック
Schema は書いたら終わりではありません。テンプレートの変更、商品の入れ替え、価格の調整で、フィールドとページ上の表示内容は再びずれていきます。月に半日かけて点検する方が、事故が起きてから直すよりずっと楽です。
| 点検項目 | チェック方法 | 頻度 | 合格基準 |
|---|---|---|---|
| GSC のリッチリザルトレポートのエラー | Search Console の体験レポート | 毎月 | エラー0件、警告は許容範囲 |
| フィールドと表示テキストの一致 | 10ページを抜き取り Rich Results Test で確認 | 毎月 | フィールド不一致の警告なし |
| Product の価格同期 | 商品ページの price フィールドと表示価格を比較 | 価格改定後 | 問い合わせ商品には price フィールドを残さない |
| Breadcrumb のパス | 下層ページを抜き取りパンくずと照合 | リニューアル後 | 階層を飛ばさず、item は絶対 URL |
| 重複 Schema | ページソースの ld+json ブロック数を確認 | 新しいプラグインを入れた後 | プラグインと手書きの重複出力なし |
点検で問題を見つけても、すぐサイト全体を直そうとしないでください。まずテスト環境で再現し、テンプレートの問題か単一ページの問題かを見極めます。テンプレートの問題なら全ページに影響するので、テンプレートを1回直せば済みます。単一ページの問題は、編集者が価格や日付を打ち間違えたケースがほとんどなので、ページごとに修正します。毎月の点検結果は1ページの台帳に記録しておきましょう。3か月もすればどの種類のエラーが繰り返し出るかが見えてくるので、それを編集マニュアルに書き込み、同じ事故を根本から減らせます。
最後にひとつ。Schema は検索エンジンと AI エンジンが読むもので、訪問者に見せるものではありません。フィールドの値はページの実際の内容を正直に反映させてください。リッチリザルト目当てに価格を偽ったり、レビューの星を水増ししたりしてはいけません。Google のスパム構造化データによる手動対策が発動すると、回復には四半期単位の時間がかかり、割に合いません。
多言語サイトでは Schema フィールドの言語統一にも注意が必要です。英語ページの JSON-LD は英語で、日本語ページは日本語で記述し、混在させないでください。通貨フィールドはその言語ページで表示する通貨に合わせ、欧州向けページに米ドルを入れないこと。日付形式は ISO 8601 に統一し、”9/21/2026″ のような地域慣習による曖昧な表記は避けてください。こうした細部は Rich Results Test ではエラーになりませんが、AI エンジンの抽出精度に影響します。
FAQ よくある質問
Article の headline フィールドは長めに書いてもいいですか？
FAQPage の Q&A はページ上より多くてもいいですか？
Product ページで価格を公開していない場合、offers はどう書きますか？
BreadcrumbList の item フィールドに相対パスを使ってもいいですか？
同じページに Article と BreadcrumbList を同時に設置できますか？
Schema を公開してからリッチリザルトが表示されるまでどのくらいかかりますか？
最後に
4 種類のコア Schema は B2B 公式サイトの最小構成です。Article はブログ、FAQPage は AI 回答、Product は製品ページ、BreadcrumbList は全サイトに。正しく書いてもリッチリザルトが出るとは限りませんが、間違えれば資格を失います。
導入は3ステップ。今週は Rich Results Test でテンプレートページを5つ監査し、不足している型を洗い出す。来週は4種類の JSON-LD テンプレートを head に追加し、フィールドの値と表示テキストを一字一句合わせる。30日目に Search Console のリッチリザルトレポートでエラーゼロを確認する。
覚えておきたい一言。Schema は多ければいいのではなく、正確であるほどいい。フィールドがページと一致し、数値が見積もりと一致し、Q&A が FAQ と一致して、はじめてリッチリザルトが表示される。