文章排版盯了 2 個小時，標題下對、結論也順，把連結丟進 LINE 群組的那一刻，縮圖卻是一片灰底，什麼圖都沒有。這種畫面，只要你自己維護過網站，大概都遇過，而且問題通常不是圖片本身壞掉，是一個叫 og:image 的標籤沒設對。
og:image 是 Open Graph 協定裡負責告訴 Facebook、LINE 這類平台「分享這篇文章時要秀哪張圖」的標籤，它藏在網頁原始碼的 head 區塊裡，訪客平常看不到，卻決定了分享出去的貼文有沒有人願意點進來。同一篇文章，縮圖清楚吸引人跟縮圖空白，點擊意願能差上一大截，這也是為什麼設定對不對值得花時間認真排查。
造成 og:image 失靈的原因不只一種，從壓根沒設定、檔名藏著中文、圖片尺寸不合格，到平台自己的快取一直吐出舊圖都算，每一種畫面看起來都差不多，排查方法卻要對症下藥。
分享到臉書或 LINE，縮圖經常空白或整個抓錯
分享出去的連結，縮圖通常長成 3 種樣子中的一種。第一種是預覽卡上什麼圖都沒有，只剩一片灰底或純色方塊；第二種是圖抓到了，但抓到的跟這篇文章毫無關係，可能是網站的 Logo、側欄的小圖示，甚至是某張投放中的廣告圖；第三種是縮圖位置顯示破圖圖示，代表平台去抓了圖片網址卻讀不到內容。
這 3 種畫面表面上都是「圖不見了」，背後對應的卻是幾個各自獨立、可以逐一排除的技術原因，不是網路忽然不穩，也不是隨機出狀況。分享縮圖是讀者點進連結前唯一看得到的視覺線索，抓錯或空白都會直接壓低點擊意願，值得認真拆一輪。要拆解這些原因，得先弄懂縮圖是靠哪個標籤決定的，答案就是 og:image 在 Open Graph 協定裡扮演的角色。
og:image 是什麼？決定分享縮圖的 Open Graph 標籤
Open Graph 協定替每一個網頁定義了一組共通的標籤，讓 Facebook、LINE 這類平台不用自己去猜網頁在講什麼，直接讀標籤就知道。協定官方規定每個頁面至少要有 4 個必要屬性：og:title（標題）、og:type（內容類型）、og:image（圖片）、og:url（網址）。其中 og:image 的官方定義是「代表這個物件在圖譜中的一張圖片網址」，簡單說，就是分享出去時該秀哪張圖。
og:image 還能搭配幾個結構化的子屬性，跟在它後面補充細節：og:image:width 與 og:image:height 標明像素寬高、og:image:secure_url 提供 HTTPS 版網址、og:image:type 標明檔案的 MIME 類型、og:image:alt 則是圖片描述文字，官方協定建議只要設了 og:image，就該一併設 og:image:alt。一個頁面也可以放多組 og:image 代表多張候選圖片，但衝突時的規則是由上而下第一個標籤為準，子屬性要緊接在它所屬的那個 og:image 標籤之後，遇到下一個 og:image 就代表前一組已經結束。
這套標籤要生效，得先通過爬蟲那一關的技術門檻，也得先通過 WordPress 從精選圖片轉換成 og:image 的邏輯，兩關只要有一關沒通過，縮圖就抓不到。
FacebookExternalHit 讀取頁面的方式與限制
Facebook 的爬蟲程式叫 FacebookExternalHit，Meta 官方文件形容它的用途是「爬取 Meta 系列應用程式上所分享的網站內容，收集、快取並顯示標題、說明及縮圖影像」。這支爬蟲有幾個技術前提，沒滿足其中任何一項都會讀取失敗：伺服器要支援 gzip 與 deflate 編碼；所有 Open Graph 屬性必須出現在網頁前 1MB 的內容之前，超過這個範圍會被直接截斷讀不到；爬蟲的請求要在幾秒內完成，逾時就抓不到內容；官方也建議把爬蟲的 user agent 或 IP 加進伺服器的許可清單，避免被其他機制誤擋。
更關鍵的一點是，FacebookExternalHit 不會執行 JavaScript，它只讀取當下伺服器回應的靜態 HTML。如果 og:image 這類標籤是靠 React、Vue 這種前端框架，在瀏覽器端才動態塞進 head 區塊，爬蟲讀到的往往是還沒渲染完成的空殼頁面，看不到那些標籤。這正是「拿偵錯工具測試都正常，實際分享卻抓不到圖」最常被忽略的一種情況。想確認自己的網站有沒有踩到這一點，可以直接模擬爬蟲的請求方式：
curl -v --compressed -H "Range: bytes=0-524288" -H "Connection: close" -A "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)" "https://example.com/your-article-url"Code language: Bash (bash)跑出來的結果如果看不到 og:image 標籤，通常就代表標籤是動態注入的，而不是隨伺服器回應一起送出。
WordPress 精選圖片轉成 og:image 的路徑
在 WordPress 的世界裡，og:image 通常不是站長自己手動寫進 head 的一行標籤，而是靠 Yoast SEO、Rank Math 這類 SEO 外掛，自動把文章的精選圖片轉換成 og:image。精選圖片是來源，og:image 是輸出，中間隔著一層外掛邏輯，這也是為什麼問題常常出在轉換這一步，而不是精選圖片本身壞掉。
WordPress 上傳一張圖片時，會自動一次產生好幾種尺寸：預設的完整原始尺寸（full）之外，Yoast 官方文章記錄的常見規格還有 large（1024×1024px）、medium_large（768px，且經過裁切）、medium（300×300px）、thumbnail（150×150px），不過這些預設值常被佈景主題或其他外掛改動過。Yoast SEO 的判斷邏輯是，當 full 尺寸圖片超過 2MB，或任一邊超過 2000px，就會嘗試退回較小的標準尺寸，或掃描文章內文找替代圖片；真的找不到合適的圖片，外掛乾脆省略 og:image 標籤，讓平台自己去猜。
同一篇 Yoast 官方文章也記下一個容易被忽略的行為，頁面若同時輸出多組 og:image 標籤，Facebook 採用的是集合中第一個，這跟 Open Graph 官方協定一致，但跟「Facebook 會挑最大張的圖」這種普遍認知相反，而且就算第一張是壞掉的網址，Facebook 依然只認第一個，不會自動跳去用第二個。外掛或主題若同時輸出好幾組 og:image，順序排錯就直接等於抓錯圖或抓不到圖。
頁面沒有 og:image 標籤時，爬蟲改用內部猜測邏輯
完全沒設定過 og:image，跟設定了但設錯，是 2 件不同的事，排查的方向也不一樣。Meta 官方文件對「沒設定會怎樣」給出的唯一明確說法是：「如果沒有這些開放社交關係圖標籤，Facebook 網路爬蟲會使用內部啟發學習法盡可能猜測內容的標題、說明和預覽圖像。」換句話說，猜測用的演算法沒有公開，官方也沒承諾猜到的結果會是文章的精選圖片。
實務上，沒設定 og:image 最常見的後果，就是分享出去抓到一張跟文章無關的圖，頁首的網站 Logo、側欄的小圖示、內文裡剛好排在最前面的一張圖，都可能被抓走，不一定是站長心裡想的那張精選圖片。這也是為什麼即使精選圖片設好了，還是有必要確認後台用的 SEO 外掛，社群分享這個模組是不是真的有開，而且真的有輸出 og:image。不少外掛安裝時，社群分享相關的功能模組預設是關閉的，要手動啟用才會生效。
精選圖片檔名藏著中文，臉書爬蟲讀不到正確網址
另一種更隱蔽的情況是，og:image 標籤本身確實有輸出、網址也指向正確的圖片，問題出在網址本身讀不到，最常見的原因是精選圖片上傳時檔名維持中文，例如「產品照片.jpg」或「文章封面圖.png」，WordPress 會把這個中文檔名原樣存進媒體庫，圖片網址裡因此夾帶中文字元。
網址的規範只允許 ASCII 字元，中文這類非 ASCII 字元出現在網址裡時，瀏覽器與伺服器會把它轉成百分比編碼（percent-encoding），一個中文字元會變成一長串類似 %E4%BA%A7%E5%93%81 的符號。不同伺服器設定、CDN、快取層對這種編碼後網址的處理方式並不一致，其中有些環節會把編碼過的網址處理錯誤或截斷，導致 Facebook 爬蟲實際去抓圖時，拿到的是一個讀不到內容的網址。前面提到爬蟲要在幾秒內完成請求，且要能正常讀到內容，網址一旦在某個環節被錯誤處理，等於爬蟲根本沒機會拿到有效的圖片網址，自然抓不到圖。
解法很直接，把精選圖片的檔名改成英文或數字，用連字號分隔單字，不要用中文替圖片檔案命名。這件事最好在你上傳圖片的當下就養成習慣，因為圖片一旦被媒體庫收錄、網址也被各處引用之後，事後要重新命名往往牽動更多地方。
圖片尺寸太小或格式不符，直接被系統忽略
網址正確、圖片檔案也讀得到，不代表這張圖就會被平台拿來當縮圖，Facebook 對 og:image 本身的尺寸與格式設了門檻，低於門檻或格式不支援，圖片會被直接忽略，而不是縮圖顯示得比較差。國際主機商 Kinsta 官方知識庫的實測記錄是：Facebook 要求的最小圖片尺寸是 200×200 像素，低於這個尺寸圖片會被直接忽略；一般情況下 1200×630 像素的效果對多數情境最好，比這個尺寸更大也可以，但 Facebook 會自動裁切，你設計時得留意這個長寬比會不會裁到重要的畫面內容。
Yoast 官方技術文章的建議則是把 og:image 尺寸落在 1200×800px 到 2000×1600px 之間、檔案控制在 2MB 以下；Facebook 允許的圖片檔案大小上限是 8MB，但太大的圖會被裁切成小尺寸縮圖，Yoast SEO 因此在外掛裡內建了原圖超過 2MB 或任一邊超過 2000px 就退回較小尺寸的自動限制（前面已提過這條邏輯）。WordPress 的精選圖片若沿用網站預設的縮圖尺寸，很可能根本不到這個門檻，這也是精選圖片明明有設定、縮圖卻還是空白的常見原因之一。
Meta 官方文件也說明了 og:image:width 與 og:image:height 這兩個子屬性的用途，是「指定圖像的高度和寬度，以確保圖像第一次分享時可以正確載入」。這呼應 Kinsta 記錄的一則偵錯工具實際警告文字：「The provided ‘og:image’ properties are not yet available because new images are processed asynchronously. To ensure shares of new URLs include an image, specify the dimensions using ‘og:image:width’ and ‘og:image:height’ tags.」意即新圖片是非同步處理，第一次分享時系統可能還沒處理完，補上寬高標籤能降低這個風險。另外，WebP 是 WordPress 近年鼓勵預設使用的圖片格式，但社群平台對它的支援不像 JPG、PNG 那樣穩定一致，精選圖片若是 WebP 格式，也值得列入你的排查名單。
會員限定與資安規則擋下的頁面，爬蟲一樣進不去
前面幾個原因都出在 og:image 標籤或圖片本身，這一類則完全不同，標籤設定得再正確，只要爬蟲根本進不去頁面，一樣抓不到東西。這裡有 2 種本質不同、但表現一樣的情況：一種是內容本身需要登入或付費才看得到，另一種是網站的資安機制把 Facebook 爬蟲當成攻擊流量擋掉。Meta 官方文件的核心原則是內容要能被爬蟲正常存取，才能被正確分享；密碼保護、需要登入才能看到的頁面，爬蟲拿到的回應不是文章實際內容，自然抓不到設定好的 og:image。
分辨自己是哪一種很重要，因為修法完全不一樣，會員限定要調整的是內容的公開設定，資安誤擋要調整的是防火牆規則，兩者都跟 og:image 標籤寫得對不對無關。
需要登入才能看到的內容，爬蟲看到的是空白或登入畫面
WordPress 的密碼保護文章就是典型例子。文章一旦設了密碼，不管是一般訪客還是 Facebook 的爬蟲，打開網址看到的都是同一個密碼輸入表單，不是文章正文，也就讀不到裡面設定好的 og:image。會員限定內容的邏輯完全一樣，公開網址背後其實回傳的是登入導向頁，爬蟲拿到的是那個導向頁的內容，不是真正的文章。
要把這種內容分享到社群，內容本身必須是公開可讀的，這是分享機制運作的前提，不是靠調整 og:image 設定能繞過的問題。如果你真的希望密碼保護的文章也有正常的分享縮圖，通常得另外做一個公開的預告頁，或乾脆先取消密碼保護。
防火牆與資安外掛把 FacebookExternalHit 判斷成攻擊流量
內容明明是公開的，爬蟲卻還是進不去，多半是網站前面掛的 CDN 或 WAF 出手擋下。以 Cloudflare 為例，官方文件「Issues sharing to Facebook」明確列出 3 種會讓分享出現「Attention Required」錯誤的情境：全站開啟了 Under Attack 模式；某條 Configuration Rule 或 Page Rule 把 Under Attack 模式打開；自訂規則裡有挑戰或封鎖動作，剛好包含到 Facebook 的 IP。文件也提到國家挑戰規則可能連帶擋到 Facebook，因為 Facebook 已知會從美國與愛爾蘭兩地發出爬取請求。
解法是移除擋到 Facebook IP、ASN 或國家的自訂規則，或針對 ASN AS32934 與 AS63293 建立一條動作設為 Skip 的規則，並在規則裡設定略過 Security Level；同時也該檢查現有的 Configuration Rule 與 Page Rule 有沒有不小心影響到 Facebook 的請求。處理完之後別忘了回到 Facebook 的分享偵錯工具，用重新抓取重新讀取一次，才會反映修正後的結果。
明明已經改好，臉書卻還在用舊圖的快取機制
前面的原因都排除了、圖片也換好了，分享出去卻還是顯示舊圖，甚至是壞掉的圖。這是最容易讓人抓狂的一種情況，原因出在 Facebook 第一次抓到內容後就會把結果快取起來，之後不會主動重新抓，除非被強制要求重抓。Meta 官方文件講得很直接：「圖像網址。若要在發佈圖像後更新圖像，請為新圖像使用新的網址。由於系統是依照網址快取圖像，如果沒有變更網址，圖像將無法更新。」也就是說，換了圖但網址沒換，在 Facebook 眼中等於什麼都沒變。
Kinsta 官方知識庫的說明補充了實務上的細節，「每當有人分享內容到 Facebook，它會把圖片快取在自己的伺服器與 CDN 上。如果之後網站有更新，Facebook 分享時可能還是顯示舊圖，因為它不會重新抓取，而是直接吐出已經快取的資訊。」這也代表光清了網站端的快取還不夠，如果站台前面還掛著另一層 CDN 快取，也得一併清乾淨，Facebook 的爬蟲才抓得到真正最新的網頁內容。
這個快取沒有公開的到期時間，Prerender.io 官方部落格的觀察是，「Facebook 通常會把連結預覽快取到近乎沒有期限，頁面內容分享出去之後才修改中繼資料，新的預覽不會自動更新，一定要用分享偵錯工具強制重新抓取」。圖不會因為時間過了就自動換過來，要刷新只能靠強制重新抓取這個動作。
用臉書分享偵錯工具重新抓取的正確順序
Meta 官方對分享偵錯工具的定位很明確，官方文件形容它「可讓你預覽內容分享到 Facebook 後的呈現方式，以及偵測開放社交關係圖標籤的任何問題」。前面拆過的每一個原因，最後都會回到同一個動作，就是用這個工具強制重新抓取，看修正有沒有真的生效。
只是工具本身的用法有幾個容易踩錯的細節：順序不對、警告訊息判讀錯誤，或者只按一次就放棄，都會讓人誤以為工具沒用，其實是操作方式沒到位。
先清網站與 CDN 快取，再讓偵錯工具重新讀取
順序錯了，就算你按了重新抓取也等於白費力氣。如果網站或 CDN 端的快取沒清乾淨，Facebook 的爬蟲實際讀到的仍然是舊版 HTML。Kinsta 官方知識庫的操作建議是，「要確保 Facebook 抓到文章的最新資訊，得先清 WordPress 的快取，如果站上舊圖片還被快取著，分享偵錯工具沒辦法解決問題，它只會重新抓到已經快取的資訊而已」。
如果站台前面還掛著 CDN，圖片也可能被快取在 CDN 上，這種情況需要另外清 CDN 的快取，才算真的清乾淨。用的是有自動清快取機制的代管主機，更新文章時通常會自動處理這一層，但仍要留意站上有沒有另外裝了第三方快取外掛，那一層代管主機不會知道，也不會自動幫忙清。清完網站與 CDN 兩層快取，才輪到打開分享偵錯工具貼上網址重新抓取。
偵錯工具的警告訊息，該修的與可以忽略的
分享偵錯工具偶爾會跳出看起來很嚴重、實際上不影響結果的警告。Kinsta 官方知識庫記錄過一個實測案例，工具警告某張圖片超過 8MB 上限，且伺服器回應太慢，但實際上那張圖只有 160.63KB，頁面載入也不到 1 秒。這份記錄也提醒，這類警告不一定準確，遇到跟實際狀況明顯對不上的警告，先照實際圖片大小與載入速度自行判斷，不必照單全收。
真正該認真處理的是另一種警告，也就是前面「圖片尺寸太小或格式不符」那節提過、Kinsta 記錄的那則「新圖片非同步處理、尺寸標籤尚未就緒」提示。這通常是圖片尺寸不足觸發的，前面那節提過的做法在這裡同樣適用，把 og:image:width 與 og:image:height 補齊，能降低這個警告再次出現的機率。
同一個網址常常要按兩三次「重新抓取」才會生效
很多人第一次按下重新抓取，看到結果還是舊的就放棄了，其實通常要連續按個 2 到 3 次才會真正刷新。Kinsta 官方知識庫的說法是，這時候會第二次按下重新抓取，聽起來有點奇怪，但很多時候真的需要重抓 2 次，操作之後才會看到新的精選圖片與新檔名出現在 og:image 屬性裡。
還有一點容易被誤會，重新抓取不會回頭更新已經被分享出去的舊貼文，它只會影響之後（重新抓取之後）才分享出去的連結。如果舊貼文的縮圖已經定型，通常得刪掉重新分享一次，而不是期待它自己跟著更新。
LINE 同樣讀取 Open Graph 標籤，但沒有對應的官方偵錯工具
把 Facebook 那一套排查完，再回頭看 LINE 分享的縮圖問題，會發現原理完全相通。LINE 讀取的同樣是 og:title、og:description、og:image 這幾個標籤，並不是 LINE 自訂的專屬格式，而是遵循 Open Graph 官方協定的通用機制。前面拆過的每一種原因，缺標籤、精選圖片檔名藏中文、圖片尺寸不合格、資安規則誤擋，對 LINE 一樣成立，排查方式也一樣。
真正的差別在後段的補救動作。LINE 原本有一個自家提供的快取清除工具，開放使用多年後已在 2025 年中正式關閉服務，目前沒有官方替代方案；LINE 也沒有公開發布過快取的時效多長。也就是說，遇到 LINE 那邊卡著舊圖不放的情況，現在沒有官方管道可以直接要求它強制重新抓取。
沒有官方工具時，實務上可行的做法是換一個帶有差異化查詢字串的網址，在原本的網址尾端加一段先前沒出現過的參數，對大多數依網址做快取鍵值的分享平台來說，這會被判定成一個沒看過的新網址，因而重新抓取一次目前版本的 og 標籤。這個做法不會影響網站原本的內容，也不會干擾 SEO 判斷的標準網址，前提是網站本來就設好了 canonical 標籤，讓搜尋引擎清楚知道哪一個網址才是正式版本。
把前面拆過的幾種情況兜在一起看，縮圖抓錯九成不是玄學，而是某個具體環節被擋住，標籤沒設好、檔名藏著中文、圖片尺寸不夠，或是資安規則把爬蟲當成攻擊擋下。每一種都對應到一個明確的檢查點，也都能用同一套邏輯排查：先確認標籤有沒有正確輸出，再確認圖片本身過不過門檻，最後才輪到快取要不要強制刷新。
往後你每次換精選圖片，養成一個習慣多半就能省下大半排查時間：檔名別用中文，尺寸落在建議範圍內，換完圖記得先清快取，再讓平台重新抓取一次。LINE 少了官方偵錯工具這一關，換圖之後更值得自己多確認一次顯示結果，別等讀者回報縮圖不對才發現問題。