OGP画像が反映されない原因|Facebookシェアのキャッシュと取得エラーを直す方法

新しいキャンペーンページを公開して、Facebookにリンクを貼ったのに、プレビューに出てくるのは古いアイキャッチや真っ白な枠だけ。画像を差し替えて何度投稿し直しても変わらず、Web担当に聞いても「ページ側は直したはず」と返ってくる。SNS運用の現場では、こうしたリンクプレビューの不具合が告知のタイミングに限って起こりがちです。
OGP画像が反映されない原因は、突き詰めると「Facebookのクローラーが画像を取りに行けていない」か「取りに行けたが古い情報がキャッシュに残っている」かのどちらかです。ところが症状だけ見ると両者は似ているため、キャッシュを消せば直ると思い込んで何度も再取得を押し、時間だけが過ぎていくケースが少なくありません。
この記事では、投稿文や画像デザインの話ではなく、URLを共有したときのプレビュー取得不良に絞って、HTMLの出力、og:imageの画像URL、リダイレクト、クローラーへの応答、Sharing Debuggerによる再取得の順に切り分ける方法を解説します。運用担当とWeb担当が同じ画面を見ながら原因を特定できるよう、確認項目と分担も整理しました。
この記事の要点
- OGP画像の不具合は「取得失敗」と「古いキャッシュ」の2系統に分けて考えると早く直る
- 最初にSharing Debuggerでレスポンスと警告を見て、どちらの系統かを判定する
- Meta公式の基準は最小200×200px・8MB以下・推奨1200×630px以上・絶対URL指定
- 画像はURL単位でキャッシュされるため、差し替え時は新しいファイル名で上げ直す
- 共有済みの投稿は自動で更新されないので、投稿側の更新操作が別途必要になる
OGP画像が反映されない原因は取得失敗と古いキャッシュの2系統
OGP画像が反映されない原因は、クローラーが画像やタグを取得できない「取得失敗」と、過去に取得した情報が残っている「古いキャッシュ」の2系統に分けられます。どちらに当たるかで打ち手がまったく違うため、修正作業に入る前の切り分けが最も重要です。
OGP(Open Graph Protocol)とは、Webページのタイトル・説明文・画像などを、SNSがリンクプレビューとして表示できるようにHTMLのhead内へ記述するメタデータの仕様です。Facebookの場合、URLが共有されるとクローラーがページを読みに行き、og:titleやog:imageの値を取得してプレビューを組み立てます。つまりプレビューに表示されるのは、ブラウザで見えている画面ではなく、クローラーが取得した時点のHTMLとメタデータです。
この前提に立つと、症状の読み方が変わります。ブラウザでは新しい画像が見えているのにプレビューが古いなら、ページは正しくてもFacebook側の記録が古いままである可能性が高いと言えます。一方で、プレビューに画像が一切出ない、白い枠になる、無関係なロゴが出るといった場合は、そもそもクローラーが正しい画像を受け取れていない可能性を先に疑います。
正常・取得失敗・古いキャッシュの見分け方
原因の見当をつけるには、症状を三つの状態に当てはめるのが早道です。手元で確かめたい場合は、正しく設定したページ、画像URLをわざと存在しないパスにしたページ、公開後に画像だけ差し替えたページの三つをテスト用に用意し、Sharing Debuggerで見比べると違いが体感的に分かります。
見分けるときの軸は、レスポンスコード、警告の有無、表示された画像が現在のog:imageと一致しているかの三点です。下の表は、Meta公式の開発者向け資料に書かれている挙動をもとに、状態ごとの典型的な出方を整理したものです。実際の表示はページの構成やサーバー設定によって変わるため、あくまで判定の目安として使ってください。

| 状態 | Sharing Debuggerでの出方 | 主な原因 | 直す場所 |
|---|---|---|---|
| 正常 | レスポンス200・警告なし・現在の画像が表示 | なし | 対応不要 |
| 取得失敗 | 警告が出る/画像が白い枠や別画像になる | タグ未出力・相対URL・画像404・アクセス遮断 | HTMLとサーバー設定 |
| 古いキャッシュ | 警告なしだが旧画像が表示される | 以前の取得結果が残っている・同じ画像URLで上書き | 再スクレイピング・画像URL変更 |
| 共有済み投稿だけ古い | デバッガーは最新だが投稿のプレビューは旧画像 | 既存投稿は自動更新されない | 投稿側の更新操作 |
この記事は技術的なプレビュー不具合の修正に絞っています。オウンドメディアの記事をSNS投稿へどう組み替えて届けるかという編集面の進め方は、以下の記事で解説しています。
HTMLの出力を確認するとタグの不備が見つかる
最初に確かめるべきは、og:imageがクローラーの受け取るHTMLに正しく出力されているかどうかです。CMSの管理画面で画像を設定していても、実際のHTMLに反映されていなければ、Facebookは何も読み取れません。
head内に絶対URLで出ているか
確認方法はシンプルで、対象ページを開いてブラウザの「ページのソースを表示」を使い、「og:image」で検索します。ここで見るのは、タグがhead要素の中にあるか、content属性の値が「https://」から始まる絶対URLになっているかの二点です。Meta公式のLink Sharing FAQでは、og:urlやog:imageに相対URLは使えず絶対URLで指定する必要があると明記されています。
開発環境やステージングで作ったページを本番に移した際、og:imageの値だけが検証用ドメインのまま残っていることもあります。ソース上の画像URLを丸ごとコピーし、ドメインが本番のものか、httpとhttpsが混在していないかまで目で確かめてください。フレームワークによっては、基準となるドメインの設定次第で画像URLが別ドメインに解決されるため、Web担当には環境ごとの設定値も確認してもらうと確実です。
重複タグとプラグインの競合
WordPressなどのCMSでは、テーマとSEOプラグインがそれぞれOGPタグを出力し、og:imageが2つ以上並ぶことがあります。この状態だと、意図した画像ではない方がプレビューに採用されることがあり、「設定した画像が出ない」という相談の典型パターンになります。ソース内でog:imageが何回出てくるかを数えるだけで、重複の有無はすぐ分かります。
重複が見つかったら、どちらか一方の出力機能を止めます。キャッシュ系や最適化系のプラグインが古いHTMLを配信し続けている場合もあるため、修正後はサイト側のキャッシュも削除してからソースを見直すことが大切です。
JavaScriptで後から挿入したタグに注意
- ブラウザの開発者ツールで見えるタグと、ページのソースに書かれたタグは別物
- 表示後にスクリプトで追加したOGPタグは、クローラーが読めない前提で考える
- 確認は必ず「ページのソースを表示」で行い、サーバーが最初に返すHTMLを見る
特にSPA構成のサイトやノーコードツールで作ったページは、画面上の表示とサーバーが返すHTMLが一致しないことがあります。ソースにタグが見当たらない場合は、サーバー側で出力する設定に切り替えられるかをWeb担当と相談してください。社内に相談できる担当者がいない場合は、SNS運用とリンク先の設定をまとめて相談することもできます。
og:imageの画像URLと画像仕様を公式基準で確かめる
タグが正しく出ていても、指定した画像URLそのものが開けなければプレビューは失敗します。次に確かめるのは、画像URL単体での応答と、Metaが定める画像の仕様です。
画像URL単体で開けるか
ソースからコピーしたog:imageのURLを、ログインしていないブラウザのシークレットウィンドウに直接貼り付けて開きます。画像が表示されれば第一関門は通過です。404エラーになる、ログイン画面に飛ばされる、ダウンロードに異常に時間がかかるといった場合は、クローラーも同じように失敗していると考えてください。
Meta公式のFAQでは、プレビューが白い枠になる理由として、元画像が利用できない、8MBを超えている、一時的な取得エラーの三つを挙げています。さらに画像URLはクローラーがアクセスできること、遅延は数秒未満が望ましいことも書かれています。画像を外部のストレージや画像配信サービスに置いている場合は、そちらの公開設定や署名付きURLの有効期限も確認対象に入れましょう。
サイズと容量はMetaの公式基準に合わせる
画像の仕様は、Meta for Developersの「Images in Link Shares」で確認できます。2026年11月時点の記載では、最小寸法は200×200ピクセル、ファイルサイズは8MB以下で、高解像度端末で見栄えよく表示するには1200×630ピクセル以上が推奨されています。
大きな横長プレビューで表示するには600×315ピクセル以上が必要で、それ未満の画像は小さな正方形のサムネイルとして扱われます。比率は1.91:1に近づけると切り抜かれずに表示されやすく、顔が写っている画像は顔を中心にトリミングされる場合があると公式FAQに記載されています。
| 項目 | Meta公式の基準(2026年11月時点) | 満たさない場合 |
|---|---|---|
| 最小寸法 | 200×200px | 画像として採用されない |
| ファイルサイズ | 8MB以下 | 白い枠になることがある |
| 大きな表示の条件 | 600×315px以上 | 小さな正方形で表示 |
| 推奨サイズ | 1200×630px以上 | 高解像度端末で粗く見える |
| アスペクト比 | 1.91:1に近づける | 上下左右が切り抜かれる |
| 寸法タグ | og:image:width/heightを指定 | 初回共有で画像が出ないことがある |
表の最後にある寸法タグは見落とされがちな項目です。Facebookは画像を非同期で処理するため、初めて共有されたURLではクローラーが画像を処理し終えるまでプレビューに画像が出ないことがあります。og:image:widthとog:image:heightで寸法を伝えておくと、ダウンロードを待たずに表示できると公式資料に書かれています。
リダイレクトとクローラーへの応答で取得が止まるケース
HTMLも画像も正しいのに取得に失敗する場合は、サーバーがFacebookのクローラーに対して正常に応答していない可能性があります。ここはWeb担当の領域ですが、運用担当も確認ポイントを知っておくと相談がスムーズになります。
リダイレクトとog:urlの食い違い
http版からhttps版へ、末尾スラッシュなしからありへ、といったリダイレクトが何段も挟まると、どのURLの情報が採用されたのかが分かりにくくなります。Metaの開発者資料では、og:urlはいいねやシェアが集計される正規URLとして扱われ、セッション変数やユーザー識別のパラメータを含まない形で指定するよう求めています。
そのため、共有したURLとog:urlが指すURLが別ページになっていると、意図しないページのタイトルや画像がプレビューに出ることがあります。UTMパラメータ付きのURLを共有する場合も、og:urlはパラメータなしの正規URLにしておくのが基本です。テンプレートの設定ミスで全ページのog:urlがトップページを指していた、という事故も起こり得るため、ソース確認の際に一緒に見ておきましょう。
アクセス制限と応答の条件
Facebookのクローラーは「facebookexternalhit/1.1」を含むUser-Agentでアクセスしてきます。WAFやセキュリティプラグイン、Basic認証、会員限定の設定がこのアクセスを遮断していると、ブラウザでは問題なく見えるのにプレビューだけが失敗する状態になります。公開前の検証環境に認証をかけたまま共有テストをして、うまくいかないと悩むのもよくある流れです。
Meta公式の「The Facebook Crawler」には、Open Graphのプロパティはページの先頭1MB以内に置く必要があること、サーバーはgzipとdeflateに対応すること、robots.txtの内容は最大24時間キャッシュされることなどが記載されています。head内に大きなインラインスクリプトやスタイルを大量に書いているページは、OGPタグを先頭に近い位置へ移すと安全です。
サーバー移転・ドメイン変更の直後は要注意
- Meta公式FAQでは、URLやサーバーを変更した際にAAAAレコードが正しく更新されていないと、レスポンスコード0が返ることがあると説明されている
- URLを変えるとそれまでのシェア数やいいね数は新しいURLへ引き継がれて見えない
- 移転時はDNS設定とリダイレクト設計をWeb担当と事前にすり合わせる
共有用のURLにパラメータを付けて流入を計測している場合は、短縮URLやリンク集との整合も崩れやすくなります。計測用URLの管理方法は、以下の記事を参考にしてください。
Sharing Debuggerの使い方と結果の読み方
Sharing Debuggerは、Facebookのクローラーが対象URLをどう読み取ったかを確認し、必要に応じて情報を再取得させるためのMeta公式ツールです。切り分けの出発点であると同時に、修正後の確認にも使うため、運用担当とWeb担当の両方が使い方を押さえておくべきツールです。
URLを入力して再スクレイピングする
使い方は、Facebookにログインした状態でSharing Debuggerを開き、確認したいURLを入力してデバッグを実行するだけです。結果画面にはクローラーが取得したメタタグ、警告やエラー、リンクプレビューの見え方が表示されます。表示された内容が古いときは「もう一度スクレイピング」を押すと、その時点のページを取り直します。
ただし、再スクレイピングで直るのは「古いキャッシュ」系統の不具合だけです。取得失敗の原因がHTMLやサーバー側に残っている限り、何度押しても結果は変わりません。2〜3回押しても変わらなければ、キャッシュではなく取得側の問題と判断して、前の章の確認項目に戻るのが時間を無駄にしないコツです。
警告とレスポンスを読み解く
結果画面で最初に見るのはレスポンスコードです。200以外であれば、サーバーがクローラーに正常なページを返していません。404ならURLの誤り、403ならアクセス制限、0なら名前解決や接続の問題というように、数字がそのまま調べる場所を教えてくれます。
次に、警告の中にog:imageに関するものがないかを確認します。「プロパティを明示的に指定すべき」という趣旨の警告は、タグが出力されていない、または値が読み取れていないことを示しています。画像を処理できないという警告が出る場合は、画像ファイルの形式や破損、容量の超過を疑います。警告の文言はそのままWeb担当へ共有すると、伝言の過程で情報が欠けるのを防げます。
共有済みの投稿は別途更新が必要
Sharing Debuggerで最新の画像が取れても、すでに投稿済みのプレビューは自動では切り替わりません。Meta公式FAQでは、og:titleやog:imageなどの変更は今後の共有にのみ反映されると説明されており、既存の投稿を直すには投稿側で共有されたコンテンツを更新する操作が必要です。
また、og:titleは一定数のアクションが付くと固定され、変更できなくなると公式FAQに記載があります。告知文のタイトルを後から大きく変える運用は避け、公開前に確定させておくのが安全です。
画像を差し替えるときは新しいURLで上げ直す
公開後にOGP画像を差し替えるときは、同じファイル名で上書きせず、新しいファイル名の画像をアップロードしてog:imageを書き換えるのが正しい手順です。Meta公式資料には、画像は画像URL単位でキャッシュされ、URLが変わらない限り更新されないと明記されています。
同じURLのまま中身だけ差し替えると、ページを再スクレイピングしても画像のキャッシュが残り、古いアイキャッチが出続けることがあります。「デバッガーで何度取り直しても画像だけ古い」という相談の多くは、この上書き運用が原因です。ファイル名の末尾に日付や版番号を付けるルールにしておけば、差し替えのたびに自然と新しいURLになります。
もう一つの注意点は、古い画像ファイルをサーバーから削除しないことです。過去に共有された投稿は古い画像URLを参照しているため、削除するとそれらの投稿のプレビューが白い枠になります。容量整理のつもりでメディアライブラリを掃除した結果、過去の投稿がまとめて崩れるのは避けたいところです。
告知の初動を確実にしたい場合は、公開直後に自分でSharing Debuggerを実行してキャッシュを作っておく方法が有効です。公式資料でも、デバッガーやGraph APIで事前にスクレイピングし、寸法タグを指定しておくと、最初の共有から画像が表示されると説明されています。広告出稿やプレスリリースと同時に拡散が始まるページほど、この事前取得の効果は大きくなります。
運用担当とWeb担当の分担を決めておく
リンクプレビューの不具合を早く直すには、どこまでを運用担当が確認し、どこからをWeb担当に渡すかを事前に決めておくことが欠かせません。原因の大半はHTMLやサーバーにありますが、最初に気づくのはSNSに投稿する運用担当だからです。
運用担当は、Sharing Debuggerの結果画面と、ブラウザで開いた画像URLの状態までを確認し、レスポンスコードと警告文をそのまま伝える役割を担います。Web担当は受け取った情報をもとに、タグの出力、画像の配置、リダイレクト、アクセス制限を順に直します。この線引きがあるだけで、「直したはず」「まだ出ない」の往復を減らせます。
| 確認項目 | 担当 | 使うもの |
|---|---|---|
| デバッガーのレスポンスと警告 | 運用担当 | Sharing Debugger |
| 画像URL単体の表示 | 運用担当 | シークレットウィンドウ |
| og:imageの出力と重複 | Web担当 | ページのソース |
| リダイレクトとog:url | Web担当 | ソースとサーバー設定 |
| WAF・認証・robots.txt | Web担当 | サーバー・セキュリティ設定 |
| 共有済み投稿の更新 | 運用担当 | Facebookの投稿画面 |
社内にWeb担当がいない、あるいは制作会社とのやり取りに時間がかかる場合は、SNS運用とサイト側の修正をまとめて相談できる外部パートナーを検討するのも一つの方法です。運用代行に依頼したときの費用感は、以下の記事で詳しく解説しています。
公開前チェックで再発を防ぐ
同じ不具合を繰り返さないためには、ページ公開とSNS告知の間に短いチェック工程を挟むのが最も確実です。原因の多くは公開前に見つけられるもので、確認にかかる時間は数分程度に収まります。
チェックの順番は、ソースでog:imageを確認し、画像URLを単体で開き、Sharing Debuggerで事前取得してから投稿する、という流れが基本です。この三つを公開手順書に組み込んでおくと、担当者が替わっても品質が保てます。告知日が決まっているキャンペーンでは、公開から投稿までに確認の時間を最低でも30分は確保しておくと、問題が見つかっても慌てずに直せます。
あわせて、画像の差し替え時は新しいファイル名にする、古い画像は消さない、og:titleは公開前に確定させる、という三つのルールを社内で共有しておきましょう。ルールを文書にしておけば、制作会社や新任担当への引き継ぎでも同じ説明を繰り返さずに済みます。
リンクプレビューの管理まで含めて運用を任せられる会社を探している場合は、ハーマンドットへのご相談も受け付けています。外部パートナーの比較ポイントは、以下の記事で整理しています。
まとめ:OGP画像の不具合は切り分けの順番で決まる
OGP画像が反映されないときは、闇雲に再スクレイピングを繰り返すのではなく、取得失敗と古いキャッシュのどちらかを先に判定し、HTML、画像URL、サーバー応答、キャッシュの順に確かめることが解決への近道です。
- 最初にデバッガーで系統を判定。レスポンスコードと警告を見て、取得失敗か古いキャッシュかを決めてから手を動かす。
- 取得失敗はHTMLとサーバーを直す。絶対URL・重複タグ・画像の404・アクセス制限を順に確認する。
- 差し替えは新しい画像URLで。古い画像は消さず、共有済み投稿は投稿側で更新する。
まずは無料でSNSアカウント診断を
リンクプレビューの崩れは、告知のクリック率や問い合わせ数に直結する見落としやすい課題です。ハーマンドットでは、SNSアカウントの運用状況に加えて、投稿から誘導するページのOGP設定やリンク先の導線まで含めて確認し、運用担当とWeb担当のどちらが何を直せばよいかを整理してお伝えします。
「告知のたびにプレビューが崩れる」「制作会社とのやり取りに時間がかかる」といったお悩みがあれば、お気軽にご相談ください。初回相談は完全無料・所要時間30分・オンライン対応可能です。



