構造化データ
Web ページの内容を検索エンジンが機械的に理解できる形式で記述したマークアップ。著者・公開日・パンくず・FAQ・商品情報・レビュー・組織情報など、人間が読む HTML とは別に「機械可読のメタ情報」として埋め込む。JSON-LD / Microdata / RDFa の 3 形式があるが、Google は JSON-LD を推奨。
本書のスタンス(Lesson 6-3)は「Schema.org([[schema-org]])が共通語彙の標準で、Google はリッチリザルト([[rich-result]])(検索結果の特別表示)で活用」。誤情報の構造化はマイナス評価。実装は業者領域だが、担当者は「何を構造化するか」の方針を握る。事業 KGI に効くもの(FAQ・事例・商品レビュー・パンくず)を優先する。
判断のポイント:Article(記事)・BreadcrumbList(パンくず)・FAQPage(FAQ)・Product(商品)・Organization(組織)・Review(レビュー)・LocalBusiness(店舗) から、自社サイトに該当する型を選ぶ。リッチリザルトテスト・Search Console の「拡張」レポートで実装状況と効果を継続監視。AI 検索([[ai-overview]] / [[searchgpt]])時代は、構造化データが「機械への引用しやすさ」に直結するため重要度が増している。
落とし穴は、本文と構造化データの内容が乖離(誤情報)で Google ペナルティ、JSON-LD の構文エラーで全構造化データが無効、不要な型(機能していない FAQ など)を入れて Search Console エラー、CMS テーマ自動生成の構造化データが古いまま、構造化データを入れて満足し本文の質を上げない、リッチリザルトテストを定期的に通さず古い実装で放置。
言葉をよく利用する人
- コーダー / フロントエンドエンジニア
- SEO 担当者
- Web 担当者(発注側)
- ディレクター
- マーケター
会話上での使用例
リニューアル時に構造化データの方針を業者と擦り合わせる場面
-
Web 担当者
構造化データ、何を入れますか
-
業者ディレクター
基本セット(Article / BreadcrumbList / Organization)+ 事例ページ用 FAQPage で。リッチリザルトテストの結果証跡を提出します。Search Console 拡張レポートでの継続監視も体制化を
Search Console で構造化データエラーが多発した場面
-
SEO 担当者
Search Console、FAQ の構造化データエラーが 50 件
-
Web 担当者
CMS テーマ自動生成の JSON-LD が古い仕様の可能性。リッチリザルトテストで 1 件確認 → 業者に原因 + 修正パッチを依頼。エラーゼロまで戻して、月次でエラー件数を Looker Studio に組み込み