一個連結被貼到社群平台，預覽卡卻是一片空白，沒有圖、沒有標題，只剩一行網址，這是行銷團隊發文前最不想看到的畫面。這種情況最常見的原因，是網站整組漏掉了社群用的meta標籤，而這一塊往往也是修復成本最低、見效最快的項目。但有一種情況修了也沒用：如果robots.txt把社群平台的爬蟲整個擋在門外，標籤寫得再完整，對方的爬蟲根本進不來讀取，預覽照樣是一片空白。

1. 社群meta標籤少一項，分享預覽就整組跑掉

根據我們的服務經驗，一家工業儲存設備供應商的官網完全沒有設定Open Graph與Twitter Card標籤。連結被貼到社群平台時，平台抓不到指定的預覽圖、標題與描述，只能自己亂猜，結果經常抓錯圖，或是顯示一段沒有意義的文字片段。對一個仰賴專業形象接單的工業品牌來說，這種空白的預覽等於在分享的第一眼就先失了分。社群meta標籤不是裝飾性的選項，它決定了連結被貼出去之後，別人看到的第一印象是清楚的品牌畫面，還是一團亂猜的殘片。我們替這家供應商補齊標籤之後，業務團隊反映在群組裡轉發報價頁面的連結，終於能正常顯示廠房實景照與清楚的產品標題，不再需要另外附一句話解釋這個連結是什麼。這種差異看似很小，累積下來卻直接影響對方點不點開連結、願不願意繼續往下讀。

1.1 Open Graph四個核心標籤決定連結在社群上長什麼樣

Open Graph是一組放在<head>裡的meta標籤，告訴社群平台這個頁面該用什麼標題、描述、圖片和網址來呈現。核心的四個是og:title、og:description、og:url與og:image。我們的做法是讓前三個動態綁定頁面本身的標題、描述與正規網址，不另外手寫一套，否則兩邊很快就會不一致，日後改了頁面標題卻忘了同步更新社群標題，反而製造新的落差。og:image則要準備一張獨立設計的預覽圖，尺寸建議走1200×630這種主流長寬比，社群平台裁切時才不會切壞重點文字或人像。除了核心四項，我們也會視情況補上og:type與og:site_name，前者告訴平台這是文章、產品頁還是其他類型的內容，後者則讓分享卡片上多顯示一行品牌名稱，對於連結被轉發到不同群組、脫離原本網站脈絡時，能多一層辨識度。這幾個欄位不是必填，但補上之後，整張預覽卡看起來會更完整，也更容易被認出是哪個品牌發的內容。

1.2 Twitter Card不是Open Graph的附屬品，要各自寫齊

很多網站以為設了Open Graph就足夠，但部分社群平台走的是自己的Card規格，不會完全沿用Open Graph的內容。twitter:card設成summary_large_image可以拿到大圖版面，再搭配twitter:title、twitter:description、twitter:image。這幾個欄位可以和Open Graph共用同一份文字與圖片，重點是要「都寫上去」，別讓某一個平台抓到空值，退回顯示小圖或純文字連結。我們也遇過只設了Open Graph、沒設Twitter Card的網站，結果連結貼到不同平台呈現的樣子完全不一樣，有的圖文並茂，有的卻只剩一行藍色網址，對外觀感很不一致，對方甚至會誤以為是不同來源的連結。下面這張表是我們交付給客戶時，最基本的社群標籤與伺服器層設定清單，實務上會依專案再擴充。

項目	用途	建議設定	漏掉或設錯的後果
og:title	社群顯示標題	動態綁定頁面Title	顯示錯誤或空白標題
og:description	社群顯示描述	動態綁定Meta Description	平台自行抓一段亂文字
og:url	正規化網址	動態綁定Canonical網址	分享數據分散在不同網址
og:image	預覽圖	獨立預設圖，1200×630	抓錯圖或完全無圖
twitter:card	卡片版型	summary_large_image	退回小圖或純文字
robots.txt	控制爬蟲能否進站	不誤擋社群爬蟲的User-agent	meta標籤寫再好也讀不到

1.3 上線社群meta後，一定要跑一次驗證流程

我們在實務上看過標籤都加了，分享出來卻還是舊圖的狀況，原因通常是社群平台自己有快取，沒抓到最新版本。所以每次上線後，我們一定用各平台的官方預覽偵錯工具重新丟一次網址，強制刷新快取，順便確認圖片真的載得出來、文字沒有被截斷。標籤寫對只是第一步，確認平台端真的更新了，才算真正收尾，否則行銷團隊還是會拿著舊圖去發文，白忙一場。我們會建議把這道驗證寫進發文前的固定檢查清單，尤其是活動頁、產品頁這類會被大量轉發的頁面，發文前多花兩三分鐘重抓一次快取，遠比發出去之後再補救划算。

2. robots.txt把社群爬蟲擋在外面，標籤寫再好也沒用

我們診斷過的案例中，這正是那家工業儲存設備供應商最容易被忽略、卻也最致命的一個問題。系統掃描後發現，它的robots.txt裡有一條規則，把某個社群平台用來抓分享預覽的爬蟲整個擋掉了。這種情況下，Open Graph標籤寫得再完整都沒有意義，因為對方的爬蟲根本進不來讀取頁面內容，自然也讀不到寫在<head>裡的任何標籤。這類問題不會在畫面上顯示任何錯誤訊息，只會安靜地讓分享預覽長期是空的，很容易被誤判成標籤沒寫好，反覆修標籤卻始終沒有效果。這家供應商的行銷同仁其實早就發現分享預覽不對勁，也請網站廠商調整過標籤內容，但因為問題根源在robots.txt，標籤怎麼改都沒用，前前後後拖了好幾個月才被我們的系統掃描抓出真正的原因。

2.1 針對社群爬蟲下Disallow是常見的誤傷

那條規則長得像是對某個社群圖片抓取用的User-agent下了Disallow: /，等於告訴它「整站都不准爬」。這種設定通常不是故意的，而是早年為了擋掉某些不想要的流量或惡意爬蟲，順手把一整批User-agent都封鎖了，結果誤傷了負責抓分享預覽的爬蟲。我們的處理方式是把針對社群抓圖爬蟲的那條Disallow移除，讓它能正常讀取頁面，分享預覽才回得來。這類誤傷往往一放就是好幾年，沒人發現，因為它不影響一般使用者瀏覽，只有分享到社群時才會露餡。我們也看過另一種變形，是規則沒有直接寫Disallow: /，而是擋掉了圖片所在的資料夾路徑，結果爬蟲雖然能讀到頁面文字，卻抓不到og:image指定的那張圖，分享出來變成有標題、有描述，唯獨圖片是空的，同樣需要回頭檢查robots.txt裡跟圖片資料夾相關的規則。

2.2 檢查robots.txt時，我們會照兩個順序走

第一步，把每一條User-agent和它對應的Disallow列出來，逐條確認沒有哪一隻該放行的爬蟲被Disallow: /全站封鎖，搜尋引擎的主要爬蟲和社群平台的抓圖爬蟲都要放行。第二步，確認robots.txt本身回傳的是正常狀態，不是錯誤頁面或空白頁面。robots.txt是爬蟲進站看的第一份文件，這裡設錯，後面所有的優化都會被卡在門口進不去，不管標籤、內容、結構做得再好都沒用。這也是為什麼我們每次接手新專案，第一件事就是先看robots.txt，而不是急著看內容或標籤。順手也會確認裡面有沒有正確指向sitemap的路徑，雖然這和社群分享沒有直接關聯，但既然都在檢查這份文件，一併確認清楚，能省下之後另外排時間再查一次的工夫。

2.3 判斷是robots.txt問題還是標籤問題，順序不能顛倒

遇到分享預覽異常，我們的診斷流程分三步。第一步，用該社群平台的官方預覽或除錯工具丟入網址測試，看看回傳結果是完全抓不到內容，還是能抓到內容但顯示不對。第二步，如果連頁面基本內容都抓不到，幾乎可以斷定是robots.txt或伺服器層擋住了爬蟲，這時候該先查robots.txt和伺服器的存取記錄，而不是急著改標籤。第三步，如果爬蟲確實能讀到頁面，只是標題、描述或圖片不對，才回頭檢查標籤本身有沒有寫錯或動態綁定失效。順序顛倒的話，很容易在標籤上反覆修改卻始終沒有效果，浪費時間也找不到真正的原因。我們碰過的案例裡，不少人一發現分享預覽異常，直覺反應就是懷疑圖片檔案壞掉或標籤打錯字，花了大半天檢查程式碼細節，最後才發現問題出在最上游的robots.txt，如果一開始就先確認爬蟲進不進得來，其實幾分鐘就能鎖定方向。

3. referrer-policy重複設定與舊追蹤碼，該留該清怎麼判斷

這一段的兩個問題都不到致命等級，但都屬於放著不處理、日後會越滾越麻煩的類型。優先順序排在社群meta與robots.txt之後，但改版時我們會建議一起收尾，不要拖到下一次改版才處理，累積久了反而更難釐清哪些是刻意保留、哪些只是忘了刪。

3.1 同時送出兩個referrer-policy標頭，瀏覽器該聽哪一個

那家供應商的伺服器同時送出兩個referrer-policyHTTP標頭，一個是same-origin，一個是strict-origin-when-cross-origin。這個標頭控制瀏覽器發送請求時，要把多少來源網址的資訊帶給目標網站。同時給兩個不同的值，會讓實際行為變得不確定，也讓分析數據裡的來源判讀變得混亂，難以判斷某一筆流量真正的來源網頁。我們檢查這類問題時，通常會用瀏覽器的開發者工具直接看伺服器實際回傳的HTTP標頭，而不是只看程式碼裡寫了什麼，因為有時候問題出在CDN或反向代理層又疊加了一次設定，程式碼裡看起來只有一個值，實際送到瀏覽器手上的卻是兩個。我們的建議是只保留strict-origin-when-cross-origin，這是目前兼顧安全與可用性的主流設定，把same-origin那一條從伺服器設定裡移除即可。要提醒的是，這動的是伺服器層設定，得由掌握伺服器權限的一方來改，不是前端頁面能單獨調整的項目。

3.2 已經停止收集資料的舊追蹤碼，為什麼還是建議清掉

頁面裡還留著一段舊版分析工具的追蹤程式碼，那套服務其實已經停止收集資料一段時間，程式碼目前雖然被註解掉，實際上已經不會執行。從立即效益來看確實不急，但我們在實務上還是建議趁改版時一併移除，而不是留著註解。理由有兩個，一是減少無效程式碼堆積，降低日後維護時的誤解與困惑；二是萬一哪天有人手滑把註解解開，反而多送一個沒有意義的請求出去。清乾淨的好處是長期的，不是立即見效那種，但屬於值得順手處理的整理項目。我們在做程式碼盤點時，經常發現一個網站身上疊了三、四套不同時期導入的追蹤或分析程式碼，有些還在運作，有些早就停用，混在一起很難一眼分辨，每次改版都得重新確認一次哪些能動、哪些不能動，這種重複確認的時間成本，長期累積下來並不小。

3.3 誰該動哪一段，先分清責任再動手

我們在交付這類項目時，一定先把「誰有權限動」講清楚。像伺服器層的referrer-policy、還有由客戶自家帳號管理的追蹤程式碼，外部團隊通常沒有權限、也不該擅自更動，得交由客戶內部的資訊人員或帳號管理者處理。社群meta和robots.txt這類前端與站台設定，才是外部團隊能直接經手的範圍。把責任邊界先切清楚，才不會改到一半卡在權限，或是動到不該動的東西，也能避免事後追究時說不清楚是誰改了什麼。這一點在多方協作的專案裡特別重要，一個網站常常同時有網站代管商、行銷代理、內部資訊人員三方在動，如果沒有先講清楚誰負責哪一段，出問題時很容易互相猜測是對方動的手，反而拖慢排查速度。

4. 社群分享與爬蟲問題，怎麼排優先順序

把前面三段問題放在一起看，會發現它們的急迫程度並不一樣，不能用同一套速度去處理。我們的看法是先分清楚哪些問題會讓整件事完全失效，哪些只是影響品質，哪些純粹是收尾整理，再依序安排時間和人力。

4.1 三個層級的問題，先後順序怎麼定

robots.txt誤擋屬於「完全阻斷」等級，爬蟲進不來，後面所有優化都無從談起，這類問題永遠排第一。社群meta標籤缺漏或寫錯，屬於「品質受損」等級，爬蟲進得來，但呈現出來的內容不對，會影響點擊與分享意願，排第二順位處理。referrer-policy重複與舊追蹤碼，屬於「工程整潔」等級，不影響使用者看到的畫面，也不阻斷任何流程，可以排在確認前兩項都處理好之後再收尾。下面這張表整理了我們判斷優先順序時常用的架構。

問題類型	影響範圍	緊急程度	通常由誰處理
robots.txt誤擋爬蟲	收錄與分享全部失效	最高，立即處理	工程或站台管理端
社群meta標籤缺漏	分享預覽品質不佳	高，盡快處理	行銷或內容人員可自行調整
referrer-policy重複	分析數據判讀混亂	中，可排入改版一併處理	伺服器管理端
舊追蹤碼未清除	維護認知負擔	低，順手整理即可	負責網站程式碼的一方

4.2 什麼情況該找工程端，什麼情況內容人員能自己改

robots.txt和伺服器標頭這類設定，通常需要主機或站台的管理權限，得交給工程或維運端處理，一般內容編輯很難自行調整，也不建議在沒有把握的情況下亂改，因為一個字元寫錯就可能誤擋整站。相對的，如果網站是用常見的內容管理系統架設，搭配SEO外掛，社群meta標籤往往可以在後台介面直接填寫，不需要碰程式碼，行銷或內容團隊自己就能完成，不必每次都排工程資源。分清楚這條界線，可以省下不少來回溝通的時間。我們的習慣是在專案一開始就先盤點清楚，這個網站的社群標籤是能透過後台外掛直接管理，還是寫死在版型檔案裡，兩種情況需要的資源完全不同，前者行銷團隊當天就能自己調整完成，後者可能得排進工程team的開發排程，提前弄清楚能少走很多冤枉路。

4.3 上線後多久驗一次，驗什麼

我們建議把驗證排進固定流程，而不是等到有人反映分享有問題才處理。每次頁面標題、描述或主視覺圖片有重大調整時，就該用平台工具重新抓取一次，確認社群預覽同步更新。網站做過改版、換過主機或調整過CDN設定之後，建議額外檢查一次robots.txt，確認沒有在搬遷過程中不小心帶入新的封鎖規則。這種定期抽查花不了太多時間，但能避免問題長期潛伏，等到流量明顯下滑才被發現，那時候要回頭追查原因反而更費工夫。

5. 常見問題

5.1 Open Graph標籤都設定好了，分享出來為什麼還是顯示舊圖？

幾乎都是社群平台的快取還沒更新。每個主流平台都有官方的分享偵錯或預覽工具，把網址貼進去重新抓取，就能強制刷新快取。如果重抓後圖片還是不對，再回頭檢查og:image填的是不是絕對路徑網址，以及圖片本身能不能公開存取，沒有被權限或防盜連設定擋住。

5.2 robots.txt把爬蟲擋掉，和meta標籤沒被讀到有什麼關係？

關係非常直接。robots.txt是爬蟲進站前看的第一份文件，被Disallow擋掉的爬蟲根本讀不到頁面內容，自然也讀不到寫在<head>裡的Open Graph標籤。所以檢查社群預覽異常時，我們一定先看robots.txt有沒有誤擋，確認爬蟲放行之後，再回頭看標籤本身寫得對不對。

5.3 referrer-policy該設哪一個值比較安全？

目前多數情況我們會用strict-origin-when-cross-origin。它在同源請求時傳完整來源網址，跨網域請求時只傳網域、不傳完整路徑，同時照顧到分析需求和使用者的隱私。如果業務上對安全要求更高，可以考慮更嚴格的策略，但不要同時送出兩個不同的值，那只會讓實際行為變得不可預期。

5.4 舊的追蹤碼已經被註解了，還有必要花時間刪嗎？

從立即效益來看確實不急，被註解的程式碼不會執行，不影響現在的網站運作。但我們還是建議趁下次改版順手清掉，一來減少無效程式碼堆積，降低日後維護時的認知負擔；二來避免哪天有人不小心把註解解開，多送出一個沒有作用的請求。這屬於低優先度但值得順手完成的整理工作。

5.5 這些社群和標頭設定，對搜尋排名有幫助嗎？

根據我們的服務經驗，Open Graph和Twitter Card本身不算是直接的排名因素，它們影響的是社群上的點擊與分享意願，間接帶來流量與品牌曝光。robots.txt誤擋則會直接傷到收錄，是完全不同層級的問題。referrer-policy和舊追蹤碼偏向工程整潔面，不太會直接反映在排名上。我們會把它們放在各自對的優先順序裡處理：robots.txt先修，社群meta次之，標頭與追蹤碼最後收尾，各自解決各自該解決的問題，不混為一談。