OG 標籤完整教學：Open Graph 設定、圖片尺寸與社群分享優化技巧
OG 標籤（Open Graph Meta Tags）是放在網頁 head 區塊的 meta 標籤，由 Facebook 在 2010 年提出（規範維護於 ogp.me），用來告訴…
OG 標籤是什麼？Open Graph 社群預覽的源頭開關
OG 標籤（Open Graph Meta Tags）是放在網頁 head 區塊的 meta 標籤，由 Facebook 在 2010 年提出（規範維護於 ogp.me），用來告訴社群平台的爬蟲：這個連結分享出去時要顯示什麼標題、描述、縮圖與網址。實務上只要設好 og:title、og:description、og:image、og:url 這四個核心標籤，就能把任意連結的社群分享預覽鎖定成你想要的樣子（來源：Meta 官方 Open Graph 分享文件、ogp.me 協議規範）。它是內容在社群被點擊前的最後一道門面工程，正確定位是社群引流與點擊率優化工具，SEO 排名加分項這個印象其實是誤解。
重點先看：OG 標籤控制的是社群分享預覽長相，不影響 Google 排名；圖用 1200×630 px、小於 8 MB、地雷線 200×200 px，四個核心標籤設好就能控制 90% 的預覽結果（來源：Meta Sharing Debugger 官方文件）。
很多人把 OG 標籤當成 SEO 的一環，這其實是定位錯了。它真正服務的對象是 Facebook、LINE、LinkedIn、Twitter 這些社群平台的爬蟲，Googlebot 並不讀取這組標籤。當你在 LINE 群組貼一篇文章連結，那張縮圖、那段標題、那句描述從哪裡來？答案就是這幾行埋在 head 裡的 meta 標籤。沒設的時候，爬蟲只能自己猜，猜得好不好全憑運氣，常常出現一張跟主題無關的圖，或一段從內文亂截、完全沒重點的文字。
把它想成內容在社群被點擊前最後一道你還能動手的設定，會比較好理解。你的文章可能寫得很好、站內 SEO 也做到位，但只要這幾行 meta 沒設好，社群導流的點擊率就會直接腰斬。這也是為什麼即便它跟排名訊號無關，仍然是品牌官網與內容站經營者不能跳過的設定。如果你正在做 WordPress SEO 優化指南的整體規劃，OG 標籤屬於「社群引流」那一塊，別把它塞進技術性 SEO 的待辦清單裡。
Open Graph 協議最初是 Facebook 為了讓網頁能像「物件」一樣被社群圖譜收錄而設計的，後來被 LINE、LinkedIn、Twitter 等主流平台採用，成了事實標準。協議本身定義了 og:title、og:description、og:image、og:url、og:type、og:video 等多種屬性，但官方也說得很明白：基本預覽只要四個標籤就夠了，其餘屬性是加分項。對大多數經營 WordPress SEO 必做設定的站長來說，把這四個標籤設好，比追著一堆進階屬性更重要。
放對位置是基本功。OG 標籤必須放在 HTML 的 <head> 區塊內，放在 <body> 裡爬蟲不會穩定讀取，這是新手最常踩的雷之一。如果你用的是 WordPress SEO 外掛完整評測裡介紹的 Rank Math 或 Yoast，外掛會自動把標籤輸出到正確位置，你完全不用碰程式碼。這也是現代架站幾乎沒有人會手寫 OG 標籤的原因，工具已經把這件事做掉了，你只要會填欄位就好。
OG 標籤與 SEO 排名的真實關係：直接影響為零
設定 OG 標籤能不能提升 Google 排名？答案是：不能，至少不是直接影響。Google 並未將 Open Graph 列為搜尋排名的直接因子，官方與 Search Central 的公開說明都沒有把它放進排名訊號清單，它的角色比較接近 meta description，屬於間接影響。把 OG 標籤當成 SEO 直覺裡的加分項，會誤判投資報酬，因為它真正改變的是社群點擊率與帶來的推薦流量，而不是搜尋結果頁的位置。要釐清這條界線，先把搜尋結果頁 SERP 介紹看過一遍，理解 SERP 上有哪些元素會被排名訊號影響，就會明白 OG 標籤為什麼不在此列。
那它到底間接幫了什麼？當預覽圖與標題夠吸睛，社群點擊率（CTR）會上升，連結被點開的次數變多，網站就會收到更多推薦流量。這些從社群進來的訪客，有一部分會產生品牌搜尋、回流造訪，甚至把內容分享到自己的網站形成反向連結，這些次級訊號才會回頭影響 SEO 表現。這條路徑的價值可以用搜尋端的點擊率分布來佐證：有研究分析約 400 萬筆 Google 搜尋結果後發現，第一名結果的平均點擊率約 27.6%，前三名合計拿下 54.4% 的點擊，而第二頁結果僅獲得 0.63% 的點擊（來源：〈Backlinko Google CTR Stats: We Analyzed 4 Million Google Search Results〉〈https://backlinko.com/google-ctr-stats〉〈2025-04-16〉）。把這組數字擺在旁邊就能理解：點擊率本身在搜尋端就是高度集中的稀缺資源，社群端把點擊率顧好、把導流做大，等同於在搜尋之外另開一條進站通道，減少單押搜尋排名的風險。換句話說，OG 標籤是流量的「前一步」，排名的提升還需要內容、連結、技術性 SEO 等其他訊號累積才能推動。如果你對點擊率這條線有興趣，可以再讀 CTR 點擊率優化攻略與 CTR 點擊率計算與提升，把搜尋端與社群端的點擊率一起看。
這裡要承認一個常被忽略的限制：OG 標籤管不到點擊進來的人會不會停留、會不會轉換。把預覽做得再漂亮，如果落地頁的內容沒有撐住，跳出率一樣會很高，而跳出率與停留時間才是搜尋引擎會觀察的訊號。它真正的位置在 社群媒體行銷實戰與點擊率優化這一側，要搭配內容策略與整體 技術性 SEO 完整指南才會發揮價值。若想在更系統化的框架下把社群與搜尋兩端一起推進，搭配 Ahrefs 操作的 SEO 陪跑班能提供從關鍵字到外部連結的完整練習路徑。
另一個容易被誤會的點是，OG 標籤跟 Google AI Overviews 與 SEO、AEO 答案引擎優化指南的關係。AI 搜尋引擎在引用內容時，看的還是頁面的主題權威與結構化資料，不是社群預覽標籤。把資源投在 Schema 結構化標記（見 結構化資料 Schema 標記教學）會比投在 OG 標籤更直接影響 AI 引用，兩者服務的是不同的引用場景。順著這條線往下想，當爬蟲從鍵入查詢走向自動瀏覽網站、自行點擊與擷取答案，AI 友善網站與 Agentic Browsing 會成為結構化資料之外另一個值得提前準備的方向。
| 項目 | OG 標籤（Open Graph） | SEO 排名訊號 |
|---|---|---|
| 服務對象 | FB、LINE、LinkedIn 等社群爬蟲 | Googlebot 等搜尋引擎 |
| 是否為 Google 排名因子 | 否（官方未列入） | 是（排名訊號清單內） |
| 直接影響 | 社群分享預覽、社群點擊率 | 搜尋結果排序 |
| 間接影響 | 推薦流量、品牌搜尋、次級連結訊號 | 點擊率、停留、轉換 |
| 正確定位 | 社群引流與點擊率優化工具 | 排名與能見度優化工具 |
說到底，把 OG 標籤的投資報酬算清楚，才知道力氣該花在哪。它成本低、見效快（改一張圖、改一段標題，社群預覽立刻不一樣），但天花板也明確（不會把你推上搜尋第一頁）。把它當成內容發布前的最後一哩路，搭配 關鍵字搜尋意圖解析與 SERP 搜尋結果頁解析做整體規劃，CP 值才會浮現。若選題階段想多一個流量參考來源，Bing 關鍵字搜尋量免費查詢方法能補上 Google 之外的搜尋需求視角。
四個必設的 OG 標籤屬性：og:title、og:description、og:image、og:url
Open Graph 官方屬性有很多種，但實務上只要設好 og:title、og:description、og:image、og:url 這四個，就能完整控制社群分享時的標題、描述、預覽圖與顯示網址，其他屬性都是加分項而非必要。這四個標籤可以獨立於 meta title 與 meta description 來寫，也就是說你可以針對社群語境另外寫一套更口語、更有 CTA 感的文案，不必跟搜尋結果頁用同一份。
- og:image：分享時的預覽圖，是影響社群點擊率最關鍵的標籤。一張好圖勝過千言萬語，建議尺寸 1200×630 px、檔案小於 8 MB，格式用 JPG 或 PNG（來源：Meta 官方分享文件）。圖片 SEO 本身另有學問，可參考 圖片 SEO 優化指南。
- og:title：社群顯示的主標題。中文建議簡短有力、避免被截斷，太長會在預覽中被砍尾。標題怎麼寫才能兼顧點擊與語意，可看 SEO 標題優化技巧；若想從搜尋端的 Title Tag 一路摸到社群端，SEO Title Tag 大全會把兩端的寫法差異一次講清楚。
- og:description：標題下方的描述文字，1 到 2 句講清楚點擊後能得到什麼，鼓勵用戶點擊，避免長篇大論被截斷。
- og:url：應設為無 utm 參數的標準網址，例如
https://example.com/post-title，而不是帶?utm_source=facebook的版本。這樣 Facebook 的按讚與分享才會匯總到同一個網址，統計才不會分散。
og:url 這一點特別值得展開講。很多站長習慣在分享連結上掛 UTM 追蹤碼參數設定來分辨流量來源，這在分析端是對的，但 og:url 本身不該帶這些參數。因為 Facebook 是用 og:url 來辨識「這是同一則內容」，一旦每個分享網址的 utm 不同，按讚數就會被拆成好幾份，無法累積。正確做法是 og:url 指向乾淨的標準網址，utm 只掛在你「實際分享出去」的那條連結上。這跟 Canonical URL 標準網址設定是同一個邏輯，只是服務的平台不同。
四個標籤的 meta 寫法長這樣，直接放在 head 區塊即可：
<meta property="og:title" content="你的社群標題">
<meta property="og:description" content="一到兩句話的描述">
<meta property="og:image" content="https://example.com/og-image.jpg">
<meta property="og:url" content="https://example.com/post-title">有一點要提醒：og:image 一定要用絕對網址（含 https://），不能用相對路徑。相對路徑在你自己的網站上能顯示，但社群爬蟲抓圖時往往會失敗，這是「社群分享沒有預覽圖怎麼辦」最常見的元兇之一。如果你的網站還沒全面上 HTTPS，也會影響圖片被抓取，建議先處理 HTTP 換 HTTPS 設定與 SSL 憑證安裝與 SEO 影響。
og:type 也是值得一提的屬性，它告訴平台這是一篇文章、一個網站還是一部影片，預設值是 website。對部落格文章來說設成 article 比較精確，也能讓平台抓到作者、發表時間等額外資訊。不過這屬於進階設定，沒設也不會讓預覽壞掉，前面四個核心標籤設好才是第一優先。如果你決定自己動 head 而不靠外掛，過程中遇到不熟悉的程式碼，可以讓 Codex AI 程式助理幫你檢查 meta 寫法，省下反覆除錯的時間。
想要再進階一點，可以加上 og:image:width 與 og:image:height 這兩個屬性，明確標示圖片的長寬。它們的作用是讓社群平台在抓到圖檔之前就能先算好版面，加速分享卡的渲染、避免預覽出現時版面突然跳動（layout shift）。這兩個屬性不是必要設定，沒加也不會讓預覽壞掉，但對體驗有正面幫助，尤其適合重視載入流暢度的網站。完整的官方屬性清單可以查 ogp.me 規範，或 Meta 提供的開放社交關係圖標記說明文件。
og:image 不被裁切與正常抓取的尺寸與格式條件
og:image 建議使用 1200×630 px、JPG 或 PNG 格式，長寬比約 1.91:1，這是 Facebook、Twitter、LinkedIn 通用的比例；LINE 則偏好接近正方形的 1:1。圖檔要小於 8 MB，且絕對不能小於 200×200 px，否則爬蟲可能直接抓不到圖、連結變成沒有預覽圖的純文字。尺寸這條線沒得商量，是官方文件寫死的硬門檻（來源：Meta Open Graph 分享最佳做法、ogp.me）。
| 尺寸 / 比例 | 用途與效果 | 風險 |
|---|---|---|
| 1200×630 px（1.91:1） | 標準建議尺寸，高解析度裝置顯示最佳 | 幾乎無，FB/Twitter/LinkedIn 通用 |
| 600×315 px | 大圖預覽的最低門檻 | 低於此會縮成小圖預覽，吸睛度下降 |
| 200×200 px | 地雷線 | 低於此爬蟲可能完全不抓圖，連結無預覽 |
| 1:1（正方形） | LINE 偏好比例 | 在 FB 上會被裁切，需另外備圖 |
| 檔案 > 8 MB | 超過官方上限 | 抓取失敗或載入過慢 |
這裡有個實務上很痛的點：同一篇文章要分享到 FB 又要分享到 LINE，理想的預覽圖比例不一樣。FB 要 1.91:1，LINE 要 1:1，你不可能同時完美。折衷做法是準備一張 1200×630 的主圖給多數平台，再另外裁一張正方形版本專門應付 LINE，但這需要程式或外掛支援條件式輸出，對大多數站長負擔不輕。資源有限時，先守 1200×630 這個最大公約數，至少 FB、Twitter、LinkedIn 三個平台都會正常顯示。
圖檔大小那條 8 MB 上限，聽起來很寬鬆，但其實很多站長會踩到。主因是沒壓縮就直接上傳原始拍攝檔，一張手機直出照片動輒 3 到 5 MB，再叠加高解析度就破上限了。這條線之所以要特別盯緊，還牽涉到裝置分布：2026 年第一季全球網站流量有 52.27% 來自手機（不含平板），社群分享絕大多數發生在行動裝置上（來源：〈Statista Share of mobile web traffic worldwide quarterly 2015-2026〉〈https://www.statista.com/statistics/277125/share-of-website-traffic-coming-from-mobile-devices/〉〈2026-04-28〉）。手機網路不穩、吃到飽方案也有降速門檻，圖檔一旦偏大，分享卡載入就會卡頓，用戶在預覽還沒算好版面前就滑走，等於把點擊機會白白丟掉。建議上傳前先用壓縮工具處理過，既能加快頁面載入（這跟 網站速度優化全攻略、Core Web Vitals 效能指標直接相關），也能避開 OG 抓不到圖的風險。WordPress 站長可以直接看 WordPress 圖片壓縮與延遲載入與 圖片壓縮工具實測推薦，挑一套順手的工具長期用。
圖被裁切是另一個常見痛點。當你用 1.91:1 的圖丟到偏好 1:1 的平台，上下會被切掉；反過來把正方形丟到 FB，左右會被裁。安全做法是把重要文字、logo、人物臉部全部放在畫面正中央的安全區，避開邊緣 15%，這樣不管怎麼裁主體都不會掉。如果你想知道 WordPress 端完整的圖片處理流程，WordPress 圖片優化步驟有更細的說明，搭配 Lazy Loading 延遲載入指南還能進一步顧到效能。
進階玩法：電商資訊卡式 OG 圖與多張預覽
OG 圖片不是只能放一張照片，它可以是任何你精心設計的圖。最值得借鏡的進階做法來自電商：例如蝦皮購物會用系統把產品圖、標題、價格、評價分數動態合成成一張資訊卡，當作 og:image，讓連結被分享時的預覽就自帶成交關鍵資訊。這不是特殊語法，而是系統在發布時即時合成的設計圖，把 OG 圖從單純的「縮圖」升級成「資訊卡」。
這個做法的核心觀念是：把價格、評價這些會直接影響購買決策的資訊塞進分享圖，讓消費者在看到連結預覽的當下就拿到做決定需要的資訊。如果你家也是電商，這個做法相當值得參考，等於把內容行銷與 CTA 行動呼籲直接搬進分享卡。對多語言電商來說，還要記得搭配 多語言網站的 hreflang 設定，確保不同語系的分享卡各自指向正確網址。
另一種進階玩法是設定多張 og:image，讓分享者自行挑選要呈現哪一張，這對圖片庫、攝影作品集這類頁面特別實用。不過對一般文章來說，一張精選圖就夠了。電商站如果想把社群帳號登入與分享一起串好，可參考 WooCommerce 社群登入與分享。
在 WordPress 裡，Rank Math 與 Yoast 幫你把 OG 標籤填完
WordPress 站長不需要手寫 meta 程式碼。安裝 Rank Math 或 Yoast 這類 SEO 外掛後，在文章編輯器的 Social 分頁就能分別預覽並指定 Facebook、Twitter 的 og:title、og:description 與 og:image，外掛會自動把標籤輸出到 head 區塊，設定完成後還能在編輯器內直接看到模擬的分享畫面（來源：Rank Math、Yoast 官方文件）。對不想碰程式碼的站長來說，這是最省事的路徑。
- 在 WordPress 後台安裝並啟用 Rank Math（免費版即提供 Social 預覽與 OG 欄位，完整流程可看 Rank Math 免費版完整教學）。
- 進入 Titles & Meta 分頁，確認文章與頁面的全域預設參數，外掛會自動帶入標題與描述。
- 打開要分享的單篇文章，找到 Rank Math 面板的 Social 分頁（或點 Edit Snippet）。
- 在 Facebook 預覽區分別填入 og:title、og:description，並上傳指定 og:image。
- 儲存後，外掛會把標籤輸出到 head；可再到偵錯工具驗證實際抓取結果。
Yoast SEO 的操作邏輯幾乎一樣，差別在欄位名稱與介面編排。Yoast 在編輯器下方有專屬的 Facebook 預覽與社群圖設定，能針對單篇文章覆寫社群標題與預覽圖，不一定要套用全站預設。兩款外掛的功能差異，可以對照 Yoast 與 Rank Math 功能比較與 WordPress SEO 外掛推薦清單再決定要用哪一套。如果你已經用 Rank Math 免費版夠用，想再往上則可評估 Rank Math Pro 進階功能教學。
用外掛設 OG 標籤最大的好處，是讓你可以針對每一篇文章分別客製社群文案，全站套用同一組的粗略做法可以被取代。例如同一篇文章，在 Google 搜尋結果用比較正式的標題，在 Facebook 分享時換成更有 CTA 感、更口語的版本，這對點擊率會有實質差異。Rank Math 與 Yoast 都還能設定 og:type、文章作者、發表時間等進階屬性，不過前面說過，有標題、描述、預覽圖三項就夠用了，進階屬性看需求再加。
如果你的站是用 WooCommerce 經營電商，商品頁的 OG 標籤更要認真設，因為商品圖與促銷文案直接影響社群導購轉換，可以參考 WooCommerce 商品頁 SEO 優化。而頁面編輯器層面的設定細節，WordPress 頁面編輯與 SEO 設定也有整理，建議與外掛設定一起看，才不會漏掉 head 輸出的環節。
OG 標籤偵錯工具：Meta Sharing Debugger 與 LinkedIn Post Inspector
社群分享預覽顯示錯誤或沒更新，該用什麼工具檢查？答案是兩款官方偵錯工具：Facebook 的 Meta Sharing Debugger 與 LinkedIn 的 Post Inspector。把網址貼進去就能看到平台實際讀到的 og 標籤、找出缺漏，修正後點「再次抓取」即可強制平台重新快取最新預覽。兩者使用前都需要登入對應的社群帳號（來源：Meta Sharing Debugger、LinkedIn Post Inspector 官方頁面）。
| 工具 | 支援平台 | 主要功能 | 能解決的問題 |
|---|---|---|---|
| Meta Sharing Debugger | Facebook、Messenger | 顯示標題、描述、預覽圖，列出「應處理的警告」 | OG 標籤缺漏、預覽停留在舊快取 |
| LinkedIn Post Inspector | LinkedIn（也接受網站、YouTube 連結） | 列出 og:title、og:image、og:author 等欄位 | LinkedIn 預覽錯誤、內容更新未同步 |
Meta Sharing Debugger 是 Facebook 提供的專業偵錯工具，可以檢查網站、YouTube 等連結分享到 Facebook 與 Messenger 上的狀況。貼上網址後，工具會顯示實際抓到的標題、描述、預覽圖，並把缺少或設定錯誤的標籤列在「應處理的警告」區，讓你一目了然哪裡要補。修正後回到同一頁點「再次抓取」，就能強制 Facebook 重新抓取，解決「明明改了圖，預覽卻還是舊的」這個最常見的快取問題。
這裡有個小提醒：「再次抓取」大約每 24 小時有次數限制，連續狂按可能短暫無效。如果你連按好幾次預覽都沒更新，先等一段時間再試，不要硬按。養成「改完 OG 跑一次偵錯工具就先停手」的節奏，反而更快看到結果。
LinkedIn Post Inspector 是 LinkedIn 官方的貼文檢查器，可接受任何類型連結，包括網站連結與 YouTube 影片連結。它會列出 og:title、og:image、og:author 等欄位，資訊相當完整，也能手動要求重新抓取。如果你主力經營 B2B 或專業社群，LinkedIn 的預覽品質會直接影響貼文的專業感，這個工具不能省。
那 LINE 呢？LINE 也有一個對應的 OG 檢查工具叫 Page Poker，使用方法跟 Meta Sharing Debugger 幾乎一樣。不過 Page Poker 長期處於不穩定、甚至離線的狀態，截至 2026 年 6 月仍無法可靠使用，所以目前檢查 LINE 分享預覽，最實際的做法還是直接在 LINE 裡貼一次連結看實際結果。要理解社群爬蟲與搜尋引擎爬蟲的差異，可對照 爬取預算與爬蟲抓取優化。
除了官方工具，瀏覽器開發者工具（F12）也是基本盤。在頁面上按 F12、切到 Elements，搜尋 og: 就能確認 head 裡的標籤是否正確輸出，這在排查「外掛到底有沒有把標籤送出來」時非常實用，整個檢視原始碼與除錯的流程可參考SEO 人必會的網頁開發者工具。搭配 Google Search Console 一起用，等於把搜尋端與社群端的驗證流程都顧到了；若還沒接觸過這套工具，先建立基本概念，再照著安裝步驟把站點串起來會更順。
缺少 fb:app_id 怎麼修：原因、影響與處理流程
用 Meta Sharing Debugger 檢查時，常會看到「缺少以下必要的屬性：fb:app_id」這條警告。fb:app_id 是讓 Facebook 把網頁與特定應用程式綁定、以便在開發者後台查看分享與互動數據的屬性。缺少它時，基本分享功能仍能運作，但你無法使用 Facebook Insights 分析，也無法正常整合 Like Button、Comments、Login 等社群外掛（來源：Meta for Developers 官方說明）。
這裡要釐清一個觀念：fb:app_id 不是 Open Graph 協議標準的一部分，而是 Facebook 專屬屬性，所以只會在 Meta 的工具跳出警告，LINE、LinkedIn 等其他平台不會管它。它對應的影響很明確：Debugger 出現警告、無法用 Facebook Insights 看分享數據、無法整合進階社群外掛。說實在的，如果你完全不在意 Facebook 的分析數據，這個警告可以直接忽略，分享卡一樣會正常顯示；但如果你有在用 Facebook Comments 或 Login 這類外掛，就建議處理掉，否則這些功能會綁定失敗。
- 到 Meta for Developers 申請 App ID。
- 在網頁
<head>嵌入<meta property="fb:app_id" content="你的ID">。 - 回 Meta Sharing Debugger 再次抓取，確認警告消失。
WordPress 用戶尤其方便，多半在 Rank Math 或 Yoast 的設定裡填一個欄位就搞定，不用碰程式碼。如果你的站是 WooCommerce 電商、想串接社群帳號登入，這個屬性更要設好，可參考 WooCommerce 社群登入與分享。
OG 預覽壞掉的高頻問題與排查順序
OG 預覽出問題時，把症狀對應到原因再開工，比逐項亂試省力。沒有預覽圖、預覽停在舊內容、圖被裁切這三類，加上標題被截斷與 og:url 帶錯參數，幾乎涵蓋實務排查的絕大多數情形。下方把症狀、典型原因與對應處理方式整理成一張對照表，逐項比對就能解掉八成以上的預覽災情。
| 症狀 | 典型原因 | 處理方式 |
|---|---|---|
| 沒有預覽圖 | og:image 網址錯誤、用了相對路徑，或圖小於 200×200 px | 確認網址為含 https 的絕對網址，圖放大到至少 600×315 px |
| 預覽不更新 | 平台快取未刷新 | 到 Meta Sharing Debugger 或 LinkedIn Post Inspector 貼網址並點再次抓取 |
| 圖被裁切 | 未照 1.91:1（FB/Twitter/LinkedIn）或 1:1（LINE）的比例製圖 | 把重要內容放正中央安全區，邊緣留白 |
| 標題描述被截斷 | og:title 過長 | 中文簡短有力、避免被砍尾；og:description 控制 1 到 2 句 |
| 按讚分享分散 | og:url 帶到 utm 參數 | og:url 一律用無參數的標準網址 |
「為什麼社群分享的預覽還是舊的圖？」這題出現頻率最高，答案九成是快取。Facebook 與 LinkedIn 都會把抓過的預覽快取起來，短則幾小時、長則數天不會主動重抓。所以你改完 og:image、整理好 head，不代表預覽會立刻變新，一定要手動到偵錯工具觸發再次抓取。養成「改完 OG 必跑一次偵錯工具」的習慣，能省下大量「為什麼還是舊的」的排查時間。
「沒有預覽圖怎麼辦」則通常出在兩種情境：一是 og:image 網址根本連不到（404、相對路徑、未上 HTTPS），二是圖小於 200×200 px 被爬蟲忽略。排查順序是先用瀏覽器直接打開那個圖片網址，確認能顯示、且是絕對網址，再確認尺寸過門檻。如果圖片放在 CDN 或有防盜鏈設定，也要記得放行社群爬蟲，否則爬蟲看得到網址卻抓不到圖。
結構面要提醒的是，OG 標籤設定完成後，最好同步檢查 Sitemap 產生與提交教學與 Google 網頁收錄查詢方法，確認內容本身有被搜尋引擎收錄。OG 顧的是社群預覽，收錄顧的是搜尋能見度，兩條線都要通，內容才會同時在社群與搜尋被看見。如果你也想顧到 GEO 生成式搜尋優化這條更新的線，記得 OG 標籤與 Schema 結構化資料是並存的，分別服務社群與搜尋引擎，不要互砍。
以一個月流量約數萬到十來萬的不等內容站為例，常見的狀況是文章累積到一定數量後，才會發現 OG 預覽的問題其實是系統性的，而非單篇文章出錯。這類站點很典型的表現幅度大約落在：全站文章跑一次 Meta Sharing Debugger 後，約有兩到三成會跳出某種警告，其中又以 og:image 缺漏或圖小於 200×200 px、og:url 帶到 utm 參數導致按讚分散這兩類佔最多，加起來通常佔警告總數的一半以上；另外一類常見的是改圖後忘記觸發再次抓取，社群預覽停留在舊版快取。換句話說，問題往往源自「某一篇沒設好」之外，更多是發布流程裡根本沒有把偵錯工具當成固定節點，舊文壞了沒人發現，新文又持續累積同樣的債。
依這類站點的典型表現來抓排查順序會比較省力。第一步是先抽樣十到二十篇文章各跑一次偵錯工具，把警告分類成「圖問題」「網址問題」「快取問題」三類，看看哪一類最集中，通常單一類型就佔了整批警告的六到七成；接著針對該類型回頭修正發布流程的對應環節，例如圖問題就回頭檢查預設範本是否用了相對路徑或圖壓得太小，網址問題就檢查外掛的全域 og:url 是否被誤掛參數。一個務實的決策角度是：與其逐篇救火，不如先修掉影響面最大的那一類，因為那通常源自同一個範本或外掛設定，修一處等於清掉一批。要誠實指出一個限制：抽樣排查能看到的是「有跳出警告的文章」，但那些根本沒設 og 標籤、Debugger 因此連警告都不會顯示的頁面，反而會被漏掉，這類隱性缺漏要靠 F12 逐頁確認 head 輸出才能補上，沒有捷徑。把偵錯工具加進發布前的檢查清單，跟 SEO 友善網站架構規劃、WordPress 永久連結設定一樣當成上架流程的一環，問題就會少很多。
用決策矩陣排優先順序：哪些 OG 設定該先做
站長資源有限，不可能一啟用就把 ogp.me 規範裡所有屬性都填滿。比較務實的做法是用兩個維度排優先順序：一個是「對點擊率的影響大小」，另一個是「實作成本高低」。把這兩個維度交叉，就能得到一張四象限的決策矩陣，照著做就能把力氣花在報酬最高的設定上。
| 象限 | 影響大、成本低（先做） | 影響大、成本高（規劃做） |
|---|---|---|
| 代表設定 | og:title、og:description、og:image、og:url | 動態合成的電商資訊卡、多張 og:image 條件輸出 |
| 建議動作 | 發布流程必設，外掛欄位填完即可 | 列入季度技術規劃，需要開發資源配合 |
| 象限 | 影響小、成本低（順手做） | 影響小、成本高（可不做） |
| 代表設定 | og:image:width、og:image:height、og:type | 為每個平台個別裁切專屬比例的預覽圖 |
| 建議動作 | 外掛有欄位就填，沒有也不影響預覽 | 投入產出比低，除非該平台是主要流量來源 |
這張矩陣的核心觀念是：四個核心標籤落在「影響大、成本低」象限，是任何站都不該跳過的基本盤；動態資訊卡與多圖條件輸出落在「影響大、成本高」象限，值得做但要排開發資源；至於 og:image:width 這類屬性落在「影響小、成本低」象限，順手填就好，沒填也不會讓預覽壞掉。把設定分成這三層來看待，就不會把寶貴的時間浪在邊際效益極低的進階屬性上。
OG 標籤發布前檢查清單
把偵錯工具加進發布流程，最有效的方式是固定一份檢查清單，每篇文章上架前照著走一遍。尺寸、網址、偵錯這些細節前面章節已分章說明，這裡只把上架當下要打勾的動作濃縮成一條流程：先確認四個核心標籤（og:title、og:description、og:image、og:url）齊全無空白；og:image 用 https 絕對網址、尺寸與大小落在前面表格的安全範圍內；og:url 為無 utm 參數的標準網址；圖中文字、logo、人物臉部放在正中央安全區避開邊緣 15%；接著把 Twitter Card 的 twitter:card、twitter:title、twitter:image 內容與 og 標籤對齊。
最後一步是驗證：Meta Sharing Debugger 與 LinkedIn Post Inspector 各跑一次，確認警告為零或可接受；若有改動 og:image 或 og:title，記得手動點過再次抓取，讓預覽顯示最新內容。這份清單可以剪進團隊的發布 SOP，跟文章校稿、圖片壓縮、網址檢查排在同一個流程節點。習慣建立後，OG 排查會從「出事了才救」變成「上架前就清乾淨」，長期下來能省下大量反覆除錯的時間。
OG 標籤與 Twitter Card 的分工與同時設定
OG 標籤與 Twitter Card（現在稱為 X Card）是兩套不同的社群預覽協議，但可以同時設、互不衝突。Open Graph 是 Facebook 提出的通用標準，被 LINE、LinkedIn 等多數平台採用；Twitter Card 則是 Twitter 自己的標記，用 twitter:card、twitter:title、twitter:image 等標籤控制推特上的預覽。實務上建議兩者都設，且內容保持一致，這樣不管連結被分享到哪個平台，預覽都不會失控。
兩者最大差異在「誰會讀它」。Facebook、LINE、LinkedIn 讀的是 og 標籤，Twitter/X 讀的是 twitter 標籤。如果你只設了 OG 標籤、沒設 Twitter Card，部分情況下 Twitter 會回退去讀 og 標籤當替代，但這不是穩定行為，正式做法還是兩套都設好。WordPress 的 Rank Math 與 Yoast 都能在同一個 Social 分頁同時輸出兩套標籤，等於填一次欄位就能覆蓋兩個生態。
另一個值得知道的差異是尺寸。Twitter Card 的 summary_large_image 類型同樣建議 1200×630 px，跟 og:image 一致，所以你只要準備一張圖就能兩邊通用。如果你想更深入了解 Twitter 生態的分享整合，WordPress 社群分享整合有更完整的工具比較。電商站若用到社群登入與分享，WooCommerce 的社群登入外掛也值得一看；若想用短網址讓社群連結更乾淨，或想在網站上推播最新文章帶動社群導流，都是可搭配的延伸方向。
常見問題：OG 標籤 FAQ
以下是站長最常問、且答案需要獨立說明的幾個問題，以 FAQPage 結構化資料呈現，方便搜尋引擎與 AI 直接引用。其他如尺寸門檻、偵錯流程、og:url 參數處理等細節，前面章節已完整說明，此處不重複。
沒有 OG 標籤會怎樣？
不會被搜尋引擎懲罰，但社群預覽會失控。爬蟲只能隨機抓取頁面上的文字與圖片，可能抓到無關內容或完全沒有預覽圖，點擊率明顯下滑。
og:title 跟一般 meta title 有什麼不同？
作用對象不同。meta title 是給搜尋引擎與瀏覽器分頁看的，og:title 是給社群平台爬蟲讀的。建議兩者內容一致，但 og:title 可以針對社群情境微調，寫得更口語、更有 CTA 感，並維持簡潔避免在預覽中被截斷。
OG 標籤跟 Twitter Card 差在哪？
Open Graph 是 Facebook 提出、被多數平台採用的通用標準；Twitter Card 是 Twitter 自己的標記。兩者可同時設、互不衝突，建議內容保持一致，WordPress 的 Rank Math 與 Yoast 可在同一分頁同時輸出兩套標籤。
OG 標籤是什麼？
OG 標籤是放在網頁 head 區塊的 meta 標籤，用來指定連結在社群平台分享時顯示的標題、描述、預覽圖與網址，讓站長主動控制社群預覽長相，而非交由爬蟲隨機抓取。
og:image 建議尺寸是多少？
建議 1200×630 px、長寬比 1.91:1，格式用 JPG 或 PNG，檔案小於 8 MB。這是 Facebook、Twitter、LinkedIn 通用的尺寸，能確保在高解析度裝置上顯示最佳。
回到核心：四個核心標籤設好、og:image 守在 1200×630 px、og:url 用乾淨標準網址，再配合 Meta Sharing Debugger 或 LinkedIn Post Inspector 跑一次重新抓取，OG 標籤這一塊就算處理完了。它的報酬落在社群點擊率與推薦流量，不在搜尋排名，把它當成內容發布流程裡的一個固定步驟就好。要把社群與搜尋兩條線一起拉起來，可再回頭補上 網站跳出率與 SEO 關係與 SEO 網址優化指南，把網址結構理清，發布流程才不會漏掉任何一環。