強制重新整理 Facebook Open Graph 快取

您可以強制重新整理 Facebook Open Graph 快取，因為 Facebook 是主要平台中唯一提供程式化方式來提出此要求的平台。您可以對單一連結使用 Sharing Debugger 的 Scrape Again 按鈕，或使用應用程式存取權杖呼叫 Graph API 的 scrape 端點。目前無法強制重新整理 WhatsApp、LinkedIn 或 X 的快取：這些平台並未對任何人提供此類 API。

最常讓人卡關的地方

Meta 會以頁面 URL 為鍵值快取連結預覽，並儲存自己的一份圖片副本。它不會重新讀取你的頁面來發現 og:image 現在指向別處。

因此，以下這個流程會失敗，而這正是大多數人嘗試的方式：

更換封面 → og:image URL 是新的 → 以為 Facebook 會自動更新 → 結果沒有。

新的圖片 URL 可以繞過圖片 CDN 的快取，但對 Meta 以頁面為鍵值的快取毫無作用。要讓 Facebook 更新，你必須告訴 Meta 頁面已經變更。

快取	鍵值依據	清除方式
你的頁面快取 / CDN	頁面 URL	清除快取
Meta 的連結預覽快取	頁面 URL	scrape 端點或 Sharing Debugger
Meta 的圖片副本	圖片 URL	新的圖片 URL
你的圖片 CDN	圖片 URL	新的圖片 URL

開啟 developers.facebook.com/tools/debug，貼上頁面網址，然後按下 Scrape Again。Meta 會重新抓取頁面並重建其快取的預覽。

這同時也是你手上最好的免費驗證工具，因為它回報的是 Meta 實際找到的內容，而不是你希望它找到的內容：遺漏或重複的 og:image、無法存取的圖片、不支援的格式。有兩件事它做不到：它無法處理 WhatsApp（快取是分開的，存在收件人的應用程式內），而且它不是目錄工具——它一次只能處理一個網址、有速率限制，且需要有人在前面操作。

選項二 — Graph API（這是外掛程式實際呼叫的方式）

FastOG 使用的程式化對等做法是向 Graph API 發出 POST 請求，並附上 scrape=true：

bash

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}"

有四項細節值得留意：

id 是頁面網址，不是圖片網址。 Meta 以頁面為依據來建立快取，因此對圖片網址發出請求不會刷新任何內容。
需要權杖（token） — Meta 自 2017 年 10 月起便要求此端點必須提供權杖。使用 {app_id}|{app_secret} 形式的應用程式存取權杖（app access token）即可，且無需使用者登入，這正是讓背景工作能發出此呼叫的關鍵。
Graph API 版本會持續演進。 FastOG 會固定使用經過測試的 Graph API 版本；在你自己的程式碼中固定版本之前，請先查閱 Meta 目前的最新文件與變更紀錄。
將其視為盡力而為（best-effort）。 Meta 會對抓取呼叫進行速率限制，若遭拒絕，僅代表 Facebook 會依自己的排程刷新，而非立即更新 — 你頁面上的標籤本來就是正確的。

由於此呼叫受速率限制，請勿在大型商品目錄每次儲存時都同步觸發。請改為排入佇列，並以網址進行去重，以免重複儲存相同的未變更商品時浪費速率限制額度。

選項 3 — 外掛程式幫你處理一切

標榜為「Open Graph 快取重新整理」的外掛程式可分為兩類，其中只有一類能修復 Facebook：

機制	清除的內容	能否修復過期的 Facebook 預覽？
在圖片 URL 後附加變動的查詢字串（`?v=timestamp`）	你的圖片 CDN	否 — Meta 的快取是以頁面為鍵值
針對頁面 URL 呼叫 scrape 端點	Meta 的預覽快取	是

安裝前，先確認它屬於哪一類。時間戳參數能真正修復過期的圖片，但無法修復過期的 Facebook 卡片。

FastOG for WooCommerce 屬於第二類，而且你完全不需要設定任何東西。 此外掛程式會註冊 WooCommerce 原生的商品 webhook，因此儲存商品時，會針對該商品的永久連結觸發 Meta 重新抓取 — 以佇列方式處理、在短時間視窗內去重，且刻意採用盡力而為（best-effort）設計，因此拒絕請求絕不會導致儲存失敗。此功能僅適用於商品頁面（product.created / product.updated）；分類與部落格編輯不在涵蓋範圍內。

圖片部分則另外處理，且做法與所有競爭對手不同：由於 FastOG 的封面 URL 包含產生該封面時所用的數值，因此編輯價格或照片會產生新的封面 URL。Meta 無法重新提供一個位址已不存在的圖片。

當 Facebook 不足以解決問題時

平台	能否強制重新整理？	實際發生的情況
Facebook	可以 — 使用偵錯工具或 `scrape=true`	會要求重新抓取；傳播時間長短不一
WhatsApp	否	預覽會快取在收件人的應用程式中；沒有可用的 API
LinkedIn	沒有文件化的程式化 API	會依自己的排程重新讀取；此處不提供公開的時機保證
X / Twitter	沒有文件化的程式化 API	會依自己的排程重新讀取；此處不提供公開的時機保證
Slack、Discord	否	短暫的快取，會在數分鐘到數小時內自動清除

如果 WhatsApp 上的預覽過期，答案不是使用 Facebook 的工具，而是把商店端設定正確，這樣下一次讀取時就會是正確的。

成功抓取後仍顯示舊圖片時

請依序檢查以下清單：

頁面是否仍提供舊的標籤？ curl -s https://your-store.com/product/example | grep -i 'og:image' — 帶有過期 og:image 的快取 HTML 頁面會讓抓取完全失效。請清除頁面快取。
頁面是否輸出了多個 og:image？ 如果兩個外掛各輸出一組，爬蟲會取用最先讀取到的那組。請計算數量。
圖片是否可存取且未被封鎖？ curl -I <image-url> 應回傳 200，並帶有圖片 Content-Type。社群爬蟲會遵循 robots.txt，因此位於 Disallow: 路徑上的圖片會以類似檔案損毀的方式失敗——而 curl 永遠無法重現此問題，因為 curl 會忽略 robots.txt。
圖片 URL 是否真的變更了？ 如果沒有變更，內容自然也沒有變更——請確認價格／照片的編輯確實寫入了卡片所讀取的來源。
再次檢查除錯工具。 如果它現在回報新圖片，但 Facebook 仍顯示舊卡片，那麼你看到的是 Facebook 自身的傳播延遲，而非你的標籤問題。

常見問題

是否有官方 API 可以清除 Facebook 的 Open Graph 快取？

FastOG 使用 scrape 端點（POST https://graph.facebook.com/{version}/?id={page-url}&scrape=true&access_token={token}）。Meta 有文件說明 Sharing Debugger 與程式化爬取流程；確切的端點格式與 Graph API 版本可能變動，因此在自行實作前，請先對照 Meta 目前的最新文件進行確認。

不需要。它是公開工具，適用於任何公開 URL。但它無法排程執行，也無法涵蓋整個商品目錄。

重新爬取會消耗一次 FastOG 渲染嗎？

通常不會。封面 URL 是根據內容產生的，因此若內容未變更，URL 也不會變更，此時的擷取會命中快取，不消耗渲染。若價格變更，URL 就會變更——這會產生一次新的渲染，而這正是你想要的渲染。

重新爬取 Facebook 能修正我的 WhatsApp 預覽嗎？

不能。兩者是獨立的快取。Facebook 的偵錯工具仍值得作為驗證器使用——它會以與 WhatsApp 相同的方式擷取頁面，並回報找到的內容——但它無法重新整理 WhatsApp 的快取。

如果我從不主動通知，Facebook 會保留預覽多久？

Meta 文件記載標準的重新爬取週期約為 24 小時，但實際傳播時間可能有所差異。這就是偵錯工具與程式化爬取路徑存在的原因。

商品目錄匯入後，我必須逐一通知每個商品嗎？

這就是佇列的用途。若在請求中逐一為每個商品發送請求，會觸發 Meta 的速率限制，並拖慢商家的請求；透過佇列與去重處理，目錄掃描可以無害地排空。

如果 Meta 拒絕請求怎麼辦？

不會有任何問題。被拒絕或受限速的通知，只代表 Facebook 會依自己的排程重新整理，而非立即更新——頁面上的標籤本來就是正確的，因此這項呼叫屬於盡力而為，而非硬性依賴。