OG 標籤教學：Open Graph 設定、圖片與社群優化

其實不少人都遇過這種情況：花了一整週寫出一篇自認為今年最紮實的文章，上架後興奮地把連結貼進 LINE 群組、丟到 Facebook 粉專，結果跳出來的分享卡不是圖片一片空白，就是僅剩半張、裁掉重點。讀者連點都還沒點進去，視覺印象就已經先打了折扣。

問題多半出在網頁少了正確的 Open Graph 標籤（簡稱 OG 標籤）設定。OG 標籤是一組寫在 HTML <head> 裡的 meta 後設資料，告訴支援這套協定的平台「這個網址被分享時要顯示什麼標題、描述與圖片」。不同平台實際讀取的欄位與呈現規則不完全相同，但 Open Graph 已是常見的連結預覽基礎（ogp.me 的〈Open Graph protocol〉官方規範）。

重點先看：OG 標籤提供連結預覽資料，平台仍決定實際呈現。1200×630 可作製圖起點，但不是 OG 協定規定的唯一尺寸或跨平台不裁切保證。發布前應確認原始 HTML、圖片存取與實際預覽；平台沒有重抓工具時，不能假設加參數一定能清快取。

分享卡如何影響讀者對連結的理解

標題、圖片與描述能幫助讀者判斷連結內容。預覽不完整可能增加理解成本，但曝光次數、點擊與轉發仍取決於平台與受眾，不能斷言卡片被滑過就再也沒有第二次曝光。

OG 標籤不會讓你從第五名跳到第三名，但能讓每一次分享都有較完整、可控的預覽。分享卡是否清楚，可能影響讀者願不願意點擊；實際差異仍要看平台、受眾、文案與內容本身。把 CTR 的檢查延伸到社群分享，可以和 點閱率優化 一起看。

支援連結預覽的協作與通訊工具也可能讀取 OG 標籤，因此它不僅用在公開社群。不過，不能進一步推論 ChatGPT、AI Overviews 或其他 AI 搜尋功能一定用 OG 標籤決定引用與縮圖。Google 明確說明，AI 搜尋功能沒有需要額外加入的特殊標記；一般 SEO 基礎與可被索引的內容才是前提。OG 的可靠定位仍是管理支援平台上的連結預覽，這點在 Google 的〈Google Search 的 AI 功能與網站〉說明中也有印證。

Open Graph 是什麼：從 HTML 一行 meta，到社群上一張卡片

Open Graph 的運作機制換句話說，很直白：你在網頁 <head> 裡用 <meta property="og:..."> 寫好後設資料，當有人在社群平台貼上你的網址，平台派出的爬蟲（crawler）就會去抓這頁的 HTML，讀出 og:title、og:image 這些欄位，再依自己的版型組合成你看到的那張分享卡。整個流程跟你平常理解的 技術性 SEO 裡 Googlebot 抓網頁的邏輯是同一套，僅是這次爬蟲是 Facebook、LINE、X 的。

OG 資料與可見 H1、文章圖片、HTML title 是不同欄位。平台可能在缺少 OG 時採用其他內容，例如 LINE 會回退到 title 或頁面描述；設定 OG 能表達預期值，卻不能強制平台完全照用。

命名上還有一個小坑。OG 規範使用 property 屬性（<meta property="og:title">），不要自行改成 name；這是 ogp.me〈Open Graph protocol〉規範的寫法。如果你用的是 WordPress 搭配主流 SEO 外掛，這段 HTML 通常會自動產生，你若在後台填欄位即可。

四個必要屬性，加上三個常用 OG 標籤

依 ogp.me 規範，基本中繼資料的必要屬性是 og:title、og:type、og:image、og:url。內容網站通常還會加入 og:description、og:site_name 與 og:locale，但它們不是基本規範的必要屬性。

og:description 可以比 meta description 更口語、直接，把文章能解決的問題放在前面。各平台顯示長度與截斷方式不同，沒有一個通用的 60 到 200 字保證值；先用短而完整的句子表達核心即可。og:site_name 使用品牌顯示名稱，不要塞網址或關鍵字。

當 og:type 設成 article，可以額外提供 article:published_time、article:modified_time、article:author 等文章屬性，讓支援的平台取得發布脈絡。時間使用含時區的 ISO 8601 格式，例如 2026-07-12T09:00:00+08:00。Article 結構化資料與 Open Graph 是不同系統；Google 的 Article 文件目前沒有 required properties，若有提供日期，仍應使用正確格式與真實值。

Meta 平台另有一個選配標籤 fb:app_id。它跟分享卡的長相無關，用途是把網站關聯到你的 Facebook 應用程式，藉此解鎖 Facebook Insights、查看來自 Facebook 的流量分析；沒有這個需求的網站可以不加（依 Meta 的網站分享標籤文件）。

og:url 是圖譜物件的標準網址與識別值，宜與canonical所選的內容正本一致。但它不是搜尋 canonical 標記的替代品，也不能保證所有平台把讚、留言或點閱數合併；例如 LINE 官方只列出三個用於預覽的 OG 欄位。

og:image 建議使用可公開抓取的完整 HTTPS 絕對網址，減少不同平台解析相對路徑的差異。不能一概說每個爬蟲都不會解析相對網址；跨平台驗收仍應檢查最終回應、格式與存取限制。這也與圖片 SEO的穩定路徑管理相關。

若你用程式動態產生 og:image，例如依文章標題即時合成圖檔，還要記得 Meta 的圖片快取規則：圖片以網址為單位快取，換圖就必須換網址（新檔名或版本參數）；只置換網址背後的圖檔內容、網址維持不變，平台會繼續讀舊快取（依 Meta 對圖片快取的說明）。動態產圖的流程因此要從一開始就設計可版本化的圖片網址。

OG 圖片尺寸的真相：1200×630 僅是一個起點

1200×630、約 1.91:1 可作本文的橫式製圖基準，但 OG 協定本身沒有規定統一尺寸。各平台可能依卡片類型、裝置與介面版本裁切，仍需對目標平台測試。

同一圖片在不同卡片與裝置上可能使用不同版型。不要把某次看到的 Facebook、LINE 或 X 裁切比例當作永遠適用的規則；文字、人臉與品牌圖樣應留出四周餘裕，再用實際預覽檢查。

中央集中主體是製圖上的取捨，不是通用安全區規格。只留上下 90 像素無法防止左右裁切，也沒有一塊固定區域能保證所有平台不裁圖；應檢查橫式與較接近方形的預覽。

製作流程上，建議幫全站準備一個固定的 OG 圖模板，避免每篇文章都從零設計。模板的好處是品牌一致性：固定的 logo 位置、固定的字體級距、固定的配色，讀者在訊息流裡一眼就能認出「這是誰家的內容」。工具方面，Canva、Figma 都很適合做這類模板，把標題文字設成可替換的變數，每篇新文章若換文字、換一張背景圖就能產出。這層「模板化」的投資做一次受用很久，跟你建立圖片 SEO 標準化作業流程是同一個道理，差別僅在 OG 圖是給社群爬蟲看的，而圖片 SEO 是給 Google 圖片搜尋看的。

顏色與對比也有講究。分享卡在訊息流裡通常被白底或深色底包圍，OG 圖本身的對比要夠強，標題文字才不會糊掉。深色背景配白字、或淺色背景配深色字，是最保險的組合；避免用低對比的灰配灰、或把細字體放在複雜背景圖上。字體也要選粗壯一點的字型，太細的襯線字縮成手機縮圖後幾乎看不見。這些設計細節看似瑣碎，累積起來就是「別人分享卡看起來專業、你的看起來隨便」的差距來源。

檔案大小是另一個常被略過的細節。OG 規範沒有通用的 300KB 上限，各平台也可能有不同限制；實務上應在不明顯犧牲畫質的前提下壓縮圖片，並確認爬蟲可公開存取。圖片網址使用穩定的 HTTPS 絕對網址，能避免混合內容與重新導向造成的抓取問題。圖片壓縮可搭配 圖片優化 一起處理。

可加入 og:image:width、og:image:height 表明真實尺寸，並依 OG 規範提供描述圖片內容的 og:image:alt。這些資料方便平台解析，但不能保證消除分享卡重排或固定加快顯示；輸出後仍需核對實際值。

底下這張表是實務上常用的尺寸速查，給你做參考。

台灣情境：LINE 的分享預覽為什麼特別折磨人

台灣網站常需要特別檢查 LINE 分享預覽。LINE 官方 FAQ 說明，網址預覽會使用 og:title、og:description、og:image；缺少時才會嘗試從頁面其他內容取得資料（見 LINE Developers FAQ）。

圖片應放在不需登入、沒有 robots 或防火牆阻擋的公開網址，並使用 HTTPS。是否使用自有網域不是 LINE 公開規範的必要條件，真正要驗證的是 LINE 爬蟲能否取得檔案。

修改後若 LINE 仍顯示舊預覽，先核對公開 HTML 與圖片是否已更新，再以實際分享確認。LINE FAQ 沒有提供可承諾更新時間或清除快取的流程；查詢參數只能作診斷測試，不能保證重抓，測完也不應留下大量分享網址變體。

LINE 的縮圖應以實際裝置檢查，而非假定固定為螢幕寬度一半。可把設計縮小到預期顯示尺寸，確認重點仍可辨識；字級與版型由測試結果決定。

台灣受眾若常用 LINE，可將它列入社群媒體行銷的分享驗收流程。哪個平台帶來較穩定流量，應看自己的追蹤資料，不能直接斷言 LINE 優於 Facebook。

Twitter Card 與 OG 可分別設定

X 的卡片使用 twitter: 標記，與 OG 是不同的標記系統。網站可同時輸出兩者，若希望資料明確，可一併提供 twitter:title、twitter:description 與 twitter:image；不要把它理解成只能依賴 OG 的裝修層。

若要表達大圖卡片偏好，常見設定如下。這是輸出偏好，不是平台必定顯示某種版型的保證：

<meta name="twitter:card" content="summary_large_image">

summary_large_image 用來表達大圖卡片類型；圖片仍須能被平台取得。twitter:site 與 twitter:creator 用於網站或作者識別，不能描述成 SEO 加分項。發布後請檢查實際 X 預覽，不要只看模板有沒有這一行。

維護時可從同一份標題、描述與圖片資料產生 OG 和 Twitter Card，減少彼此矛盾。OG 四個基本必要屬性與常用補充資料要分開檢查，並依平台驗收。

三種設定 OG 標籤的技術路線

設定 OG 標籤的方法不僅一種，依你網站的技術棧不同，最順手的路線也不同。底下三種是實務上最常見的，你挑跟你現況最接近的那個就好。

路線一：手寫 HTML head

如果你是用純靜態 HTML、或是自己刻前端的網站，最直接的方式就是在每一頁的 <head> 裡手動寫入 <meta property="og:...">。優點是控制力最強、沒有任何外掛的包袱；缺點是每篇文章都要手動改，一旦圖片換了、標題改了，就得記得同步更新 head 裡的對應欄位，容易漏。這條路線適合頁面數量少、且你有工程能力能維護的人。

路線二：WordPress SEO 外掛

若網站使用 WordPress，主流 SEO 外掛通常都能自動產生 OG 標籤。文章編輯畫面的「社群」分頁一般可單獨設定 Facebook 與 X 的分享標題、描述與圖片，外掛再將對應的 og: 與 twitter: 標籤輸出到頁面 head。欄位名稱與預設行為會隨外掛版本不同，上線前仍要檢查實際原始碼。這是對非工程背景較友善的路線。

實際填寫時，不要完全依賴外掛抓取預設值。預設值多半會沿用頁面的 <title> 與 meta description，但社群標題與搜尋標題的任務不同，直接套用未必合適。圖片也應手動確認，避免抓到文章內不適合當分享卡的第一張圖。這套填寫紀律跟你做 WordPress SEO 基礎設定 時逐項檢查的精神是一致的。

有些佈景主題或社群分享外掛也會輸出 OG，應避免不同工具產生相互矛盾的 title、url 等值。OG 規範允許多張 og:image，這本身不是錯誤，重點是順序與其後尺寸、alt 是否正確配對。可用瀏覽器開發者工具（F12）檢查，再確認伺服器原始 HTML 已包含資料。

路線三：Headless CMS 與程式化產生

Astro、Next.js 搭配 Headless CMS 時，可在模板中產生 OG。資料要出現在平台實際抓到的 HTML，不要假設每個社群爬蟲都會執行前端 JavaScript。圖片可使用 CDN，但網址須穩定且能回傳平台支援的格式；<picture> 不會控制 OG 爬蟲對 og:image 的請求。

預覽壞掉怎麼辦：三個偵錯位置與快取那件事

OG 預覽出問題時，常見原因包括快取、爬蟲無法存取、標籤重複與圖片格式不符。平台通常會快取抓取結果，修改後未必立即更新。下面依序檢查三個位置，通常就能定位問題。

Facebook 可使用官方 Sharing Debugger 檢查抓取資料，並在工具可用時要求重抓。工具可能需要登入或受到存取限制；重新抓取也不能保證所有舊貼文立即改變。

第二個是直接用瀏覽器檢視原始碼。在頁面按右鍵「檢視網頁原始碼」，搜尋 og:，確認實際輸出的標籤、圖片網址與重複項目。第三個是到目標平台做實際分享測試，因為第三方模擬器不一定能重現平台當下的抓取與裁切規則。

先確認公開來源 HTML 與圖檔已更新，必要時清除網站和 CDN 的相關快取，再使用平台提供的重抓功能。沒有公開重抓方式時，只能實測與等待平台更新，不要把網站端清快取等同於社群端清快取。

例如網站已換新封面，平台仍顯示舊圖，就可以比較原始碼、圖片回應與平台最近抓取資訊。若來源與 CDN 都已更新，平台快取是可能原因之一；也要檢查存取失敗、圖片格式與網址重複，不能保證點一次重抓幾秒內就修復。

網站可能同時有 CDN、網站快取與社群平台快取。修改後先確認來源 HTML 與圖片已更新，再依序清除網站與 CDN 的相關網址快取，最終讓支援重抓的社群平台重新抓取。這樣能分清楚舊資料停在哪一層。

OG 標籤到底算不算 SEO

Google 沒有公開把 OG 當作通用排名加分，但官方明確列出 og:title 是產生搜尋標題連結時可能參考的來源之一。這與保證採用標題或提高排名不同，仍應使它與可見內容一致。

OG 的價值主要在分享體驗：完整的預覽可能增加社群點擊，也可能讓內容得到更多曝光與自然連結，但這些都是後續效果，不是 OG 本身帶來的排名加成。AI 搜尋是否採用 OG 標題或圖片，也不能一概而論；若要理解 AI Overviews 的公開技術要求，可看 Google AI Overviews。

OG 與 結構化資料 是不同規範，但用途有交集：Google 可參考 og:title 產生標題連結，也可用 og:image 或適當 Schema.org 圖片欄位判斷偏好預覽圖。兩者仍不能互相取代；例如單獨設定 og:image 不會取得評分豐富結果資格。應讓各欄位與頁面內容一致，並分別驗證目標功能。

og:url 與 canonical 理想上應指向同一個正本網址。兩者不一致不等於會受到「重複內容處罰」，但會讓社群互動歸屬與搜尋正規化訊號不一致。重新規劃 站內 SEO 時值得一起對齊。

六個最常見的 OG 踩坑，你中過幾個

教學看了再多，真正上線時會犯的錯就那幾種。以下整理出台灣內容網站最常踩的六個地雷，每一個都附上正確做法，你可以拿來對照自己的網站。其中相對路徑這個坑特別容易卡關，常讓人花上一整個下午才搞懂為什麼 Facebook 抓得到圖、LINE 卻空白。

原始碼與網路回應可找出部分設定問題，實際平台分享則能驗證呈現與裁切。兩種檢查互補，後台預覽與第三方模擬器不能保證完全重現平台結果。

使用UTM 追蹤碼時，可在實際分享連結加上行銷參數，並讓 og:url 與 canonical 保持內容正本。分析工具是否取得參數仍要實測；平台是否合併互動紀錄由自身規則決定，不能用 og:url 保證跨平台統一統計。

把 OG 預覽檢查寫進發布流程的方法

實務上常見的情況是，OG 預覽的問題很少出在某一篇文章沒寫好，多半是發布流程根本沒有把偵錯這一步放進去。內容上架前，沒有人實際把連結貼進 LINE、Facebook 驗收過，壞掉也沒人發現，等讀者在群組裡截圖回報「你們圖片壞掉了」才驚覺。補救的成本，遠高於發布前多花兩分鐘檢查。

建議固定做一輪「上架前預覽檢查」，在每次文章發布前跑一遍。流程很簡單。

1. 看原始碼：核對 og:title、og:type、og:image、og:url 四個必要屬性，補上適合的 description 與圖片 alt。避免矛盾輸出；若有多張圖片，確認順序與尺寸等欄位配對。
2. 開圖檔：把 og:image 的網址直接貼到瀏覽器網址列，確認圖片可公開開啟、尺寸符合設計，檔案也經過合理壓縮。
3. 跑偵錯工具：用 Meta Sharing Debugger 檢查 Meta 抓到的資料，再到其他目標平台實際分享，確認圖沒被裁掉重點、標題沒有亂碼。
4. 實機驗收：把連結貼進你目標讀者最常用的那個管道（台灣多半是 LINE 群組），用另一支手機、另一個帳號實際看一次縮圖長相。這步最花時間，但也最能反映真實情況。
5. 保留更新驗證步驟：先確認來源和 CDN，平台支援時再要求重抓；沒有公開重抓工具的服務不保證立即更新。

這份清單看起來平凡，它的價值不在於技巧多高深，而在於「每一次發布都確實執行」。SEO 與社群優化裡，真正拉開差距的常常不是某個神操作，而是這種紀律性的檢查有沒有變成 SOP。

下一步：把你流量最高的那篇文章拿來試

可先選一篇經常被分享的文章，依下列步驟檢查。完成設定不保證半小時內各平台就更新，應記錄實際抓取與預覽結果。

1. 盤點現況：打開那篇文章，檢視原始碼搜尋 og:，先確認四個必要屬性，再檢查常用補充標籤與圖片網址。
2. 補齊缺漏：修正必要標籤、圖片絕對網址與 alt，依目標平台規劃尺寸和構圖，實測是否裁掉重點。
3. 驗收分享卡：用 Meta Sharing Debugger 與目標平台的實際分享測試，修正裁切或破圖問題。
4. 正式分享觀察：把連結貼進平常經營的社群管道，追蹤接下來一週的點閱數變化，判斷修改是否真的有效。

OG 標籤不會讓你一夜衝上 Google 首頁，但能讓內容被分享時，以完整、可控的預覽面對讀者。把這個基本功與發布前驗收做好，就能少掉許多破圖、錯標題與舊快取問題。