Open Graph 檢查器
Open Graph 標籤是決定頁面連結被貼到 Facebook、X、LinkedIn、Slack 或聊天應用程式時外觀的 meta 標籤。輸入一個 URL，本檢查器會抓取該頁面一次，準確顯示每個平台將使用哪些標籤和回退值，算繪四張分享卡片，並檢查分享圖片的真實尺寸。配套指南發佈前先檢查你的分享卡片會講清發現問題後如何修復；想要更寬泛的例行體檢，請改用網站健康檢查。
最後更新:
想持續監控這個網站？用 myeventwatch 免費監控——到期和停機提醒，無需綁卡。
檢查的運作方式
檢查器會對你輸入的 URL 做一次受保護的伺服器抓取、跟隨重新導向，並讀取最終頁面的靜態 HTML——也就是平台抓取器看到的同一份 HTML。它解析 og: 與 twitter: meta 標籤、頁面 <title> 和 meta 描述，然後逐個平台推算每張分享卡片實際會顯示哪個值、這個值來自哪裡。由回退提供的值會被標註為回退，因此一張看起來完整的卡片不會掩蓋其下缺失的標籤。
有一個限制決定了其餘一切：這是一次普通 HTTP 抓取，不是瀏覽器，而平台抓取器也不是瀏覽器——兩者都不運行 JavaScript。由腳本注入、僅在用戶端算繪、或只在登入後加入的標籤，在這裡看不到，在 Facebook、X、LinkedIn 和 Slack 上也同樣看不到。如果一個標籤只存在於你的 JavaScript 包裡，它對分享來說就不存在。結果中顯示的內容——最終 URL、HTTP 狀態、原始標籤表和四張算繪出的卡片——就是抓取器必須依據的靜態事實。
回退、相對圖片陷阱與抓取器快取
每個平台的回退方式都不同，這正是同一個頁面在一個應用程式裡正常、在另一個應用程式裡損壞的原因。Facebook 直接讀取 og: 標籤。X 先讀取自己的 twitter: 標籤，缺失時回退到對應的 og: 標籤。LinkedIn 只讀取 og: 標籤，因此再完美的 Twitter Card 設定對它也毫無幫助。Slack 先讀取 og: 標籤，再讀取 twitter: 標籤。下方的清單會標出每個缺失欄位、每個空欄位，以及每個會被平台用回退填補的欄位，並註明它會回退到哪個來源。
最常見的無聲失敗是相對路徑的 og:image：像 /images/share.jpg 這樣的值在你的範本和瀏覽器裡看起來沒問題，但大多數抓取器無法對它做任何解析，於是卡片乾脆不顯示圖片。修復方法永遠是帶通訊協定的絕對 URL。第二個陷阱是快取：每個平台都會快取其抓取器抓到的內容，因此修復標籤並不會更新已經發出的貼文，甚至新的預覽也可能繼續提供舊卡片，直到你要求平台重新抓取該 URL。先修標籤、在這裡驗證、然後重新抓取——必須按這個順序，否則你會把損壞的版本再次快取下來。
誠實的邊界：這裡的預覽是對各平台已公開行為的模擬，不是真實貼文的截圖。各平台裁剪、圓角和截斷的方式各不相同，卡片版面會不經通知地改變，登入與未登入使用者看到的也可能不同，因此請把卡片當作忠實的模型，而不是保證。有一件事不是模擬的：分享圖片的尺寸讀取自實際圖片檔案的檔頭，而不是頁面宣告的 og:image:width 與 og:image:height 值——宣告值只是說法，本檢查器會拿檔案本身來核對它。
檢查內容及其背後的規則
| 檢查的標籤 | og:title、og:description、og:image、og:url、og:type 和 og:site_name，加上 twitter:card、twitter:title、twitter:description 和 twitter:image——以及作為回退來源的頁面 <title> 和 meta 描述。 |
| 推薦圖片尺寸 — 1200 × 630 px | 1200 × 630 是平台指引，不是正式標準：它是 Facebook 推薦的尺寸，也是 X、LinkedIn 和 Slack 處理效果最好的大卡片尺寸。更小的圖片仍能顯示，但卡片可能裁剪它們，或回退成小縮圖。 |
| 直接讀取 og: 標籤——og:title、og:description 和 og:image——僅在 og: 標籤缺失時才回退到頁面 <title> 和 meta 描述。 | |
| X（Twitter） | 先讀取 twitter:title、twitter:description 和 twitter:image；每一項缺失時都回退到對應的 og: 標籤。twitter:card 決定卡片版面，缺失時 X 會根據找到的內容猜測。 |
| LinkedIn 與 Slack | LinkedIn 只讀取 og: 標籤——twitter: 標籤在那裡沒有幫助。Slack 先讀取 og: 標籤、再讀取 twitter: 標籤，因此是四者中最寬容的。 |
| 相對圖片 URL | og:image 和 twitter:image 必須是帶通訊協定的絕對 URL。大多數抓取器無法解析相對路徑，結果就是一張沒有圖片、且任何地方都沒有報錯的卡片。 |
| 圖片尺寸 | 讀取自實際圖片檔案——它的 PNG、JPEG、GIF 或 WebP 檔頭——同時給出位元組大小和格式。宣告的 og:image:width 和 og:image:height 會顯示出來供對比，但從不單獨被信任。 |
| 尺寸未知 | 意味著檢查器無法抓取或解析圖片檔案——它逾時了、拒絕了請求，或格式的檔頭無法讀取。屆時頁面宣告的尺寸（如果有）就是所有人——包括抓取器——唯一擁有的資訊。 |
常見問題
為什麼我分享的連結不顯示圖片？
按常見程度排序的原因：根本沒有 og:image；og:image 是抓取器無法解析的相對 URL；圖片太小，或位於抓取器無法抓取的位置（登入之後、被 robots 規則封鎖，或傳回錯誤）；或者平台仍在顯示圖片存在之前那次抓取的快取。在上方運行檢查——它會指出適用的是哪一種——修復標籤，然後要求平台重新抓取。
Open Graph 標籤和 Twitter 標籤——兩者都需要嗎？
實際工作中，需要。Facebook 和 LinkedIn 只讀取 og: 標籤，而 X 優先使用自己的 twitter: 標籤，並把 og: 標籤用作回退。一套完整的 og: 標籤加一個 twitter:card 標籤能覆蓋大多數情況，但顯式的 twitter:title、twitter:description 和 twitter:image 是讓 X 卡片與 Facebook 卡片有所區別的唯一辦法——而 Slack 會讀取兩套標籤，先 og: 後 twitter:。
為什麼真實貼文和這裡的預覽不一樣？
幾乎總是因為快取。每個平台的抓取器都會快取它為某個 URL 抓到的內容，修改標籤並不會讓該快取失效。修復前發佈的貼文會保留舊卡片，甚至平台自己的偵錯器在被強制重新抓取前也會繼續顯示快取版本。較少見的原因是裁剪：平台會按其目前版面裁剪和截斷，而這裡的預覽是對已公開行為的模擬，不是截圖。
這個檢查器會運行 JavaScript 嗎？
不會——而且這是故意的。檢查器只抓取一次靜態 HTML，與平台抓取器的做法完全相同，而抓取器同樣不運行 JavaScript。因此，由腳本或用戶端框架加入的標籤在這裡缺失的原因，與它在 Facebook、X、LinkedIn 和 Slack 上缺失的原因完全相同。如果你的標籤由 JavaScript 算繪，它們必須出現在伺服器算繪的 HTML 中，才能對分享起作用。
og:image 應該用多大的尺寸？
盡可能使用 1200 × 630 px。這是平台指引而非正式標準——它是 Facebook 推薦的尺寸，也是 X、LinkedIn 和 Slack 大卡片所圍繞的尺寸。讓檔案保持合理的小體積，使用 PNG 或 JPEG（WebP 的支援因抓取器而異），並始終用絕對 URL 引用它。本檢查器會標記小於 1200 × 630 的圖片，並告訴你它從檔案中測得的真實尺寸。