はじめに
Rank MathのカスタムSchemaは、WordPressサイトに構造化データを柔軟に追加できる便利な機能です。一方で、テンプレート化・変数差し込み・カスタムフィールド連携を組み合わせるほど、JSON-LDのエラーや意図しないSchema出力が起きやすくなります。
構造化データは、Googleにページ内容を明確に伝えるための標準化された形式です。Googleも、構造化データによってページ内容の意味を検索エンジンに伝えられると説明しています。
しかし、構造化データは「入れればSEOに効く魔法のタグ」ではありません。ページ上に存在しない情報をSchemaだけに記述したり、誤った型や空の値を出力したりすれば、リッチリザルトの対象外になるだけでなく、Search Console上のエラー管理も複雑になります。
この記事では、Rank MathのカスタムSchema運用で起こりやすいエラーを、変数設計・ACF連携・Display Conditions・検証フローの4つの観点から整理します。元資料では、変数バインディング、ACFリピーター、条件表示、検証ループを中心に、カスタムSchema運用のエラー防止設計が整理されています。
Rank MathのカスタムSchemaでエラーが起きる理由
Rank MathのCustom Schema Builderでは、プロパティやプロパティグループを追加し、ページごとのSchemaを作成できます。作成したSchemaはテンプレートとして保存し、複数ページへ再利用することも可能です。
この「再利用できる」という利点が、同時にエラーの温床にもなります。1ページだけであれば見落としで済むミスも、テンプレートに組み込まれると、カテゴリ全体・商品群全体・記事群全体へ一気に広がるからです。
たとえば、次のようなケースです。
- 商品価格が未入力なのに
offers.priceを出力してしまう - 著者情報が空欄なのに
author.nameが空文字になる - FAQ本文がページ上に存在しないのに
FAQPageだけを出力する - ACFのリピーターフィールドを配列として扱うべきところを単一値で出力する
- 特定カテゴリだけに出すSchemaが、別カテゴリにも適用される
特に注意したいのは、JSON-LDの文法エラーだけが問題ではないという点です。JSONとしては正しくても、ページ内容と一致していなければ、構造化データとしては不適切です。Googleは、構造化データは対象ページ上の内容を説明するものであり、ユーザーに表示されていない情報を追加すべきではないと説明しています。
エラー防止の第一歩は「変数設計」を固めること
Rank MathのCustom Schema Builderは変数に対応しており、投稿やページ内にある既存データを参照してSchemaへ自動反映できます。Rank Math公式ドキュメントでも、変数を使えば既存の投稿データをSchemaプロパティへ差し込めると説明されています。
ただし、変数は便利な反面、「値が必ず存在する」という前提で使うと危険です。タイトル、アイキャッチ画像、公開日、更新日、著者名、商品価格、SKU、在庫情報などは、サイト運用のなかで未入力・表記ゆれ・形式違いが起きやすい項目です。
そのため、Schemaテンプレートを作る前に、まず「変数台帳」を作るべきです。
変数台帳で整理すべき項目
変数台帳には、最低限以下を整理します。
| 項目 | 確認内容 |
|---|---|
| 使用するSchemaタイプ | Article、Product、FAQPage、LocalBusinessなど |
| 参照する変数 | タイトル、URL、画像、価格、著者、カテゴリなど |
| 入力元 | WordPress標準項目、ACF、WooCommerce、独自フィールド |
| 空欄時の扱い | 出力しない、代替値を使う、公開前に差し戻す |
| 値の形式 | URL、日付、数値、テキスト、配列 |
| 検証方法 | Rich Results Test、Schema Markup Validator、Search Console |
重要なのは、空欄時に「Not Provided」「未設定」「0」などの仮値を安易に出力しないことです。とくに価格・レビュー・在庫・日付・URLは、仮値が残ると検索結果上の表示や検証結果に悪影響を与える可能性があります。
Schemaは「埋めること」よりも「正しい値だけを出すこと」が優先です。
ACFやカスタムフィールド連携では型のずれに注意する
Rank MathのカスタムSchema運用では、ACFや独自カスタムフィールドと連携したくなる場面が多くあります。たとえば、商品仕様、導入事例、FAQ、イベント情報、拠点情報、レビュー情報などです。
ここで起きやすいのが、「WordPress上の入力形式」と「Schema.orgが期待する構造」のずれです。
たとえば、ACFのリピーターフィールドで複数のFAQを管理している場合、Schema側ではmainEntityに複数のQuestionを配列として出力する必要があります。ところが、単なるテキスト結合で出力してしまうと、JSON-LDとしては成立しても、Schema構造として意味が崩れる可能性があります。
Rank MathのCustom Schema Generatorでは、複数のプロパティグループを配列として扱う設計が可能です。公式ドキュメントでも、複数項目を配列として追加できることが説明されています。
実務では、ACF連携を行う前に、次の順番で設計します。
- どのSchemaタイプを使うか決める
- 必須プロパティと推奨プロパティを確認する
- WordPress側の入力欄をSchema構造に合わせて設計する
- 空欄・複数値・画像未設定時の扱いを決める
- 実ページでJSON-LDを確認する
この順番を逆にして、「すでにある入力欄を無理にSchemaへ当てはめる」と、後から修正が難しくなります。
Display Conditionsは「出す条件」より「出さない条件」が重要
Rank MathのSchema Templatesでは、Display Conditionsを使って特定の投稿タイプ、カテゴリ、ページなどにSchemaを自動適用できます。Rank Math公式ドキュメントでも、Display ConditionsによりSchemaをルールに基づいて適用できると説明されています。
この機能は、大規模サイトでは非常に便利です。記事一覧、商品カテゴリ、店舗ページ、導入事例ページなどに対して、Schemaを一括で適用できるからです。
しかし、条件設定が甘いと、本来出すべきではないページにもSchemaが出力されます。
たとえば、次のようなミスです。
- 商品詳細ページ以外にもProduct Schemaが出る
- FAQがない記事にもFAQPageが出る
- 店舗ページ以外にもLocalBusinessが出る
- 一覧ページと詳細ページで同じSchemaが重複する
- テーマや別プラグインのSchemaとRank MathのSchemaが二重出力される
Display Conditionsでは、「どこに出すか」だけでなく「どこには絶対に出さないか」をセットで考える必要があります。
特に、Include条件だけで広く適用するのは危険です。カテゴリ、投稿タイプ、固定ページ階層、カスタム投稿タイプ、タクソノミーを組み合わせ、Exclude条件も明示的に設計しましょう。
Product Schemaでは価格・レビュー・在庫情報の整合性を見る
ECサイトや商品紹介ページでは、Product Schemaの運用が重要になります。GoogleはProduct構造化データについて、商品名に加え、review、aggregateRating、offersのいずれかを含める必要があると説明しています。
ここで問題になりやすいのが、価格や在庫の更新漏れです。
WordPressやWooCommerce側では価格が変更されているのに、Schema側では古い価格が残っている。あるいは、在庫切れの商品なのにInStockのまま出力されている。このような状態は、検索結果上の情報と実ページの情報の不一致につながります。
Product Schemaでは、以下を定期的に確認します。
- 商品名とページ上の商品名が一致しているか
- 価格が税込・税抜の表示方針とずれていないか
- 通貨コードが適切か
- 在庫状況が実際の商品状態と一致しているか
- レビュー数や評価値が実データに基づいているか
- SKUやGTINなどの識別子に表記ゆれがないか
商品ページのSchemaは、SEOだけでなく、顧客に誤解を与えないための情報管理でもあります。
FAQPage Schemaは今後の扱いを見直すべき
これまでFAQPage Schemaは、検索結果上のFAQ表示を狙う施策として使われてきました。しかし、Google公式ドキュメントでは、2026年5月7日以降、FAQリッチリザルトはGoogle検索に表示されなくなり、2026年6月にFAQ検索外観・リッチリザルトレポート・Rich Results Testでのサポートを終了する予定とされています。
そのため、現在のFAQPage Schemaは「検索結果でFAQを広く表示させるため」ではなく、「ページ内容を構造化して整理するため」に位置づけを変える必要があります。
とくに一般企業サイトでは、FAQPageを大量に自動出力する優先度は下がっています。ページ上に明確なFAQがあり、構造化する意味がある場合に限定するほうが安全です。
FAQPageを使う場合も、次の点は必ず確認します。
- 質問と回答がページ上に実際に表示されているか
- 1問1答の形式になっているか
- 回答文が広告的・過剰表現になっていないか
- ユーザー投稿型のQ&AにFAQPageを使っていないか
- テンプレートだけが残り、空のFAQが出力されていないか
FAQ Schemaは、今後「入れるほど得をするもの」ではなく、「必要なページだけに正しく入れるもの」と考えるべきです。
検証は3段階で行う
Rank MathのCustom Schema BuilderにはCode Validationタブがあり、作成したSchemaのJSON-LDを確認できます。Rank Math公式ドキュメントでも、Code ValidationでJSON-LDを生成し、構造化データのエラー確認に使えると説明されています。
ただし、Rank Math内の確認だけで終わらせるのは不十分です。実務では、次の3段階で検証します。
1. Rank Math内でJSON-LDを確認する
まず、Schema Builder上で構造を確認します。プロパティの階層、配列の位置、変数の差し込み、空欄時の出力を見ます。
ここでは、主に「作ったSchemaが意図した構造になっているか」を確認します。
2. Schema Markup Validatorで文法を確認する
Schema Markup Validatorは、Schema.orgベースの構造化データを検証するためのツールです。JSON-LD、RDFa、Microdataを抽出し、構造化データグラフの概要や構文ミスを確認できます。
ここでは、主に「Schema.orgとして破綻していないか」を確認します。
3. Rich Results TestでGoogle上の対象可否を確認する
Googleは、リッチリザルト生成の可能性を見るにはRich Results Testから始めることを推奨しています。また、一般的なSchema検証にはSchema Markup Validatorを使うと説明しています。
ここでは、主に「Google検索上のリッチリザルト対象になり得るか」を確認します。
この3つは役割が異なります。
Schema Markup Validatorで問題がなくても、Googleのリッチリザルト対象になるとは限りません。逆に、Rich Results Testに出ないSchemaでも、Schema.orgとして意味を持つ場合があります。
公開後はSearch Consoleで監視する
Schemaは、公開前の検証だけでは終わりません。Googleは、構造化データを初めて公開した後やテンプレート・コードを更新した後に、Search Console上で無効な項目の増加を確認することを推奨しています。
特に、Rank MathのテンプレートSchemaを更新した直後は注意が必要です。1つのテンプレート修正が、数十ページ・数百ページに影響する可能性があります。
公開後に見るべき項目は以下です。
- Search Consoleの拡張レポートにエラーが増えていないか
- 有効アイテム数が急に減っていないか
- 特定の投稿タイプだけでエラーが出ていないか
- 商品ページだけ、FAQページだけなど偏りがないか
- テーマ更新やプラグイン更新後にSchema出力が変わっていないか
Schema運用は「設定」ではなく「監視を含む運用」です。
PHPで制御する場合は管理場所を分ける
高度なSchema運用では、Rank Mathの画面設定だけでなく、PHPフィルターでJSON-LDを制御する場合もあります。
Rank Math公式ドキュメントでは、フィルターやフックをfunctions.phpではなく、テーマ内のrank-math.phpに追加する方法が推奨されています。理由として、テーマ切り替え時の管理性、Rank Math有効時のみコードが動くこと、Rank Math関連機能を正しく動かしやすいことが挙げられています。
実務上も、Schema関連のコードは分散させないほうが安全です。
- Rank Math画面で管理するSchema
- ACF側で入力する項目
- PHPで制御する出力条件
- テーマや別プラグインが出すSchema
これらがバラバラに管理されると、エラー発生時に原因を追えなくなります。Schema運用では、どこで何を出しているかを一覧化しておくことが重要です。
Rank MathのカスタムSchema運用チェックリスト
最後に、実務で使えるチェックリストを整理します。
設計前
- 対象ページに本当にSchemaが必要か
- ページ上に表示されている情報だけを構造化しているか
- Schemaタイプは適切か
- 必須プロパティと推奨プロパティを確認したか
- 既存テーマや別プラグインのSchemaと重複しないか
テンプレート作成時
- 変数の入力元を明確にしたか
- 空欄時の出力ルールを決めたか
- ACFの配列・リピーター項目を正しく扱っているか
- Display ConditionsのIncludeとExcludeを両方設定したか
- 商品・FAQ・店舗など、ページ種別ごとにテンプレートを分けたか
公開前
- Rank Math内でJSON-LDを確認したか
- Schema Markup Validatorで構文確認したか
- Rich Results TestでGoogle上の対象可否を確認したか
- 実ページの表示内容とSchema内容が一致しているか
- 複数ページでテストしたか
公開後
- Search Consoleでエラー増加を確認したか
- テーマ更新・プラグイン更新後に再検証したか
- 商品価格や在庫など変動情報の更新漏れがないか
- 不要になったSchemaを削除したか
- 運用担当者が変更しても管理できる状態か
まとめ
Rank MathのカスタムSchemaは、構造化データを柔軟に運用できる強力な機能です。しかし、便利だからこそ、テンプレート化・変数差し込み・ACF連携・条件表示の設計を誤ると、エラーが広範囲に波及します。
大切なのは、Schemaを「SEO設定の追加項目」として扱わないことです。Schemaは、ページ上の情報を検索エンジンに正しく伝えるためのデータ設計です。
そのためには、変数台帳を作り、空欄時の出力ルールを決め、Display Conditionsを厳密に管理し、Rank Math内の確認だけでなくSchema Markup Validator、Rich Results Test、Search Consoleまで含めた検証ループを運用に組み込む必要があります。
今後は、FAQリッチリザルトの終了など、Google側の扱いも変化していきます。Rank MathのカスタムSchema運用では、「一度作ったら終わり」ではなく、検索仕様・サイト構造・商品情報の変化に合わせて、継続的に見直す体制が求められます。
コメント