Structured DataとOpen Graph、検索価格と共有画像はどこで修正すればよいですか？
Structured Dataは、検索エンジンがページの商品・記事・組織情報を理解できるように表現するもので、Open GraphはSNSやメッセンジャーが共有カードのタイトル・説明・画像を読み取るために使用します。エラーが表示される画面から原因を分けて確認する必要があります。
3行要約
Structured Dataは、検索エンジンが商品・記事などのページの意味を読み取るための形式であり、Open GraphはSNS・メッセンジャーの共有カード情報を決めます。
検索結果の価格が違うなら構造化データと本文を、共有画像が古いならogタグとプラットフォームのキャッシュをまず確認すべきです。
既存サイトを変更せず、問題のあるURL 1つの公開HTMLと元データを突き合わせれば、2つの設定の担当範囲をすぐに切り分けられます。
Structured DataとOpen Graphの違い
Google検索結果には先月の価格が表示されるのに、カカオトークの共有カードには以前の商品画像が出るなら、同じタグ1つで直すことはできません。検索エンジンが商品情報を読み取る構造化データと、メッセンジャーがリンクのプレビューを作成するOpen Graphでは用途が異なるためです。「メタデータのエラー」とひとまとめにせず、問題が表示される画面から特定しなければなりません。
比較基準 | Structured Data | Open Graph |
|---|---|---|
主な利用者 | 検索エンジン | SNS・メッセンジャー |
代表情報 | 商品・記事・組織・イベント | 共有タイトル・説明・画像 |
主な検査 | 本文の一致とリッチ結果テスト | 公開タグ・画像レスポンス・共有キャッシュ |
共通原則 | 画面と同じソースデータを使用 | 画面と同じソースデータを使用 |
Structured DataとOpen Graphを名前だけで選びません。実際の業務1件で公開本文とcanonicalを並べて書いてみると、どの段階に先に手を入れるべきかが見えてきます。担当者と再検査日まで同じ記録に残してこそ、次の修正が推測に流れません。
検索価格と記事情報はどこで読むのでしょうか？
構造化データは、ページに何があり、それぞれの項目がどのような属性を持つかを標準形式で表示します。Google検索では主にschema.orgの語彙を使用し、JSON-LD、Microdata、RDFaをサポートしています。商品名・価格・通貨・在庫状態をProductとして、記事のタイトル・著者・日付をArticleで表現するようなものです。
適切なマークアップは、一部のリッチリザルトの表示対象となるのに役立ちます。検証ツールに合格したからといって、実際にリッチリザルトが表示されることを保証するものではありません。ページ上にないレビューや別の価格を、構造化データにだけ記載することも認められていません。検索結果の情報が誤っている場合は、まず公開本文とJSON-LDの値が一致しているか、そのタイプに必要な・推奨のプロパティが正しいかを確認します。
共有画像が古くなっていたら、どこを見ればよいでしょうか？
Open Graph Protocolは、ウェブページをソーシャルグラフのオブジェクトとして表現するためのメタデータ規約です。og:title、og:type、og:image,og:urlなどが基本属性です。これらをサポートするSNSやメッセンジャーは、リンクを貼ったときのタイトル、画像、説明の構成にこれらの値を参照できます。
プラットフォームごとに、タグがない場合に値を選ぶ方式とキャッシュ更新のタイミングが異なります。HTMLを修正しても、以前のプレビューがしばらく残ることがあり、画像の規格やアクセス権限のために新しい画像が読み込まれないこともあります。Open Graphタグを入れたあとは、各サービスの共有デバッガーや再取得機能で結果を確認します。
エラーが見える場所 | まず読むコード | 続けて見るもの |
|---|---|---|
検索結果の商品価格・在庫 | 構造化データ | 公開本文、Googleガイドライン、リッチリザルトテスト |
SNS・メッセンジャーのタイトル・画像 | Open Graph | 画像レスポンス、プラットフォームキャッシュ、共有デバッガー |
一般検索のタイトル・説明 | HTML | 検索エンジンによるタイトル書き換えの可能性 |
代表URLがそれぞれ異なる | canonical と | 内部リンク、リダイレクト、追跡基準 |
この2つの値はどのソースから作成すべきでしょうか？
商品画面はコマースデータベースから、JSON-LD は SEO プラグインから、Open Graph はテーマから生成される場合があります。運営者が商品名と価格を変更しても、3つの出力が同時に更新されなければ、検索結果と共有カードに異なる情報が表示されます。価格・通貨・在庫のように頻繁に変わる値は、できるだけ同じデータソースから取得する必要があります。
canonicalとog:urlは、同じ代表URLを指すように管理するのが安全です。両者が分かれると、共有されるURLと検索上の代表URLが異なり、キャンペーントラッキングや成果集計が複雑になります。1つのページテンプレートを修正した後、商品・カテゴリ・記事など他のタイプの出力もサンプルで確認します。
Googleは、AI検索機能のために新しいschema.orgマークアップや別のAIファイルを追加する必要はないと案内しています。構造化データは公開ページの意味を説明する従来のSEO手段であり、Open Graphはリンクが共有されたときの見え方を担います。どちらも生成AIの回答での言及や出典リンクを約束するものではありません。
GEOの確認では、まず公開本文と構造化データが同じ事実を述べているかを見ます。AI回答に古い製品情報が出る場合は、最新の公式ページの本文・JSON-LD・レスポンスステータス・内部リンクを確認します。Open GraphはAI回答への入力シグナルだと断定せず、同じ情報が共有カードでもずれていないかを別途確認します。
エラー画面に応じて、担当をどう分けますか？
検索結果に問題があるなら、実際の表示URL、検索語、構造化データテスト結果を残します。共有カードに問題があるなら、どのメッセンジャーでいつ共有したかとプレビュー画面を記録します。こうして初めて、コンテンツ担当者が商品情報を修正するのか、開発者がテンプレートを直すのか、プラットフォームキャッシュを更新するのかをすぐに切り分けられます。
2つの画面がどちらも間違っていても、それぞれを検証します。本文を修正した1回のデプロイで、検索の再処理とSNSキャッシュの更新まで同時に完了すると考えてはいけません。
Structured DataとOpen Graphの併用運用における実際の判断
判断会議では、Structured DataとOpen Graphの機能一覧よりも、検索結果・共有カードの項目がどこで途切れているかを見ます。公開HTML、リンク、元データが異なる値を出力していれば、検索とAI回答も別の情報を拾う可能性があります。元データ項目が変わったURLをサンプルとして、入力から公開結果まで追跡します。
Structured DataとOpen Graphの公開本文項目は、公開直後とその後の観測時点を分けて記録します。当日は公開レスポンスを確認し、検索露出・クリックとAIでの言及・引用は同じ質問セットで再測定します。結果が実際の顧客行動につながらない場合は、作業範囲を絞ります。
参考資料
検索結果の構成をさらに確認するには
資料確認日: 2026年8月9日。SNS・メッセンジャーのOpen Graph解釈とキャッシュポリシーはサービスごとに異なるため、実際の共有結果を改めて確認する必要があります。
既存サイトへの適用範囲
問題が見られる商品・記事URLと実際の検索または共有画面をお問い合わせに記載いただければ、この運用方針に基づいて公開本文・構造化データ・Open Graph・canonicalを照合し、SEO・GEOの不一致における修正箇所を診断します。
Structured DataとOpen Graphの比較後のSearch OS運用
Search OS適用の出発点はサイトの入れ替えではありません。Structured DataとOpen Graphの比較で確認する原本データ、公開本文項目を現在のWebサイト上で測定し、コンテンツ・技術・外部情報のうち詰まっている部分だけを手直しします。
内部成果集計基準では、Search OSを適用した顧客企業はSEOとAI検索露出が平均88%以上増加しました。その後は、Structured DataとOpen Graphの比較に使用した検索とAI回答を同じ周期で再読します。改善した状態を基準線とし、逸脱が生じたURLを優先して修正し、最良の露出状態が継続するよう管理します。