構造化データを壊さない運用

— 01

なぜ構造化データは壊れるか

Next.js（App Router）とStrapi v5でメディアを運用すると、Article・FAQPage・BreadcrumbList・ItemListといったJSON-LDをページごとに大量に吐き出すことになります。これらは一度書けば終わりではなく、CMSのデータ構造やビルド方式が絡み合って、気づかないうちに壊れます。

JSON-LDが厄介なのは、壊れてもビルドが通ってしまう点にあります。JSON.stringifyは不正な値でも素直に文字列化しますし、npm run buildはスキーマの妥当性を一切検証しません。結果として、必須プロパティのundefined化・ISO8601非準拠の日付・解決できない@id参照・本文中のscript閉じタグ混入といった壊れ方が、ノーチェックで本番に出ます。

どれも画面表示には影響しないため、人間の目視では検知できません。だからこそ「壊れない書き方」と「壊れたら落とす仕組み」を最初から組み込む必要があります。

— 03

Article JSON-LDをSSGで出す

記事ページはsrc/app/blog/[slug]/page.tsxで、generateStaticParamsによるSSGを基本にしています。Strapiから記事のslugを取得し、ビルド時に静的生成します（下の例は最大100件取得。100件を超える場合はページネーションで全件取得します）。

export async function generateStaticParams() {
  try {
    const result = await getAllBlogPosts(1, 100);
    return result.data.map((post) => ({ slug: post.slug }));
  } catch {
    return []; // Strapi停止時もビルドを止めない
  }
}

catchで空配列を返している点が実運用上のポイントです。ビルド時にCMSが落ちていてもデプロイ自体は通し、個別ページはリクエスト時に解決させます。データ取得はfetchStrapiのnext: { revalidate }に乗っており、記事クエリはrevalidate: 3600（1時間）でISRを効かせています。ページ側にexport const revalidateは置かず、fetch単位でキャッシュ期間を制御する方式です（従来のキャッシュモデル前提。Next.js 16のCache Components有効時はrevalidateの扱いが変わるため別途確認が要ります）。

Article JSON-LDの出力では、descriptionはexcerptにHTMLタグが混入するためタグ除去してプレーンテキスト化し、datePublishedは後述の理由でdisplayDateを最優先にします。authorが未指定のときはコンポーネント側で代表者のPersonノードをデフォルト出力し、画面の著者カードとJSON-LDの著者を一致させます。構造化データと表示内容の不一致は、Googleの構造化データガイドライン上も問題になり得るためです。

— 06

FAQPageは廃止後も残す理由

GoogleのFAQリッチリザルトは、2026-05-07以降Google検索結果に表示されなくなりました。ではFaqPageJsonLdを消すべきかというと、netsujo.jpでは残しています。「SERPのリッチ表示トリガー」としての役割は失われましたが、サイト内の構造化情報として、またAI検索や音声検索での参照を期待して残す判断です（後者の効果はGoogleが保証するものではありません）。

残す以上、運用方針は変えます。回答が冒頭1文で完結し、具体的な数値・条件・法律を含み、実際に検索される質問だけを残します。Yes/Noだけの空虚な回答やキーワード詰め込みのsynthetic questionは削除対象です。

— 08

仕様変更への追随と、維持の自動化

構造化データは「書いた瞬間」より「その後の維持」のほうが難しい、というのが運用してみての実感です。schema.orgやGoogleのリッチリザルト仕様は変わり、CMSのデータも記事が増えるたびに動きます。書いたときは正しかったJSON-LDが、半年後には廃止された@typeを含んでいたり、データ側の変更で必須プロパティが欠けたりします。だからnetsujo.jpでは「正しく書く」だけでなく、「変更のたびに機械が確認し、壊れていたらリリースを止める」側へ運用を寄せています。

リリース前ゲートは人手のレビューに頼りきらない

セクション07で触れた「マージ前のスキーマ検証」は、担当者の目視だけに任せると抜けます。そこで、少なくとも機械で判定できる部分は自動ゲート化しています。check:facts（禁止表現・誤日付・改名前サービス名の静的走査）は、mainへのプッシュとPRのたびに専用ワークフローで自動実行され、違反があればCIが落ちます。tsc --noEmitによる型チェックとlintも各PRのCIで回ります。「構造の妥当性（@id参照・日付形式・廃止タイプ）は人のレビューで、内容の事実整合とコードの型は機械で」という分担です。人が見るべき対象を、機械で潰せない部分だけに絞るのが狙いです。

本番に出たあとのseo:audit:netsujoは、この事前ゲートをすり抜けた構造化データの欠落や想定外のスキーマ種別を、定期的に拾い直す事後の網です。事前ゲートと事後監査を分けているのは、どちらか一方では取りこぼしが出るためです。

廃止・縮小された仕様には静かに追随する（FAQPage・Speakable）

セクション06のとおり、GoogleのFAQリッチリザルトは2026-05-07以降、検索結果に表示されなくなりました。既存ページのFaqPageJsonLdはサイト内の構造情報として残しつつ段階的に見直していますが、これから作る新規記事の方針は一段はっきりさせました。新規記事にはFAQPageのJSON-LDを付けず、FAQは可視のHTMLとして本文に残します。読者が読めるQ&Aとしての価値は変わらないので、失われたSERPトリガーのために構造化データを積み増すことはしない、という整理です。

Speakableも同じ考え方で扱いを見直しています。Speakableはもともとニュース記事の音声読み上げを想定した仕様で、日本語での対応も限定的です。日本語のBtoB記事に付ける実益は薄いと判断し、新規記事には付けない方針にしました。既存の付与分はFAQPageと同様、段階的な見直しの対象です。仕様が廃止・縮小されたときに、以前書いたものを惰性で残し続けないことも、維持の一部だと考えています。

「入れればAIに引用される」とは考えない

最後に前提の確認です。構造化データを入れればAI検索に引用される、という因果関係は確認されていません。JSON-LDはページの内容を機械が読み取りやすくするための手段であって、引用や表示を約束するものではありません。FAQPageやSpeakableを残す・付けないの判断も、「引用が増えるから」ではなく「正しく維持できる範囲か」で決めています。構造化データは、正確な情報を機械可読な形で提供するための土台として扱うのが安全です。

よくあるご質問

関連記事