構造化データは、実装した時点の検証で正しくても、CMSやテーマ、プラグインを更新すると、知らないうちに出力が変わり、一部が欠けたり、内容がずれたりすることがあります。壊れても、ページの見た目は変わらないため、利用者にも運営者にも気づかれにくいのが厄介な点です。ここでは、構造化データを公開した後の運用として、CMSの更新で壊れやすい箇所、検知の方法、変更のたびに確認する手順、壊れていたときの対応を、順に見ていきます。
- 構造化データの保守が必要になる理由
- CMSの更新で壊れやすい箇所
- 崩れを検知する方法
- 変更のたびに確認する手順と崩れていたときの対応
- 保守を始める最初の一歩
構造化データの保守が必要になる理由
構造化データの保守が必要なのは、出力が、ページの表示内容や、サイトの仕組みの変更に左右されるためです。実装は一度で終わっても、正しい状態を保つには、変更のたびの確認が要ります。
Google 検索セントラル「Google 検索上の構造化データ ガイドライン」（2026年10月30日閲覧）では、ページの読者に表示されないコンテンツをマークアップしないことと、構造化データがページコンテンツを正確に表している必要があることが示されています。また、構造化データの問題があるページには、手動による対策が実施される可能性があり、実施されるとリッチリザルトとして表示されなくなると説明されています。表示内容が変わったのに、構造化データが古いまま残ると、このガイドラインから外れた状態になりえます。実装の方法は、構造化データ実装完全ガイド｜AI引用に効くJSON-LDの書き方で整理しています。
CMSの更新で構造化データが壊れやすい箇所
壊れやすいのは、テーマ、プラグイン、投稿タイプやカスタムフィールド、日付、パンくずの5つです。構造化データの出力は、これらの仕組みから値を取り出して作られているためです。
| 変更 | 起こりうること | 確認する点 |
|---|---|---|
| テーマの更新 | 構造化データを出力する部分が上書きされ、出力が消える | 代表ページで出力が残っているか |
| プラグインの追加・停止 | 同じ種類のデータが二重に出力される、または出力が止まる | 同じ種類のデータが重複していないか |
| 投稿タイプ・カスタムフィールドの変更 | 項目の名前が変わり、値が空で出力される | 必須の項目に値が入っているか |
| 日付の扱いの変更 | 公開日や更新日が、ページの表示とずれる | 表示の日付と、データの日付が一致するか |
| URLやパンくずの変更 | パンくずのデータが、実際の階層と合わなくなる | パンくずの階層とリンク先が正しいか |
表の内容は、CMSで一般的に起こりうる事例の整理で、使っているCMSや構成によって、起きる箇所は変わります。当社は、自社サイトのテーマで構造化データを出力し、リッチリザルトテストで検証しています。テーマのように、出力の実装を自社で持つ場合は、更新のたびに、自分で出力を確認する責任があります。
構造化データの崩れを検知する方法
検知は、公開前の確認、定期の確認、Search Consoleでの確認の3つを組み合わせます。1つだけでは、見落とす崩れがあるためです。
公開前の確認は、更新を本番に反映する前に、リッチリザルトテストで、代表ページの出力を確かめます。定期の確認は、月に1回程度、代表ページを決めて出力を見直します。Search Consoleの確認は、リッチリザルトのレポートで、無効になった項目や、項目数の急な減少を見ます。
Search Console ヘルプ「リッチリザルト レポートの概要」（2026年10月30日閲覧）によれば、このレポートには、サイトで検出された構造化データと、その有効性が表示されます。一方、レポートは、検出されるすべてのアイテムを網羅したものではないとも説明されています。レポートに表示されないことだけでは、崩れていないとは判断できないため、代表ページの出力を、自分でも確認します。
変更のたびに確認する手順
変更のたびの確認は、代表ページの選定、出力の取得、前回との比較、記録の4つのステップで行います。ページ種別ごとに1〜2ページずつ選ぶと、確認の手間を抑えられます。
代表ページには、記事、サービスのページ、トップページ、問い合わせのページなど、種類の違う構造化データを出力しているページを選びます。更新の前後で、同じページの出力を比べ、項目が減っていないか、値が空になっていないか、表示と一致しているかを見ます。結果は、日付と変更の内容とあわせて、記録に残します。記録があれば、あとから崩れが見つかったときに、いつの変更が原因かをたどれます。
構造化データが崩れていたときの対応
崩れが見つかったら、影響の範囲、原因、対応の順に確かめます。まず、崩れが一部のページか、全体かを調べ、原因が直近の変更かを、記録と照らして探します。
原因が更新にあれば、更新を元に戻せるか、修正で直せるかを判断します。表示と合わない構造化データを残すより、一時的に出力を止める判断が、安全な場合もあります。直した後は、同じ代表ページで出力を確かめ、Search Consoleのレポートで、状態が戻っているかを後日確認します。技術面の点検の全体像は、テクニカルSEOの基礎知識とは｜クロールとインデックス最適化の手順が参考になります。
構造化データの保守を始める最初の一歩
最初の一歩は、構造化データを出力しているページの種類を書き出し、種類ごとに代表ページを1つ決めることです。この作業だけで、確認の対象と範囲が定まります。
書き出した代表ページを、次のCMSの更新の前後で確認するところから始めます。AI向けのファイルなど、ほかの施策の保守も同じ考え方で運用できます。たとえば、llms.txtを設置した後に何を更新するか｜更新の契機と確認手順の実務では、更新の契機と確認の手順を整理しています。運用の確認項目が増えすぎないよう、まず代表ページの確認を、更新の手順書に1行足すところから始めます。AI検索への対応全体は、AEO/LLMO対策の中で整理しています。
AEO/LLMO対策のサービス資料はこちら
施策内容・進め方・支援事例・費用をまとめた資料を無料でダウンロードいただけます。ChatGPT・Geminiから引用される状態をどうつくるのか、具体的な進め方をご確認ください。
よくある質問
Q 構造化データの保守は、なぜ必要ですか？
構造化データの出力が、ページの表示内容や、テーマ、プラグインなどの仕組みに左右されるためです。Googleのガイドラインは、構造化データがページコンテンツを正確に表している必要があるとしています。表示内容が変わっても出力が古いままだと、ガイドラインから外れた状態になりえます。
Q CMSの更新で、構造化データが壊れやすいのはどこですか？
テーマ、プラグイン、投稿タイプやカスタムフィールド、日付、パンくずの5つが壊れやすい箇所です。テーマの更新で出力が上書きされる、プラグインで同じデータが二重に出る、項目名の変更で値が空になる、といった事例が考えられます。使っているCMSによって起きる箇所は変わります。
Q 構造化データが壊れていないかは、どうやって確認しますか？
公開前の確認、定期の確認、Search Consoleの確認の3つを組み合わせます。公開前と定期は、代表ページの出力をリッチリザルトテストで確かめます。Search Consoleのレポートは、検出されるすべてのアイテムを網羅したものではないため、表示されないことだけでは、崩れていないと判断できません。
Q 構造化データの確認は、どのページで行えばよいですか？
構造化データの種類ごとに、代表ページを1〜2ページ選びます。記事、サービスのページ、トップページ、問い合わせのページなど、出力の種類が違うページが対象です。更新の前後で同じページの出力を比べ、項目が減っていないか、値が空でないか、表示と一致しているかを見ます。
Q 構造化データが壊れていたときは、まず何をしますか？
影響の範囲、原因、対応の順に確かめます。崩れが一部か全体かを調べ、記録と照らして直近の変更が原因かを探します。表示と合わない出力を残すより、一時的に出力を止める判断が安全な場合もあります。直した後は、代表ページで確かめ、後日Search Consoleでも状態を確認します。
