OG 標籤教學：Open Graph 設定、圖片與社群優化
OG 標籤決定連結分享到 Facebook、LINE、LinkedIn 時的標題、描述與預覽圖，直接影響社群點擊率。完整教學涵蓋七個核心標籤、og:image 1200×630 尺寸規範、Rank Math 與 Yoast 設定及 Meta Sharing Debugger 偵錯工具排查。
作者：褚崇名（Sliven）
本頁目錄
- 為什麼一張分享卡，會決定一篇文章的生死
- Open Graph 是什麼：從 HTML 一行 meta，到社群上一張卡片
- 四個必要屬性，加上三個常用 OG 標籤
- OG 圖片尺寸的真相：1200×630 僅是一個起點
- 台灣情境：LINE 的分享預覽為什麼特別折磨人
- Twitter Card 不是另一套系統，是 OG 的延伸
- 三種設定 OG 標籤的技術路線
- 路線一：手寫 HTML head
- 路線二：WordPress SEO 外掛
- 路線三：Headless CMS 與程式化產生
- 預覽壞掉怎麼辦：三個偵錯位置與快取那件事
- OG 標籤到底算不算 SEO
- 六個最常見的 OG 踩坑，你中過幾個
- 把 OG 預覽檢查寫進發布流程的方法
- 下一步：把你流量最高的那篇文章拿來試
其實不少人都遇過這種情況：花了一整週寫出一篇自認為今年最紮實的文章，上架後興奮地把連結貼進 LINE 群組、丟到 Facebook 粉專，結果跳出來的分享卡不是圖片一片空白，就是僅剩半張、裁掉重點。讀者連點都還沒點進去，視覺印象就已經先打了折扣。
問題多半出在網頁少了正確的 Open Graph 標籤（簡稱 OG 標籤）設定。OG 標籤是一組寫在 HTML <head> 裡的 meta 後設資料，告訴支援這套協定的平台「這個網址被分享時要顯示什麼標題、描述與圖片」。不同平台實際讀取的欄位與呈現規則不完全相同，但 Open Graph 已是常見的連結預覽基礎（ogp.me 的〈Open Graph protocol〉官方規範）。
重點先看：OG 標籤控制的是「被分享時的長相」，不是直接的 Google 排名因素，卻會實際影響點閱率、品牌印象與被轉發的機率。圖片用 1200×630 當基準，重要內容留在中央 安全區避免被裁切。LINE、Facebook、X 各有快取機制，預覽壞掉時要先清的是平台端快取，不是僅改你自己的網頁。把「分享預覽檢查」變成發布前的固定步驟，比事後補救有效太多。
為什麼一張分享卡，會決定一篇文章的生死
分享卡片這件事，本質上就是搜尋結果頁（SERP）藍色連結的社群版本。在 Google 搜尋結果上，標題、網址、描述那段預覽決定了使用者要不要點；到了社群平台，換成標題、圖片、描述組成的分享卡來扮演同一個角色。差別在於，搜尋引擎的點閱率（CTR）你還能用排名位置去彌補，社群訊息流裡的分享卡一旦滑過去就是滑過去，連第二次曝光的機會都沒有。
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 標籤跟你網頁上「看得到」的標題、封面圖是兩回事。你的文章標題（<title> 標籤或 H1）寫得多漂亮，都不會自動變成分享卡的標題，除非你用 og:title 明確指定；你文章內文第一張圖再好看，平台也不一定會挑它，常常會抓到一張無關的側欄圖、甚至 logo。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，若有提供日期，仍應使用正確格式與真實值。
| 標籤 | 作用 | 填寫重點 |
|---|---|---|
og:title | 分享卡的標題 | 建議與 <title> 一致或更口語；避免重複網站名稱 |
og:description | 標題下方那段文字 | 核心訊息放前面，實際截斷長度依平台而異 |
og:image | 分享卡的主圖 | 指定絕對網址（含 https://），建議 1200×630 |
og:url | 這頁的標準網址 | 填你想被當作「正本」的網址，與 canonical 一致 |
og:type | 內容類型 | 文章用 article；首頁用 website |
og:site_name | 整站名稱 | 品牌名，例如「Whoops SEO」 |
og:locale | 語言地區 | 繁體中文填 zh_TW |
這裡面 og:url 最容易被忽略，也最容易出問題。它的作用跟 canonical 幾乎一樣：當同一份內容有多個網址（例如有追蹤參數、有手機版網址、有快取副本），og:url 告訴平台「不管你從哪個網址抓到的，正本是這一個」。平台會把所有分享的互動數據，例如讚、留言、點閱，集中歸到 og:url 指定的那個正本網址上。你不在意，數據就分散到一堆變體網址，每一個都僅有零星互動。
og:image 則是另一個地雷區，後面會專門拉一節來講尺寸。這裡先記一個原則：圖片網址一定要是完整的絕對網址（包含 https:// 與你的網域），不能寫成 /images/cover.jpg 這種相對路徑。平台的爬蟲不會幫你補網域，相對路徑在它眼裡就是一個抓不到的破圖。這點跟 圖片 SEO 裡強調圖檔命名、路徑穩定的道理是一致的。
OG 圖片尺寸的真相：1200×630 僅是一個起點
講到 OG 圖片，網路上最常被複誦的一句話就是「1200×630」。這個數字沒有錯，它是 Facebook 在文件裡建議的標準尺寸，比例是 1.91:1，能同時滿足 Facebook、LinkedIn 大部分的呈現需求（依 Meta for Developers 的〈Sharing for Websites〉文件）。但「能用」跟「在每個平台都好看」是兩回事。真正會讓你頭痛的是裁切問題。
問題出在每個平台渲染分享卡時，會依自己的版型把同一張圖裁成不同比例。Facebook 在桌機版可能顯示接近 1.91:1，在手機版卻常常裁成接近正方形；X 的 large image 卡片用接近 2:1 的比例；LINE 在聊天室裡的縮圖更小、更接近 1.91:1 但會被邊框再切一次。同一張 1200×630 的圖，在不同平台被裁掉的部分都不一樣。如果你把標題文字、人臉、logo 放在圖片的上下邊緣，在某個平台上就會被切掉一半。
處理 OG 圖時，實務上會遵守一個「安全區」原則：把 1200×630 的畫布想像成一個相框，所有重要元素（標題、品牌、主角）都放在中央約 1200×450 的區塊內，上下各留 90 像素的緩衝。這塊緩衝就算被裁掉也不影響訊息傳遞。實務上比追求某個「完美尺寸」更管用，因為平台的顯示規則一直在變，但你控制「重要內容放中間」這件事永遠有效。
製作流程上，建議幫全站準備一個固定的 OG 圖模板，避免每篇文章都從零設計。模板的好處是品牌一致性：固定的 logo 位置、固定的字體級距、固定的配色，讀者在訊息流裡一眼就能認出「這是誰家的內容」。工具方面，Canva、Figma 都很適合做這類模板，把標題文字設成可替換的變數，每篇新文章若換文字、換一張背景圖就能產出。這層「模板化」的投資做一次受用很久，跟你建立圖片 SEO 標準化作業流程是同一個道理，差別僅在 OG 圖是給社群爬蟲看的，而圖片 SEO 是給 Google 圖片搜尋看的。
顏色與對比也有講究。分享卡在訊息流裡通常被白底或深色底包圍，OG 圖本身的對比要夠強，標題文字才不會糊掉。深色背景配白字、或淺色背景配深色字，是最保險的組合；避免用低對比的灰配灰、或把細字體放在複雜背景圖上。字體也要選粗壯一點的字型，太細的襯線字縮成手機縮圖後幾乎看不見。這些設計細節看似瑣碎，累積起來就是「別人分享卡看起來專業、你的看起來隨便」的差距來源。
檔案大小是另一個常被略過的細節。OG 規範沒有通用的 300KB 上限，各平台也可能有不同限制；實務上應在不明顯犧牲畫質的前提下壓縮圖片，並確認爬蟲可公開存取。圖片網址使用穩定的 HTTPS 絕對網址，能避免混合內容與重新導向造成的抓取問題。圖片壓縮可搭配 圖片優化 一起處理。
順帶提一個進階但低成本的小技巧：搭配 og:image:width 與 og:image:height 這兩個輔助標籤。它們的用途是直接告訴平台爬蟲圖片的寬高，平台就不必先下載整張圖才能算出尺寸，能更快把分享卡版型排好。對用戶體驗的好處是減少分享卡渲染時的跳動與重排（reflow），尤其在網速較慢的手機環境上更明顯。設定上沒有難度，就是兩行 meta，把圖片的實際像素填進去就好。多數主流 SEO 外掛在你上傳 OG 圖時會自動帶入這兩個值，不需要手動量像素。這個細節不會讓你的分享卡變漂亮，但會讓它變穩定、變快，是那種做了沒人稱讚、沒做卻會偶爾出事的隱形基本功。
底下這張表是實務上常用的尺寸速查，給你做參考。
| 用途 | 建議尺寸 | 比例 | 備註 |
|---|---|---|---|
| 通用 OG 主圖 | 1200×630 | 1.91:1 | Facebook、LinkedIn 通用基準 |
| 正方形版本 | 1200×1200 | 1:1 | 手機版裁切、Instagram 連播較安全 |
| X 大圖卡片 | 1200×600 | 2:1 | 搭配 twitter:card=summary_large_image |
| 小尺寸備用圖 | 依目標平台文件 | 依平台 | 發布前以實際預覽驗收 |
| 檔案大小 | 沒有跨平台統一上限 | 不適用 | 兼顧清晰度、傳輸與可存取性 |
台灣情境：LINE 的分享預覽為什麼特別折磨人
台灣網站常需要特別檢查 LINE 分享預覽。LINE 官方 FAQ 說明，網址預覽會使用 og:title、og:description、og:image；缺少時才會嘗試從頁面其他內容取得資料（見 LINE Developers FAQ）。
圖片應放在不需登入、沒有 robots 或防火牆阻擋的公開網址，並使用 HTTPS。是否使用自有網域不是 LINE 公開規範的必要條件，真正要驗證的是 LINE 爬蟲能否取得檔案。
LINE 會快取連結預覽，修改標籤後不一定立即更新，而且目前沒有像 Meta Sharing Debugger 那樣的公開重抓工具。正式發布前應先用測試網址驗收；若不得不用查詢參數測試，記得讓 canonical 與正式分享網址策略保持一致，避免把測試參數長期當成不同內容版本。
第三個差異是縮圖裁切。LINE 在聊天室裡顯示的分享縮圖比你想像的小，大概是手機螢幕寬度的一半左右，而且是接近 1.91:1 再被裁一次。這代表你圖片上的字不能太小，否則在手機上根本看不清楚。實務上的習慣是 OG 圖上的標題文字至少要大到「整張圖縮成 200 像素寬時還能辨識」的程度。這個尺度感多做幾次就能抓到。
把這些 LINE 特性搞懂，對台灣網站的社群導流幫助很大。畢竟對很多本地商家來說，一篇被轉進 LINE 群組的文章，帶來的流量往往比 Facebook 粉專貼文還穩定，這跟 社群媒體行銷 裡強調「依平台特性分眾」的邏輯是相通的。
Twitter Card 不是另一套系統，是 OG 的延伸
很多人以為要在 X（Twitter）上顯示漂亮的分享卡，就得額外學一套叫 Twitter Card 的標籤，等於工作量大一倍。其實不是。Twitter Card 的標籤（twitter:card、twitter:title、twitter:image 等）存在的目的，是讓你對 X 上的呈現做「額外微調」，前提是你已經有 OG 打好的底子。X 的官方文件明說：當它找不到對應的 twitter 標籤時，會回頭去讀你的 Open Graph 標籤當作Fallback，這是 X Developer Platform〈Cards〉文件明載的行為。
換句話說，你把 og:title、og:description、og:image 寫好，X 上就已經能顯示一張基本的分享卡了。真正需要你「額外」加的，通常僅有一行：
<meta name="twitter:card" content="summary_large_image">
這行的意義是告訴 X「我要用大圖卡片，請用滿版圖片取代預設的小縮圖版型」。少了它，X 可能會用小縮圖版型，圖片存在但存在感很弱。加這一行，就能從小縮圖升級成滿版大圖，是 CP 值最高的一個 twitter 標籤。其他像 twitter:site（填你品牌的 @ 帳號）、twitter:creator（填作者帳號）有填加分，沒填也不影響圖片顯示。
這樣你看下來會發現一個原則：Open Graph 是地基，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 基礎設定 時逐項檢查的精神是一致的。
用外掛有一個要特別注意的陷阱：重複輸出。有些佈景主題（theme）或社群分享外掛本身也會輸出 og 標籤，跟你裝的 SEO 外掛打架，結果同一頁的 head 裡出現兩組 og:title、兩組 og:image，平台爬蟲讀到兩個矛盾訊號，輕則顯示非預期的版本，重則整張卡壞掉。裝好外掛後，務必要實際打開 瀏覽器開發者工具（F12），檢查 head 裡每個 og 標籤是不是僅出現一次。
路線三：Headless CMS 與程式化產生
如果你是用 Astro、Next.js 這類現代框架搭配 Headless CMS（例如 Sanity、Contentful），那 OG 標籤通常是在前端框架的 layout 裡用程式產生的。把文章的標題、描述、封面圖欄位從 CMS 讀進來，在 <head> 模板裡組合成對應的 meta 標籤輸出。好處是全站一致、不會漏；要小心的是圖片網址的組裝邏輯，務必確保輸出的是完整絕對網址，而且 CDN 網域跟主網域的對應關係正確，否則破圖的排查會比傳統 WordPress 麻煩。另一個常見的坑是圖片經過 CDN 處理後被自動轉成 WebP 或改了網址參數，導致平台爬蟲抓到的網址跟你在 og:image 裡寫的不一致。穩當的做法是把 og:image 指向一個穩定不變的網址，把格式轉換交給 <picture> 元素或前端邏輯去處理，不要讓 og:image 的網址跟著 CDN 的優化流程變動。
預覽壞掉怎麼辦：三個偵錯位置與快取那件事
OG 預覽出問題時，常見原因包括快取、爬蟲無法存取、標籤重複與圖片格式不符。平台通常會快取抓取結果，修改後未必立即更新。下面依序檢查三個位置，通常就能定位問題。
第一個是 Meta Sharing Debugger，這是 Facebook 官方工具，貼上網址就能看到 Facebook 讀到的 og 標籤完整列表，並提供「Scrape Again」按鈕強制刷新快取。它回報的「When and how we last scraped the URL」時間戳，是判斷「修改的有沒有被重新抓取」最直接的證據（Meta for Developers 的〈Sharing Debugger〉工具頁）。
第二個是直接用瀏覽器檢視原始碼。在頁面按右鍵「檢視網頁原始碼」，搜尋 og:，確認實際輸出的標籤、圖片網址與重複項目。第三個是到目標平台做實際分享測試，因為第三方模擬器不一定能重現平台當下的抓取與裁切規則。
處理快取的順序建議如下：先確認原始碼裡的標籤是正確的（地基），再用官方偵錯工具強制刷新該平台的快取（裝修），最終才去實際貼連結驗收。顛倒順序的話，你會一直在「為什麼改了還沒生效」裡打轉，因為你以為改了，其實改的僅是你自己網站、平台讀的還是舊快取。這也是為什麼學會用 F12 開發者工具自己看原始碼，是 SEO 與社群優化都該具備的基本功。
用一個常見情境來說明快取有多會騙人。假設網站換了新的文章封面圖，後台確認 og:image 已指向新圖、檢視原始碼也看到新網址，但 Facebook 分享卡還是頑固地顯示一張三個月前的舊圖。反覆檢查主機與外掛都找不出問題，實際用 Meta Sharing Debugger 一查，它明明白白寫著「last scraped」是一週前的時間戳，也就是 Facebook 從那之後根本沒有重新抓過這頁。點一下 Scrape Again，幾秒後分享卡就更新了。整件事真正的問題在於沒有人去戳那個「重新抓取」的按鈕，圖本身其實早就換對了。這個情境的重點不是 Facebook 多難搞，而是提醒你：當你已經確認自己這邊沒問題，下一個該檢查的永遠是平台端有沒有重新讀取。
網站可能同時有 CDN、網站快取與社群平台快取。修改後先確認來源 HTML 與圖片已更新，再依序清除網站與 CDN 的相關網址快取，最終讓支援重抓的社群平台重新抓取。這樣能分清楚舊資料停在哪一層。
OG 標籤到底算不算 SEO
這個問題可以直接回答：沒有 Google 公開文件把 OG 標籤列為排名訊號。Google 產生搜尋標題與摘要時有自己的來源與規則，不能因為 og:title 寫得好，就推論排名會上升。
OG 的價值主要在分享體驗：完整的預覽可能增加社群點擊，也可能讓內容得到更多曝光與自然連結，但這些都是後續效果，不是 OG 本身帶來的排名加成。AI 搜尋是否採用 OG 標題或圖片，也不能一概而論；若要理解 AI Overviews 的公開技術要求，可看 Google AI Overviews。
另一個常被搞混的觀念，是 OG 標籤跟結構化資料（Schema.org）的關係。兩者都是「給機器讀的後設資料」，但職責完全不同。OG 標籤管的是「社群分享時的長相」，結構化資料管的是「搜尋引擎怎麼理解你的內容、要不要給你豐富結果（rich result）」。你寫了 結構化資料 的 Article schema，它不會幫你產生分享卡；你寫了 og:image，它也不會讓你拿到星等評分的豐富結果。兩套要分開設定，各司其職，不要互相取代。
og:url 與 canonical 理想上應指向同一個正本網址。兩者不一致不等於會受到「重複內容處罰」，但會讓社群互動歸屬與搜尋正規化訊號不一致。重新規劃 站內 SEO 時值得一起對齊。
六個最常見的 OG 踩坑，你中過幾個
教學看了再多，真正上線時會犯的錯就那幾種。以下整理出台灣內容網站最常踩的六個地雷，每一個都附上正確做法，你可以拿來對照自己的網站。其中相對路徑這個坑特別容易卡關，常讓人花上一整個下午才搞懂為什麼 Facebook 抓得到圖、LINE 卻空白。
| 踩坑 | 症狀 | 正確做法 |
|---|---|---|
| og:image 寫相對路徑 | Facebook 正常，LINE 或部分平台破圖 | 改用完整絕對網址，含 https:// 與網域 |
| 圖片過大或爬蟲無法存取 | 分享卡有標題卻沒圖 | 依平台規範壓縮，確認圖片網址可公開抓取 |
| 重點內容壓在圖片邊緣 | 手機版或 X 上標題被裁掉一半 | 重要元素集中在中央安全區，上下留白 |
| og:url 與 canonical 不同步 | 同一篇文章的讚與點閱分散到多個網址 | 兩者指向同一個正本網址，追蹤參數採用 UTM 標記處理 |
| 外掛重複輸出 og 標籤 | 偵錯工具顯示兩組矛盾的 og:image | 關掉佈景主題或分享外掛的 OG 輸出，僅留 SEO 外掛那一組 |
| 改了圖卻不清快取 | 你以為沒生效，其實平台還在讀舊的 | 用 Meta Sharing Debugger 的 Scrape Again 或加查詢參數強制重抓 |
這六個坑有一個共同特徵：它們在桌機瀏覽器上完全看不出來，僅有在「真的被分享出去、在別人的手機上」才會現形。這也是為什麼僅在後台預覽、不實際走一次分享流程，永遠抓不到這類問題。把這張表當成發布前的快速自檢表，逐項確認，能擋掉絕大多數的社群破圖客訴。
特別想點出「og:url 與 UTM 衝突」這一組，因為它是台灣行銷人最常糾結的情境。你明明希望用 UTM 追蹤碼 來分辨 LINE、Facebook、電子報各帶來多少流量，卻又怕加了參數的網址讓 OG 互動數據分散。解法很清楚：UTM 參數掛在分享連結上給 Google Analytics 統計，og:url 本身固定指向那個乾淨的 canonical 正本。平台會把所有變體網址的互動，集中歸到 og:url 指定的正本，這樣追蹤與社群互動數據就能各歸各位、互不擾亂。
把 OG 預覽檢查寫進發布流程的方法
實務上常見的情況是，OG 預覽的問題很少出在某一篇文章沒寫好，多半是發布流程根本沒有把偵錯這一步放進去。內容上架前，沒有人實際把連結貼進 LINE、Facebook 驗收過，壞掉也沒人發現，等讀者在群組裡截圖回報「你們圖片壞掉了」才驚覺。補救的成本，遠高於發布前多花兩分鐘檢查。
建議固定做一輪「上架前預覽檢查」，在每次文章發布前跑一遍。流程很簡單。
- 看原始碼：在預覽環境或正式網址按右鍵檢視原始碼，搜尋
og:，確認 og:title、og:description、og:image、og:url 都存在且各僅出現一次，圖片網址是完整 HTTPS 絕對網址。 - 開圖檔：把 og:image 的網址直接貼到瀏覽器網址列，確認圖片可公開開啟、尺寸符合設計，檔案也經過合理壓縮。
- 跑偵錯工具：用 Meta Sharing Debugger 檢查 Meta 抓到的資料，再到其他目標平台實際分享，確認圖沒被裁掉重點、標題沒有亂碼。
- 實機驗收：把連結貼進你目標讀者最常用的那個管道（台灣多半是 LINE 群組），用另一支手機、另一個帳號實際看一次縮圖長相。這步最花時間，但也最能反映真實情況。
- 清快取備案：如果中途改過 og 標籤，記得用官方偵錯工具刷新該平台快取，別等到讀者回報才處理。
這份清單看起來平凡，它的價值不在於技巧多高深，而在於「每一次發布都確實執行」。SEO 與社群優化裡，真正拉開差距的常常不是某個神操作，而是這種紀律性的檢查有沒有變成 SOP。
下一步：把你流量最高的那篇文章拿來試
讀到這裡，別僅停留在理論了，現在就動手試。挑出你網站上流量最高的那篇文章，照這個四步行動方案走一遍，你會在半小時內看到具體差異。
- 盤點現況：打開那篇文章，檢視原始碼搜尋
og:，先確認四個必要屬性，再檢查常用補充標籤與圖片網址。 - 補齊缺漏：缺的標籤補上，相對路徑改成絕對網址，圖片換成 1200×630 且重要內容在中央安全區的版本。
- 驗收分享卡：用 Meta Sharing Debugger 與目標平台的實際分享測試，修正裁切或破圖問題。
- 正式分享觀察：把連結貼進平常經營的社群管道，追蹤接下來一週的點閱數變化，判斷修改是否真的有效。
OG 標籤不會讓你一夜衝上 Google 首頁，但能讓內容被分享時，以完整、可控的預覽面對讀者。把這個基本功與發布前驗收做好，就能少掉許多破圖、錯標題與舊快取問題。
常見問題
沒有 OG 標籤會怎樣？
og:title 跟一般 meta title 有什麼不同？
OG 標籤跟 Twitter Card 差在哪？
OG 圖片的建議尺寸是多少？
OG 標籤對 Google 排名有幫助嗎？
操作步驟
- 確認四個必填標籤齊全：og:title、og:description、og:image、og:url 都填了、沒有空白，og:image 用 https 絕對網址。
- 檢查圖片規格：尺寸以 1200×630 px、長寬比 1.91:1 為基準，重要內容留在中央安全區；檔案在不明顯犧牲畫質的前提下壓縮（規範無通用上限），並確認圖片網址可被爬蟲公開存取。
- 確認 og:url 是乾淨標準網址：不帶 utm 參數，按讚分享才會匯總到同一個網址。
- 顧好安全區：圖中文字、logo、人物臉部放在正中央，避開邊緣 15%，不怕被任何平台裁切。
- 對齊 Twitter Card：twitter:card、twitter:title、twitter:image 內容與 og 標籤一致，兩套協議同時覆蓋。
- 跑一次偵錯工具：Meta Sharing Debugger 與 X Card Validator 各跑一次，確認警告為零或可接受；若有改圖或改標題，手動點過再次抓取。