分享頁面前，先檢查圖片與標題

分享頁面前，先檢查公開網址提供的標題、簡介和圖片，再查看準備使用的平台實際產生的預覽。這是兩項不同的檢查：正確的頁面中繼資料為平台提供有效資訊，而平台上的實際預覽，才能顯示其他人可能看到的樣子。

你寫完了一篇產品指南，在網站上開啟，標題和配圖都正確。可是當別人把網址貼到社群貼文裡，預覽介紹的卻是首頁。文章本身可能沒問題，需要調整的是跟著連結一起傳播的那段簡短介紹。

對創辦人或小團隊來說，這是一項值得在上線前明確交由某個人負責的發布檢查。應從正確的公開網址開始。CMS 裡漂亮的預覽、瀏覽器分頁，或頁面成功回應，都不能證明分享預覽已經準備就緒。

檢查公開頁面提供了什麼

頁面上可見的標題與分享中繼資料，面向的是不同的呈現位置。標題向已進入頁面的讀者介紹內容，中繼資料則在造訪發生前，為其他平台提供頁面資訊。許多網站使用 Open Graph 欄位來完成這件事。

Open Graph 協定定義了四項基本屬性：標題、物件類型、圖片網址，以及物件的標準網址。協定也說明了簡介等選用資訊。可以把這些看作有名稱的輸入欄位，而不是頁面截圖。

我們在 2026年10月14日 檢查了頁面標題指南公開回傳的 HTML。當時的 Open Graph 標題是「Write a Title That Matches the Page | FounderOmni」，頁面上可見的主標題是「Write a Page Title That Matches the Answer Inside」。兩者措辭不同，但介紹的是同一項編輯工作。

回應中也提供了文章類型、指南本身的網址、一段說明如何核對標題與內文答案的簡介，以及以 page-title-label-cover-v1.jpg 結尾的圖片位址。我們下載了這張公開圖片，確認它是尺寸為 1,536 × 1,024 像素的 JPEG，實際尺寸與回傳 HTML 中宣告的寬度及高度一致。

這是對真實頁面和圖片檔案的觀察，不是對 Facebook、LinkedIn 或通訊應用程式預覽的測試。它能說明伺服器回傳了什麼，以及我們檢查了哪張圖片；無法說明某個平台選擇了怎樣的裁切、使用哪些快取資訊，或顯示了什麼文字。

你也可以向開發人員提出這樣一個範圍明確的小需求：檢查指定頁面回傳的 HTML，列出分享標題、簡介、網址及圖片位址，然後直接開啟圖片位址。如果預覽指向另一頁，把這些欄位一起記錄下來，會更容易排查。

除了缺漏的資訊，也要檢查意外重複的欄位。佈景主題、SEO 擴充套件與頁面範本，都可能各自產生中繼資料。協定對陣列的說明指出，重複值發生衝突時，排在前面的值優先。不要把每張額外圖片都視為錯誤，提供備選圖片也可能是刻意安排的。但如果舊首頁圖片排在文章原本要使用的圖片前面，就需要調查原因。

如果公開回應中的欄位仍是舊的，應先修正發布流程，再考慮反覆修改分享貼文。CMS 可能儲存了修訂，卻沒有更新公開頁面。我們的部署檢查指南說明了如何區分「頁面成功回應」與「預期內容已經發布」。

把圖片當作頁面介紹來檢查

開啟實際選用的圖片，而不只是查看網站的主視覺。有些網站會為文章主圖和分享中繼資料使用不同素材。只要選中的圖片介紹的是同一主題，也沒有暗示無關產品或成果，這樣做可以是合理的。

在我們的例子中，配圖是一雙手在文件盒上貼標籤，呼應了「標籤應與內容相符」這個主題。這是一張編輯插圖，不是搜尋結果已改善的測試證據。實際含義由標題和簡介傳達，圖片起輔助作用。

準備自己的圖片時，先想清楚：縮小之後，哪些內容仍應容易辨認。把主體放在常見裁切方式下仍能理解的位置，並將重要說明寫在搭配的文字裡。嵌在圖片中的長標題，在預覽縮小或被裁切後，可能很難閱讀。

可以在本機裁切圖片，找出明顯的構圖問題，但要把它視為設計練習。你自行裁出一張方圖，不能證明某個平台就會採用相同裁切。對準備發布的貼文而言，相關的實際依據仍是該平台產生的預覽。

發布產品公告時，一張真實截圖可能比裝飾插畫更有幫助。使用獲得授權的公開頁面或示範介面，清楚呈現相關功能，並移除私人工作空間資訊。如果介面還只是概念，應明確標註；精美的概念圖不應讓人誤以為尚未開放的功能已經可用。

替代文字也應提供有用資訊。Open Graph 圖片屬性包含尺寸與圖片說明。描述圖片裡有什麼，而不是重複行銷口號。在我們的例子中，圖片檔案和對應說明文字都經過了檢查；只有說明文字，不能證明圖片檔案可以存取。

同時檢查平台預覽與連結目的頁

確認公開欄位和圖片正確後，開啟目標平台支援的預覽工具或編輯器，輸入準備分享的正確網址。如果平台支援草稿預覽，就先查看預覽，不必發布。記錄平台、網址及檢查時間，讓隊友能夠重現觀察結果。

除了外觀，也要檢查實際任務是否完成：標題介紹的是這一頁嗎？簡介是否補充了有用背景？圖片是否仍容易辨認？接著點擊預覽中的連結，確認它通往預期的答案。一張漂亮的卡片如果跳到籠統的首頁，仍未完成這次資訊交接。

如果顯示的資訊與目前回應不同，要同時保留兩份觀察紀錄。這種差異不見得代表 CMS 修改失敗。平台可能保留著較早的資訊，或選用了其他欄位。應查看它目前的說明文件或可用的診斷工具，不要假設所有平台都有統一的重新整理按鈕或等待時間。

不要為了強行產生不同的預覽，就不斷加入隨意的查詢參數。先弄清楚分享的是哪個網址，以及它所代表的頁面是否保持一致。如果刻意為圖片檔案加入版本號，應更新頁面中的引用，並檢查新檔案。只改檔名，不能證明平台已擷取該檔案。

可以用這份簡短紀錄進行交接：

• 頁面：正確的公開網址，以及開啟後應獲得的有用答案。
• 輸入欄位：分享標題、簡介、圖片位址，以及回傳 HTML 中發現的衝突值。
• 檔案：實際圖片格式、尺寸和可存取性檢查結果。
• 預覽：目標平台、觀察時間，以及草稿或診斷頁面實際顯示的內容。
• 目的頁：點擊連結後的結果；若與頁面承諾不符，下一步需要修正什麼。

把紀錄放在發布草稿旁邊。欄位檢查、圖片審閱與平台預覽，分別回答不同的問題。將它們結合起來，下個接手的人才能知道具體該修什麼，而不只是再次收到一句「把社群分享圖片做好一點」。