發現損壞的連結預覽的最糟糕時間是在發布推文之後。你在一個頁面上花了一周的時間,寫公告,點擊發送 - 出現的卡片是一個灰色矩形,標題被截斷,沒有圖像,因為 og:image 指著 /images/og.png 代替 https://yoursite.com/images/og.png. 貼文已經發布了。該卡已快取。您可以修復它,然後要求每個人重新共享。
一個 打開圖 預覽透過提前移動支票來解決這個問題。您無需發布和希望,而是查看標籤仍可編輯時卡片會是什麼。這就是整個前提 開啟圖形預覽 工具:輸入您的標籤,或貼上您已有的標籤,然後查看並排呈現的近似 Facebook、X、LinkedIn、Slack 和 Discord 卡,並在每個欄位上給出通過/警告/失敗判決。
單一預覽不夠的原因是每個平台讀取相同的標籤並以不同的方式呈現它們。 X 截斷了大約 110 個字元的描述; Facebook 顯示接近 155。LinkedIn 經常完全刪除描述,只顯示圖像、標題和網域。 Slack 將整個內容折疊成帶有彩色導軌的緊湊附件。 Discord 將描述嵌入顯著位置,但縮小了圖像。完美適合 Facebook 卡的標題可以在 X 上中途剪下,除非您同時查看兩者,否則您永遠不會注意到。
我建造 工具。dev 並且不斷傳送頁面,我厭倦了發布檢查修復循環。該工具完全在瀏覽器中運行,根本不進行網路呼叫 - 它永遠不會獲取您的 URL - 這意味著它也適用於尚未部署、位於登入後面或生活在官方平台偵錯器無法到達的暫存網域上的頁面。
TL;DR: 開啟圖標籤控制連結共享時的外觀。每個平台讀起來都一樣
og:標籤但會以不同的方式截斷和排列它們,因此預覽一個平台不會告訴您其他平台的任何資訊。這 開啟圖形預覽 tool 從一組標籤渲染五張平台卡,根據當前平台限制驗證每個字段,解析現有標籤區塊(如果您已經擁有),然後遞給您一個準備複製的標籤區塊<meta>區塊 - 所有客戶端,無需抓取,也無需上傳。
主要特點
一組標籤的五個平台預覽
該工具提供了 Facebook 的近似卡,X 均包含 summary_large_image 和 summary 樣式、linkedin、slack 和 Discord。它們都從相同的欄位讀取,因此當您修剪標題時,您會同時觀看它到處更新。重點不是像素完美的保真度 - 平台在沒有警告的情況下重新設計卡片 - 而是相對保真度:正確的比例、正確的截斷點、正確的欄位順序,這樣您就可以看到哪個平台是損壞的平台。
貼上並解析您已有的標籤
如果頁面存在,您很少想重新輸入九個欄位。貼上原始 HTML - 整個 <head>,一個視圖來源轉儲,或一個鬆散的區塊 <meta> 行 - 進入解析框,內建解析器將每一行拉出 og: 和 twitter: 標記它識別並將它們加載到表單中。解析器是基於正規表示式而不是基於 DOM,這使得相同的程式碼可以在瀏覽器、節點和桌面建置中運行而無需更改。
具有實際限制的每場驗證
每個欄位都會獲得通過、警告或失敗狀態。超過約 60 個字元的標題失敗。 110 到 155 個字元之間的描述會發出警告,因為它在 Facebook 和 LinkedIn 上可以完全讀取,但在 X 上會被刪除。親戚 og:image 路徑徹底失敗--刮刀無法解決它們。一個 og:image 供應於平原 http 警告,因為多個平台拒絕渲染非 HTTPS 影像。 A twitter:site 不是有效句柄的值會失敗。判決足夠具體,可以採取行動,而不是通用的"看起來很好&引用;。
您實際上可以遵循的圖像規則
每個主要平台上的大圖像卡都呈現1.91:1的圖像; 1200x630 像素是一次滿足所有像素的大小。該工具明確指示目標,標記使圖像靜默消失的故障模式,並且 - 因為圖像損壞的卡是最常見的 Open Graph 錯誤 - 呈現您的實際情況 og:image 每個預覽中的 URL,如果影像無法加載,則回退到清晰的佔位符。
一個準備複製、正確轉義的元區塊
產生的輸出是一個完整的標籤塊,而不是一個片段。它包括 og:image:width 和 og:image:height,這比大多數人意識到的更重要:沒有它們,一些刮刀會在第一次獲取時渲染純文字卡,並且僅在下載並測量圖像後顯示圖像,這可能需要幾個小時。值是 HTML 轉義的,因此描述中的&號或引用不能突破屬性並損壞標記。
100% 客戶端,無需刮擦
該工具永遠不會請求您的 URL。這是故意的,值得理解的原因:由於同源策略,瀏覽器無法取得任意第三方頁面,而伺服器端取得器意味著將您未發布的 URL 傳送給其他人'日誌。透過您提供的標籤,可以避免問題並解鎖官方偵錯器無法服務的情況 - 驗證尚未上線的頁面。看 線上工具中的資料隱私 為了更廣泛的推理。
如何使用開放圖預覽工具
第 1 步:載入標籤
你有兩條路。如果您是從頭開始編寫元數據,請填寫以下表格: og:title, og:description, og:image, og:url, og:site_name,然後選一個 og:type 和a twitter:card 風格並添加您的 twitter:site 和 twitter:creator 手柄。
如果頁面已經有標籤,請貼上它們。開啟頁面,查看來源(不是瀏覽器檢查器 - 下面有更多關於此區別的資訊),複製 <head>,並將其放入解析框中。點擊解析標籤,識別的所有內容都會載入到表單中。解析器也理解別名: og:image:secure_url 和 og:image:url 兩者都饋送影像字段,並且 twitter:title, twitter:description, 和 twitter:image 當它們被用作後備 og: 不存在等效項 - 這反映了平台本身如何解析標籤。
第 2 步:讀取驗證面板
驗證清單按照欄位的重要性排序。首先修復失敗:缺少 og:image,相對圖像路徑,標題超出限制20個字元。然後看看警告,這些警告主要是關於平台之間的差距 - 這個描述對於 Facebook 來說很好,但對於 X 來說很長,缺少一個 og:site_name 這意味著您的卡片顯示的是裸主機名稱而不是您的品牌。
面板頂部的計數器可以讓您快速閱讀。零失敗,幾個警告是一種完美的可發貨狀態;警告是權衡,而不是錯誤。
第三步:比較卡片
這是人們跳過的步驟,也是發現真正問題的步驟。掃描所有六個預覽。 X 摘要卡上的標題是否已刪除? LinkedIn 上的描述是否消失(通常如此 - 這是預期的)?圖像看起來是否正確,或者您的徽標是否被裁剪,因為您設計了方形圖形並且卡片使其變寬?
修剪並重新檢查,直到每張卡片都乾淨地讀取。一個有用的規則:寫到最嚴格的限制。如果您的描述在 110 個字元處完全讀取,那麼它到處都完全讀取。如果您的標題在 55 處有效,則它可以在每張卡片和每個行動佈局中保留。
步驟 4:複製元區塊並運送它
將產生的區塊複製到您的頁面中's <head>. 在框架中 - Next。js、Nuxt、SvelteKit、Astro - 您不會貼上原始內容 <meta> 標籤,但該區塊仍然是您在框架中填充哪些欄位的真實來源's 元資料 API。
然後執行每個人忘記的步驟:重新抓取每個平台中的 URL's 調試器。運送修復程式不會清除快取卡。這 元標記產生器 如果您還需要與社交標籤並存的標準 SEO 標籤(標題、描述、規範、機器人),那麼它是這裡的配套工具。
開放圖協定實際工作原理
Open Graph 於 2010 年在 Facebook 上推出,旨在將網頁轉變為社交圖中的節點。野心逐漸消退;標籤詞彙被卡住了,現在它是 Facebook、LinkedIn、Slack、Discord、WhatsApp、Pinterest、iMessage、Signal 和大多數其他連結展開軟體讀取的事實上的標準。
機制很簡單。共享連結時,平台會將機器人傳送到您的 URL - facebookexternalhit, LinkedInBot, Slackbot-LinkExpanding, Discordbot, Twitterbot. 該機器人請求原始 HTML,讀取 <head>,提取 og: 和 twitter: 元標記,並建立一個卡。它是一個 HTTP GET 和一個解析。該機器人不是瀏覽器:大多數爬蟲不執行 JavaScript,這是整個錯誤類型的根本原因。
標籤本身
根據協議的要求描述了四個標籤: og:title, og:type, og:image, 和 og:url. 在實踐中 og:description 和 og:site_name 同樣承重,因為沒有它們,卡片要么裸露,要么回落到刮刀可以在頁面上找到的任何文字。標籤使用 property 屬性,不是 name- <meta property="og:title" content="..." />- 這會讓人們絆倒,因為 Twitter 標籤的作用相反並使用 name. 大多數解析器對此表示原諒,但平台'自己的驗證器並不總是如此,因此值得正確使用。
og:與 Twitter:優先
X 首先讀取 Twitter 卡標籤,當它們不存在時又回退到 Open Graph。這意味著頁面只有 og:title, og:description, 和 og:image 仍然會產生一張可用的 X 卡 - 後備是經過設計的。
那麼實際上需要什麼呢 twitter: 標籤?三件事。 twitter:card 決定佈局,並且沒有等效的 Open Graph:如果沒有它,X 會根據它找到的內容選擇卡片樣式,這不是您想要委託的決定。 twitter:site 將卡片歸因於品牌帳戶。 twitter:creator 歸功於作者。其他一切都可以安全地來自 Open Graph。
實用規則:寫出完整的 Open Graph 標籤,然後準確地添加這三個標籤 twitter: 標籤。重複 twitter:title 和 twitter:description 無害但毫無意義,除非您確實想要 X 上與其他地方不同的副本 - 這有時是一個合法的選擇,因為 X'更緊的截斷有時證明更短、更有力的描述是合理的。
影像尺寸、比例和裁剪問題
1.91:1 的長寬比是要內化的數字。 1200x630 像素擊中了它,對於視網膜顯示器來說足夠大,Facebook、LinkedIn 和 X 都在不失真的情況下對大圖像卡進行渲染。
失敗模式很微妙:平台通常不會拒絕離比圖像,他們會裁剪它。上傳一個 1000x1000 的方形圖形,Facebook 會將其居中裁剪為 1.91:1,這會將頂部和底部的大約三分之一切掉。如果您的標題文字垂直居中,它就會存活下來;如果您在頂部放置徽標,則不會。將有意義的內容保留在安全區域內並遠離邊緣,因為不同的表面裁剪量略有不同。
緊湊型x summary 卡是例外。它想要一個方形圖像,最小尺寸為 144x144,並且它將中心將 1.91:1 的橫幅裁剪成正方形 - 這通常會破壞它。如果你故意使用的話 summary,提供方形圖像;如果您提供橫幅,請使用 summary_large_image.
將檔案大小保持在約 5 MB 以下(Facebook'有記錄的上限;其他平台在實踐中更嚴格),用作 PNG、JPEG 或 網路P,並且始終使用絕對的 HTTPS URL。相對路徑和協定相對 // URL 是影像默默無法出現的兩種最常見方式。
為什麼要抓取緩存,以及如何破壞緩存
每個平台都會快取抓取頁面的結果 - 通常持續約 7 天,有時甚至更長。這並不固執:一個流行的連結每小時可以共享數千次,為每個共享重新獲取您的頁面將是該平台進行的拒絕服務攻擊。所以它們抓取一次並重複使用。
結果是修復標籤並不能修復卡片。舊預覽會針對每個現有股票和新股票持續存在,直到快取到期。強制刷新:
- 臉書: 共享偵錯器,使用 "再次刮擦並引用;按鈕。這也清除了 Instagram 和 WhatsApp 使用的快取。
- 領英: 郵政檢查員。輸入 URL 會觸發新的刮擦。
- X: 卡驗證器已被棄用且存取不一致。實際上,發布連結是唯一可靠的刷新。
- 鬆弛: 展開快取自行過期;新增無害的查詢參數會立即產生新的展開。
- 不和諧: 類似地 - 更改的查詢字串是實際的解決方法。
這個查詢字串技巧就是通用逃生艙口: https://example.com/page?v=2 對於刮刀來說,是一個不同的 URL,沒有快取條目。使用它進行測試,而不是用於您實際發布並保留的規範連結 og:url 指向乾淨的規範位址,以便參數化變體的份額正確合併。這 URL 編碼器/解碼器 當這些參數變得複雜時很方便。
標籤遺失時會發生什麼
刮刀會後退,而且後退比你希望的還要糟糕。
不 og:title 他們使用 <title> 標籤 - 通常為搜尋結果而編寫,通常以管道和您的品牌名稱結尾,笨拙地閱讀為卡片標題。不 og:description 他們使用元描述或抓取正文,這可以拉入 cookie 橫幅或導航標籤。不 og:image 大多數平台都會顯示純文字卡,儘管有些平台會尋找頁面中的任何圖像,並可能找到徽標、頭像或追蹤像素。不 og:url 並且共享位址按原樣使用,所以 ?utm_source=twitter 變體被視為不同的頁面,並且您的份額計數片段。
還有一個故障類別值得命名,因為它在正常調試中是看不見的: 由客戶端 JavaScript 注入的標籤. 如果您的元標籤是由 React 在水合後設定的,瀏覽器檢查器會完美地顯示它們,而刮刀什麼也看不見,因為刮刀從未運行過您的 JavaScript。始終使用檢視來源或進行驗證 curl,它顯示伺服器實際傳回的原始 HTML - 而不是應用程式啟動後的 DOM。這同樣適用於向未經身份驗證的請求傳回 401、登入重定向或機器人阻止 403 的頁面:抓取器取得錯誤頁面,而不是您的內容。
常見用例
啟動前驗證
核心案例。在頁面上線之前,貼上您打算發送的標籤並確認每張卡片的渲染。這是官方平台偵錯器無法做的一件事,因為他們必須取得即時 URL。啟動前檢查需要三十秒,並且可以節省啟動日的重分享。
調試損壞的卡片
連結展開錯誤,您需要知道原因。貼上頁面'當前標籤,讀取驗證面板,原因通常是直接的:相對圖像路徑,an http 圖像,兩倍限制的描述,缺失 twitter:card.修復,重新抓取平台偵錯器,完成。
審核網站'大規模元資料
逐頁瀏覽網站,貼上每個網站 <head> 閱讀判決結果,可以發現任何多貢獻者專案中累積的漂移:一個頁面有 Twitter 標籤,另一個頁面沒有,一個描述是 300 個字符,三個頁面共享相同的通用名稱 og:image. 該工具變成了快速一致性檢查,而不是每頁猜測。
設計共享影像
當您選擇或調試時 og:image(預覽版向您展示了一張寬牌與一張方牌中的莊稼實際上對其做了什麼)。設計師通常會交出一個美麗的方形圖形,該圖形會被 1.91:1 的莊稼屠殺;看到它之前發貨比看到它之後便宜。
將副本寫入最嚴格的約束
因為預覽顯示 X' Facebook's 旁邊的截斷,他們將抽象字元限制變成可見的內容。當您可以看到輸入時出現的省略號時,編寫完全讀取 110 個字元的描述會更容易遵守。這 蛞蝓發電機 涵蓋產生乾淨 URL 的相鄰工作 og:url 應該指向。
正在進行暫存或登入後
平台偵錯器無法存取內部工具、NDA 下的客戶端工作以及驗證牆後面的頁面。由於該工具是根據標籤而不是從獲取中工作的,因此它處理它們的方式與公共頁面相同。
平台比較
目前最著名的指導。平台在沒有公告的情況下更改這些數字,並且截斷點以像素而不是字元來測量 - 充滿寬字母的標題比充滿窄字母的標題更快。將這些視為安全目標,而不是規格。
| 平台 | 推薦圖像 | 比率 | 顯示標題 | 顯示說明 | 筆記 |
|---|---|---|---|---|---|
| 臉書 | 1200x630 | 1.91:1 | ~60 個字元 | ~155 個字元 | 最小 200x200;中心作物離比影像 |
| X /Twitter(大) | 1200x628 | ~1.91:1 | ~60 個字元 | ~110 個字元 | 需要 twitter:card=summary_large_image |
| X /Twitter(摘要) | 800x800 | 1:1 | ~50 個字元 | ~90 個字元 | 最低 144x144;需要方形影像 |
| 領英 | 1200x627 | ~1.91:1 | ~100 個字元 | 常隱藏 | 描述經常從卡片上掉落 |
| 鬆弛 | 1200x630 | 1.91:1 | ~60 個字元 | ~140 個字元 | 緊湊型附件;展開快取自行過期 |
| 不和諧 | 1200x630 | 1.91:1 | ~60 個字元 | ~160 個字元 | 渲染描述突出,影像較小 |
表中的要點就是設計目標:1200x630 的圖像、55-60 個字元或以下的標題以及 110 以下的描述,為您提供一張無需按平台調整即可在任何地方正確渲染的卡片。
問號
什麼是正確的開啟圖形圖像大小？
使用 1200x630 像素 - 比例為 1.91:1。對於大圖像卡,它同時滿足 Facebook、LinkedIn、X、Slack 和 Discord 的要求,並且足夠大,可以在高密度顯示器上保持清晰度。將檔案保持在約 5 MB 以下,透過 HTTPS 以絕對 URL 形式提供,並保持重要文字遠離邊緣,因為表面裁剪量略有不同。對於緊湊型 X 摘要卡,請提供至少 144x144 的方形影像。
為什麼我的連結預覽在修復標籤後仍然顯示舊圖像?
因為平台會快取早期抓取的結果,通常持續約一週。更新標籤不會使該快取失效。強制透過平台取得新的內容's 調試器 - Facebook 共享調試器和#39;s 再次抓取按鈕或 LinkedIn Post Inspector。對於 Slack 和 Discord,在 URL 中新增查詢參數會立即產生未快取的預覽,這是驗證修復程式的最快方法。
我需要 OG: 和 Twitter: 標籤嗎？
當 Twitter 等效項遺失時,X 會回退到 Open Graph,因此頁面完整 og: 標籤會產生一張可用的 X 卡。 Open Graph 無法表達的是卡片佈局,因此您仍然應該添加 twitter:card 在大橫幅和緊湊摘要之間進行選擇,加上 twitter:site 和 twitter:creator 賦予卡片屬性。這三個加上完整的 Open Graph 標籤是有效的組合。
og:title 和 og:description 應該持續多久?
保持 og:title 大約 60 個字元或以下。為了 og:description 這些平台有所不同:x 顯示大約 110 個字符,Facebook 和 LinkedIn 顯示接近 155 到 200 個字符。寫入更嚴格的 X 限制意味著描述到處都可以完全讀取。超過限制的文字不會遺失,只是隱藏在省略號後面,因此請預先載入重要的單字。
為什麼我的預覽是空白的或僅顯示 URL?
通常的原因,大致按頻率順序排列: og:image 是相對路徑而不是絕對 URL;圖像以普通形式提供 http;標籤在外面 <head>;標籤由用戶端 JavaScript 注入,而刮刀永遠不會執行這些標籤;或頁面傳回非 200 狀態或登入重定向到機器人。使用 view-source 或檢查原始 HTML curl 檢查器不是瀏覽器檢查器,而是在 JavaScript 運行後顯示 DOM,這不是刮刀所看到的。
該工具會取得我的 URL 來讀取標籤嗎?
不,它根本不提出網路請求。它可以從您鍵入或貼上標籤中運行,並且所有內容都在您的瀏覽器中解析和呈現。由於 CORS,瀏覽器無法取得任意第三方頁面,而伺服器端取得器將意味著將您未發布的 URL 傳送到其他地方。權衡是您提供標籤 - 好處是本地主機、暫存或登入後方的頁面與公共頁面完全相同。
我可以預覽尚未發布的頁面嗎?
是的,這是使用這個而不是平台調試器的主要原因。官方調試器必須取得即時 URL,因此它們在部署之前毫無用處。在這裡,您貼上要附帶的標籤(來自範本、框架元資料物件或本機建置),然後預覽立即呈現。
Open Graph 標籤對我的搜尋排名有幫助嗎?
不是直接的。它們被社交和聊天平台讀取,不被搜尋引擎用作排名因素。它們的影響是連結每個份額的點擊率,它驅動流量,並間接驅動重要的訊號。將它們視為共享連結的轉換優化,而不是 SEO 槓桿。對於確實影響您的搜尋片段的標籤,請使用 元標記產生器.
