Facebook Open Graph キャッシュの強制更新
Facebook は主要プラットフォームの中で唯一、プログラム的にキャッシュを更新するリクエストを行う方法を提供しているため、Facebook Open Graph のキャッシュを強制更新することができます。単一のリンクに対しては、Sharing Debugger の Scrape Again ボタンを使用するか、Graph API の scrape エンドポイントをアプリアクセストークンと共に呼び出します。WhatsApp、LinkedIn、X については強制更新する方法はありません。これらのプラットフォームは、いかなる対象者に対してもそのような API を公開していません。
誰もが躓くポイント
Meta はリンクプレビューをページ URL をキーとしてキャッシュし、画像自体のコピーも保存します。Meta は og:image が別の場所を指すようになったことを認識するためにページを再読み込みしません。
そのため、多くの人が試すこのワークフローは失敗します:
カバーを変更する →
og:imageURL が新しくなる → Facebook がそれを拾ってくれると期待する → しかし、そうはならない。
新しい画像 URL は画像 CDN のキャッシュを無効化しますが、Meta のページキーベースのキャッシュには何も影響しません。Facebook のキャッシュを更新するには、Meta に対して「ページが変更されたこと」を伝える必要があります。
| キャッシュ | キーとなるもの | 削除方法 |
|---|---|---|
| ページキャッシュ / CDN | ページ URL | パージ(purging) |
| Meta のリンクプレビューキャッシュ | ページ URL | スクレイプエンドポイントまたは Sharing Debugger |
| Meta が保持する画像のコピー | 画像 URL | 新しい画像 URL |
| 画像 CDN | 画像 URL | 新しい画像 URL |
オプション 1 — シェアリングデバッガー(1ページ、手動)
developers.facebook.com/tools/debug を開き、ページ URL を貼り付けて Scrape Again を押します。Meta はページを再フェッチし、キャッシュされたプレビューを再構築します。
これはあなたが持つ最高の無料バリデーターでもあります。なぜなら、それはあなたがそこにあってほしいと願っていたものではなく、Meta が 実際に 発見したものを報告するからです:欠落しているか重複している og:image、到達不可能な画像、サポートされていないフォーマット。これが行わないことは2つあります:WhatsApp には触れることができません(別のキャッシュで、受信側のアプリ内)、カタログツールではないということです。これは1 URL ずつ、レート制限があり、人間が操作します。
オプション 2 — Graph API(プラグインが呼び出すもの)
FastOG が使用するプログラムmaticな同等機能は、scrape=true を用いて Graph API に対して POST を行う処理です。
curl -X POST \
"https://graph.facebook.com/v21.0/?id=$(python3 -c 'import urllib.parse,sys;print(urllib.parse.quote(sys.argv[1],safe=""))' 'https://your-store.com/product/example')&scrape=true&access_token=${APP_ID}|${APP_SECRET}"
重要な注意点として以下の 4 点があります。
idは画像の URL ではなく、ページ(プロダクトページ)の URL です。 Meta はページ単位でキャッシュを管理しているため、画像アドレスに対して ping を打っても何も更新されません。- トークンが必要です。 Meta は 2017 年 10 月以降、このエンドポイントに対してトークンの必須化を行っています。
{app_id}|{app_secret}形式のアプリアクセストークンで十分であり、ユーザーのログインは不要です。これにより、バックグラウンドジョブからの呼び出しが可能になります。 - Graph API のバージョンは更新されます。 FastOG はテスト済みの Graph API バージョンを固定しています。ご自身のコードでバージョンを固定する前に、Meta の現在のドキュメントと変更履歴を確認してください。
- ベストエフォートとして扱ってください。 Meta はスクレイピング呼び出しに対してレートリミットを設けており、拒否された場合でも、Facebook が独自のスケジュールで更新するだけであり、ページ上のタグはすでに正しい状態です。
レートリミットがかかるため、大規模なカタログを保存するたびにインラインで呼び出さないでください。キューに積んで処理し、URL ごとに重複排除を行ってください。これにより、変更のない同じプロダクトを繰り返し保存した場合でも、レートリミットを無駄に使わずに済みます。
オプション 3 — 自動で処理するプラグイン
「Open Graph キャッシュの更新」を謳うプラグインは大きく 2 つのグループに分かれ、Facebook の問題を解決できるのはそのうちの 1 つだけです。
| 仕組み | 削除される対象 | 古い Facebook プレビューを修正できるか? |
|---|---|---|
画像 URL に変更されるクエリ文字列を付加する (?v=timestamp) |
画像 CDN | いいえ — Meta のキャッシュはページをキーとしています |
| ページ URL に対してスクレイピングエンドポイントを呼び出す | Meta のプレビューキャッシュ | はい |
インストールする前に、どちらのタイプなのかを確認してください。タイムスタンプパラメータは、古い 画像 に対する本当の修正ですが、古い Facebook カード に対する修正ではありません。
FastOG for WooCommerce は後者の手法を採用しており、設定は不要です。 このプラグインは WooCommerce のネイティブな製品ウェブフックを登録するため、製品を保存すると、その製品のパーマリンクに対して Meta による再スクレイピングがトリガーされます。これはキューに入れられ、短い時間枠内で重複が排除され、設計上はベストエフォートであるため、拒否されても保存処理は失敗しません。これは製品ページ (product.created / product.updated) に適用されますが、カテゴリやブログの編集には適用されません。
画像側の処理は別個に行われ、競合他社とは異なる方法で処理されます。FastOG のカバー URL にはそれを生成した値が含まれているため、価格や写真を編集すると、新しいカバー URL が生成されます。Meta は、存在しなくなったアドレスの画像を再配信することはできません。
Facebook では不十分な場合
| プラットフォーム | 強制更新可能か? | 実際に行われる処理 |
|---|---|---|
可能 — デバッガーまたは scrape=true |
再スクレイピングを要求;伝播時間は可変 | |
| 不可 | プレビューは受信側のアプリにキャッシュされます;API は存在しません | |
| ドキュメント化されたプログラムmatic な API なし | 独自のスケジュールで再読み込みします;公開されたタイミングの保証はありません | |
| X / Twitter | ドキュメント化されたプログラムmatic な API なし | 独自のスケジュールで再読み込みします;公開されたタイミングの保証はありません |
| Slack, Discord | 不可 | 短期間のキャッシュで、数分から数時間で自動的にクリアされます |
WhatsApp でプレビューが古い場合、解決策は Facebook のツールを使うことではなく、ストア側を正しく設定する ことです。そうすれば、次の読み込み時に正しい情報が取得されます。
スクレイピング成功後も古い画像が表示される場合
以下のリストを順番に確認してください。
- ページはまだ古いタグを配信していますか?
curl -s https://your-store.com/product/example | grep -i 'og:image'— 古くなったog:imageを含むキャッシュされた HTML ページは、スクレイピングを完全に無効にします。ページキャッシュをパージしてください。 - ページに複数の
og:imageが出力されていませんか? 2つのプラグインがそれぞれ1つずつ出力する場合、クローラーは最初に読み込んだものを使用します。数を数えて確認してください。 - 画像はアクセス可能で、ブロックされていませんか?
curl -I <image-url>は画像Content-Typeを伴って200を返す必要があります。ソーシャルクローラーはrobots.txtを尊重するため、Disallow:パス上の画像は、壊れたファイルのように見える方法で失敗します — そしてcurlはそれを再現できません。なぜならcurlはrobots.txtを無視するためです。 - 画像URLは実際に変更されましたか? 変更されていない場合、コンテンツも変更されていません — 価格や写真の編集が、カードの元データとして使用されているソースに反映されたか確認してください。
- デバッガーを再度確認してください。 ここで新しい画像が報告されているにもかかわらず、Facebook でまだ古いカードが表示されている場合、それはあなたのタグの問題ではなく、Facebook 自身の伝播(プロパゲーション)の問題です。
よくある質問(FAQ)
Facebook の Open Graph キャッシュをクリアする公式 API はありますか?
FastOG はスクレイピングエンドポイント(POST https://graph.facebook.com/{version}/?id={page-url}&scrape=true&access_token={token})を使用します。Meta は「Sharing Debugger」およびプログラムmaticなクロールフローについて文書化していますが、正確なエンドポイントの形状や Graph API のバージョンは変更される可能性があるため、実装する前に Meta の最新ドキュメントで確認してください。
Sharing Debugger にはアプリやトークンが必要ですか?
いいえ。これはパブリックツールであり、あらゆる公開 URL で動作します。ただし、スケジュール実行やカタログ全体の処理を行うことはできません。
再スクレイピングで FastOG のレンダリングコストがかかりますか?
通常はかかりません。カバー URL はコンテンツに依存して生成されるため、コンテンツが変更されていない限り URL も変更されず、フェッチはキャッシュヒットとなります(レンダリングコストは発生しません)。価格が変更された場合、URL も変更されます——これが 1 つの新しいレンダリングであり、あなたが望んでいたレンダリングです。
Facebook の再スクレイピングで WhatsApp のプレビューも修正されますか?
いいえ。これらは別々のキャッシュです。Facebook のデバッガーは バリデーター として有用です——WhatsApp が行うのと同じ方法でページを取得し、見つかった内容を報告しますが、WhatsApp のキャッシュを更新することはできません。
Facebook は、ping を送信しない場合、プレビューをどのくらい保持しますか?
Meta によると、標準的な再スクレイピング期間は約 24 時間ですが、正確な伝播時間は変動する可能性があります。そのため、デバッガーやプログラムmaticなクロールパスが存在します。
カタログインポート後、すべての製品に ping を送信する必要がありますか?
それがキューの役割です。製品ごとにインラインでリクエストを送信すると、Meta のレート制限に達し、マーチャントのリクエストが遅延します。キューイングして重複を除外することで、カタログの一括処理は安全かつ効率的に完了します。
Meta がリクエストを拒否した場合どうなりますか?
何も壊れません。拒否された、またはレート制限された ping は、Facebook が即座ではなく独自のスケジュールで更新することを意味します——ページ上のタグはすでに正しいため、この呼び出しはベストエフォートであり、必須の依存関係ではありません。