ank MathのカスタムSchema運用は「作る」より「壊さない」設計が重要
Rank Mathを使えば、WordPress上でArticle、Product、FAQ、LocalBusinessなどの構造化データを比較的手軽に設定できます。公式ドキュメントでも、Custom Schema Builderを使って独自のSchemaを作成し、ページやテンプレートに適用できることが示されています。
しかし、カスタムSchemaの運用で本当に難しいのは、Schemaを一度作ることではありません。問題は、記事更新、商品情報の変更、ACFの追加、WooCommerceの商品管理、テーマ変更、プラグイン更新などが重なったときに、JSON-LDの出力が壊れない状態を保つことです。
構造化データは検索エンジンにページ内容を伝えるための補助情報です。Schema.orgは、検索エンジンなどがWebページ上の情報を理解しやすくするための語彙体系を提供しています。 一方で、Googleは構造化データについて、ページ内容と関係のない情報や誤解を招くマークアップを避けるよう求めています。
つまり、Rank MathのカスタムSchema運用では「リッチリザルトを狙う」だけでなく、「事実と一致したデータを、継続的に、壊さず出力する」ことが重要になります。元資料でも、Rank MathのカスタムSchema運用におけるリスクとして、JSON-LD構文エラー、動的変数の欠落、Schemaの重複、データベース上の破損、検証不足が整理されています。
Rank MathのカスタムSchemaで起こりやすいエラー
JSON-LDの構文崩れ
もっとも分かりやすいエラーは、JSON-LDそのものの構文崩れです。
たとえば、カスタムSchema内に手入力した値に引用符や改行が混じったり、ACFなどのカスタムフィールドから取得した値が想定外の形式だったりすると、JSON-LDとして正しく解釈されない可能性があります。
構造化データはHTML上では見えにくいため、ページ表示に問題がなくても、検索エンジン側ではエラーとして扱われることがあります。ここが通常の本文編集と大きく違う点です。
必須項目の欠落
Product Schemaで商品名や価格、在庫状況などが不足する。Article Schemaで見出しや画像が空になる。FAQ Schemaで質問だけがあり、回答が空欄になる。
このような必須項目・推奨項目の欠落も、Rank Math運用で起こりやすい問題です。
Rank Mathでは、%title% や %excerpt% などの変数を使ってSchemaに値を流し込めます。しかし、元データが未入力であれば、Schema側にも空の値が出力される可能性があります。便利な変数ほど、元データが空だった場合の逃げ道を用意しておく必要があります。
Schemaの重複出力
Rank Mathだけでなく、テーマや別のSEOプラグイン、パンくずリスト機能、WooCommerce関連機能が同時にSchemaを出力している場合、同じページ内に似た構造化データが重複することがあります。
とくに、WebSite、Organization、BreadcrumbList、Product、Articleなどは複数の機能から自動出力されやすい領域です。
重複そのものが常に致命的とは限りませんが、異なる情報が同時に出力されると、検索エンジンに対してページの意味を曖昧に伝えてしまう可能性があります。
ACFやカスタムフィールドとの連携ミス
高度なWordPressサイトでは、Advanced Custom Fields（ACF）で商品情報、FAQ、事例情報、店舗情報などを管理しているケースがあります。
Rank MathはACFフィールドをSchemaに利用できますが、リピーターフィールドや柔軟コンテンツのような複雑なデータ構造では、単純な変数展開だけでは対応が難しい場合があります。Rank Math公式も、ACFを使ったFAQ Schema生成では、フロントエンド側で rank_math/json_ld フィルターを使う方法に触れています。
ACF連携では、「入力欄があるからSchemaにも出せる」と単純に考えない方が安全です。配列、空欄、改行、HTMLタグ、特殊文字をどう処理するかまで設計しておく必要があります。
エラーを防ぐ基本設計
1. Schema Templatesで個別設定を減らす
Rank Math PROのSchema Templatesを使うと、特定の投稿タイプやカテゴリーに対してSchemaをテンプレートとして適用できます。公式ドキュメントでも、Display Conditionsを使ってSchema Templateの表示条件を設定できることが説明されています。
個別記事ごとにSchemaを手作業で設定すると、担当者によって入力ルールがずれます。記事数が増えるほど、設定漏れや表記ゆれも増えます。
基本方針は、できるだけテンプレート化することです。
たとえば、コラム記事はArticle、商品紹介ページはProduct、FAQページはFAQPage、会社概要ページはOrganizationまたはLocalBusinessというように、ページの種類ごとにSchemaの型を決めておきます。
そのうえで、個別に編集する項目を最小限に絞ると、運用ミスを減らしやすくなります。
2. Display Conditionsで適用範囲を絞る
テンプレートを作っても、適用範囲が広すぎると別のエラーを招きます。
たとえば、すべての投稿にProduct Schemaを適用してしまえば、商品ではない記事にも商品情報が出力されます。FAQのないページにFAQPage Schemaを適用すれば、中身のないFAQ構造が出る可能性もあります。
Display Conditionsでは、投稿タイプ、カテゴリー、タグ、個別ページなどを条件にして、Schemaを出す範囲を管理します。
「全ページに出す」のは、WebSiteやOrganizationなど一部の基本情報に限るべきです。Article、Product、FAQ、Reviewなどは、ページ内容と一致する場所だけに絞って適用する方が安全です。
3. 動的変数には必ずフォールバックを用意する
Rank Mathの変数は便利ですが、元データが空だったときの扱いを考えておかないと、空欄のSchemaが出力されます。
たとえば、アイキャッチ画像が未設定ならデフォルト画像を使う。抜粋が空なら本文冒頭やメタディスクリプションを使う。商品価格が未入力なら、そのSchema項目を出力しない。
このようなフォールバック設計が必要です。
重要なのは、「空でもとりあえず出す」のではなく、「空なら出さない」「代替値を使う」「公開前に止める」のどれにするかを決めておくことです。
4. WooCommerceの商品Schemaは表示内容と一致させる
ECサイトでは、Product Schemaの扱いに注意が必要です。
GoogleのProduct構造化データでは、商品情報が検索結果に使われる可能性があります。 そのため、ページ上の表示内容とSchema内の価格、在庫、レビュー、評価などがずれている状態は避けるべきです。
たとえば、フロント画面では価格を非表示にしているのに、JSON-LDには価格が残っている。レビューを表示していないのに、Schemaだけに評価情報がある。このような状態は、ユーザーにも検索エンジンにも不自然です。
商品ページでは、管理画面、ページ表示、JSON-LD出力の3つが一致しているかを確認する必要があります。
検証フローを運用に組み込む
Rank Math内のCode Validationだけで終わらせない
Rank MathのCode Validationは、Schema作成中の確認には役立ちます。ただし、テンプレート作成画面では動的変数が実データに置き換わっていないことがあります。
そのため、本当に確認すべきなのは、公開または下書きプレビュー状態の実ページです。
テンプレート上では問題がなくても、実ページではアイキャッチ画像がない、抜粋が空、ACFの値が未入力、商品価格が未設定といった理由でエラーが出ることがあります。
Googleのリッチリザルトテストで最終確認する
Googleは、検索でサポートされる構造化データの種類を公開しています。 また、レビューや評価についても、対象となる型や表示条件に関するガイドラインを示しています。
Rank Math側でSchemaを作成したら、最終的にはGoogleのリッチリザルトテストで確認する流れを運用に入れるべきです。
確認するポイントは、主に次の4つです。
- JSON-LDの構文エラーがないか
- ページ内容とSchema内容が一致しているか
- 必須項目が欠けていないか
- 不要なSchemaや重複Schemaが出ていないか
とくに、記事テンプレートや商品テンプレートを変更した直後は、1ページだけでなく、複数パターンのページを確認することが重要です。
運用担当者が決めておくべきルール
Schemaを編集できる人を限定する
Rank MathのカスタムSchemaは、SEO設定でありながら、実質的にはサイトのデータ構造を扱う作業です。
そのため、誰でも自由に変更できる状態は危険です。記事担当者が触る項目、SEO担当者が触る項目、開発者が触る項目を分けておくべきです。
たとえば、記事担当者はタイトル・抜粋・アイキャッチ画像を正しく入れる。SEO担当者はSchemaテンプレートと適用条件を管理する。開発者はACF連携や rank_math/json_ld フィルターの制御を担当する。
このように役割を分けると、問題が起きたときの原因特定もしやすくなります。
変更履歴を残す
構造化データのトラブルは、あとから原因を探すのが大変です。
ある日突然、リッチリザルトが表示されなくなった。Search Consoleで警告が出た。商品ページのSchemaだけエラーになった。
このような場合、直近で誰が何を変更したかが分からないと、復旧に時間がかかります。
WP Activity Logのような監査ログ系プラグインを使い、Rank Mathの設定変更、投稿のSEOタイトル変更、メタディスクリプション変更、robots設定変更などを追える状態にしておくと安心です。
CSV一括編集はバックアップ後に行う
大規模サイトでは、SEOタイトルやメタディスクリプション、カスタムフィールドをCSVで一括編集することがあります。
この方法は効率的ですが、ミスがあると大量のページに同じ問題が広がります。
一括編集前には、必ずバックアップを取ります。また、全件反映する前に、少数ページでテストし、JSON-LDの出力まで確認してから本番反映する流れが必要です。
中小企業サイトでの実践ポイント
中小企業のWebサイトでは、専任のSEOエンジニアがいないことも多く、Rank Mathのようなプラグインに頼る場面が増えます。
だからこそ、最初から複雑なカスタムSchemaを作り込むより、まずは壊れにくい運用を優先すべきです。
おすすめの進め方は、次の順番です。
まず、記事ページにはArticle Schemaを安定適用する。次に、会社概要や店舗情報にOrganizationまたはLocalBusinessを整理する。その後、商品ページやFAQページなど、成果に直結しやすいページから個別にSchemaを強化する。
いきなり全ページを高度に構造化しようとすると、運用が追いつきません。小さく始めて、検証できる範囲で広げる方が現実的です。
特に、AI検索やAEOを意識するなら、構造化データは「検索結果の装飾」ではなく、サイト内の情報を機械が理解しやすい形に整える基盤として考えるべきです。
まとめ：Rank MathのSchema運用はテンプレート・検証・監査で安定する
Rank MathのカスタムSchemaは、WordPressサイトのSEOを強化する有効な手段です。ただし、自由度が高い分、設定ミス、動的変数の欠落、Schemaの重複、ACF連携ミス、WooCommerceの商品情報不一致などのリスクもあります。
安定運用の基本は、個別作業を減らしてSchema Templatesに集約することです。そのうえで、Display Conditionsで適用範囲を絞り、変数にはフォールバックを用意し、公開前後にリッチリザルトテストで確認します。
さらに、誰が何を変更したかを追える監査ログを残し、CSV一括編集やデータベース操作の前には必ずバックアップを取る。ここまで含めて、初めて「壊れにくい構造化データ運用」といえます。
今後のSEOでは、検索エンジンだけでなく、生成AIやAI検索に対しても、ページ内容を正確に伝えることが重要になります。Rank MathのカスタムSchemaは、そのための便利な道具です。しかし、道具を入れるだけでは十分ではありません。継続して正確なデータを出し続ける運用設計こそが、サイトの信頼性を支える土台になります。
コメント