為什麼一堆推文的按鈕都不見了?
摘要提示
- 現象: 網站多篇文章的推文數字與按鈕顯示突然消失。
- 交叉檢查: 到推推王查詢發現推文紀錄仍存在，證實非資料遺失。
- 回連異常: 從推推王點回原文出現錯誤，顯示連結對不上。
- 問題根源: 發現本站實際文章網址已與推推王紀錄的網址不同。
- 版本升級影響: 近期升級 BlogEngine.NET 從 1.3 到 1.4 為關鍵變因。
- SLUG 規則變更: 1.4 版調整自動產生 SLUG 的規則（移除逗號、合併多重連字號）。
- 具體差異: 原本 URL 中的 — 被新規則壓縮為 -，導致舊連結失效。
- 影響範圍: 舊外部書籤與社群服務指向舊 URL，造成推文按鈕偵測不到。
- 解決方式: 因受影響篇數不多，作者選擇到推推王手動修改連結。
- 經驗教訓: 升級應注意 URL 相容性，建議實作 301 轉址或固定 SLUG 策略。
全文重點
作者發現網站上原本顯示的推文數字與按鈕突然消失，直覺懷疑網站或外部服務是否出問題。為驗證，他前往推推王查詢歷史推文紀錄，發現各篇文章的推文數仍在，顯示資料未遺失。接著他嘗試從推推王點回原文，卻發生連結錯誤，進一步比對網址後確認，推推王所記錄的文章 URL 與網站目前實際的文章 URL 已經不一致。
深入追查後，作者聯想到前幾天才將 BlogEngine.NET 從 1.3 升級到 1.4，於是用版本控制比對程式碼，發現 1.4 版對自動產生 SLUG（文章網址尾段）的規則有變更。具體而言，新版會移除逗號，並將連續多個連字號 –、— 壓縮為單一連字號 -。在此案例中，某篇文章原本 URL 中含有三個連字號 —，升級後自動被壓縮成單一 -，導致舊外部連結（如推推王儲存的 URL）指向不到正確頁面，因此網頁上的推文數偵測也跟著失效，看起來就像推文按鈕「不見了」。
原本作者打算寫程式批次修復，但因實際受影響的文章不多，最後選擇直接到推推王手動修改連結以快速解決。事件結束之餘，他也暗示了升級平台時的重要教訓：任何會影響 URL 結構的變動，都可能造成外部引用斷鏈與社群計數遺失，最佳做法是預先規劃 URL 相容性，例如維持舊 SLUG 規則、建立永久轉址（301 redirect）、或提供對舊規則的路由相容層，避免既有流量與社群訊號受損。
段落重點
為什麼一堆推文的按鈕都不見了?
作者注意到網站多篇文章的推文數字消失，先到推推王確認推文仍存在，排除外部服務資料遺失的可能；從推推王回連時發現連結錯誤，進一步比對得知本站實際 URL 已變更。追查原因鎖定近期將 BlogEngine.NET 從 1.3 升級至 1.4，並透過程式碼比對確定新版改動了 SLUG 產生規則：會移除標點（如逗號）與將連續多個連字號壓縮成一個。這使得原本含有 — 的舊網址在升級後變成 -，導致外部書籤與社群服務的既有連結失效，進而影響推文按鈕與計數顯示。由於受影響文章不多，作者選擇到推推王手動更新連結，迅速了結問題。同時也提醒未來進行系統升級或 URL 規則調整時，應規劃 301 轉址或維持舊規則相容，以避免斷鏈與社群數據流失。
資訊整理
知識架構圖
- 前置知識：
- 基本網站架構與網址（URL/Slug）概念
- 部落格/內容管理系統（CMS，如 BlogEngine.NET）的文章永久連結設定
- 版本升級對行為變更的可能影響
- 社群書籤/分享服務的計數依賴「固定網址」
- 版本控管工具（如 VSS）用於程式碼或設定差異比較
- 核心概念：
- Slug 產生規則：文章標題如何轉換成 URL 片段，符號處理（逗號、連字號折疊）
- 永久連結穩定性：URL 穩定對於分享計數、SEO 與外部連結的重要性
- 版本升級行為改變：BlogEngine.NET 1.3 -> 1.4 對 slug 規則的調整造成連結不一致
- 追蹤與比對方法：透過外部服務（推推王）與站內實際頁面比對，並用版本控管比較差異
- 修復策略：調整外部服務的連結、或站內提供對應（如維持舊 slug、301 轉址、或批次修補）
- 技術依賴：
- CMS 的 slug 產生器依賴標題字串處理（移除標點、連字號正規化）
- 分享計數系統依賴 URL 精確匹配（URL 改變即視為不同內容）
- 版本控制工具協助定位升級前後程式差異
- 網站層面（IIS/應用程式）可配置 URL Rewrite/301 Redirect 作為相容層
- 應用場景：
- 升級部落格/網站平台後，舊文章分享按鈕或計數消失
- 更改永久連結樣式（Permalink schema）導致外部連回失效
- 多語系或標點豐富標題的 slug 正規化導致衝突
- 移轉網站域名或路徑結構時的計數與 SEO 保留
學習路徑建議
- 入門者路徑：
- 了解什麼是 slug 與永久連結，為何必須穩定
- 認識分享/書籤計數與 URL 綁定的關係
- 學會比對實際頁面 URL 與外部平台記錄的 URL 是否一致
- 進階者路徑：
- 研究 CMS 的 slug 產生規則與可配置選項（符號處理、大小寫、空白轉換）
- 使用版本控管工具比較升級前後的實作差異
- 熟悉 301 轉址與 URL Rewrite 規則，規劃自動相容
- 實戰路徑：
- 盤點全站既有 URL 與外部連結（含分享平台索引）
- 設計對映表或規則（如多連字號 -> 單連字號、移除逗號）並配置 301 轉址
- 驗證修復：抽樣測試分享平台回連、搜尋引擎收錄與計數恢復情況
- 擬定升級流程與回歸測試清單，避免再次發生
關鍵要點清單
- Slug 定義與重要性: Slug 是文章 URL 的核心識別，影響分享計數與 SEO（優先級: 高）
- 計數與 URL 綁定: 社群分享/書籤計數與精確 URL 綁定，變更即視為新頁面（優先級: 高）
- 升級風險管理: 平台升級可能改變 slug 規則，需事前評估與測試（優先級: 高）
- 規則變更範例: 逗號移除、連續 “—” 正規化為 “-” 導致舊連結失效（優先級: 高）
- 差異比對技巧: 使用版本控管（如 VSS）比較 1.3 與 1.4 的 slug 產生程式（優先級: 中）
- 外部平台驗證: 透過分享平台（如推推王）查歷史 URL 與計數，對照站內實際 URL（優先級: 中）
- 快速修復策略: 少量案例可於外部平台手動改鏈結（優先級: 中）
- 可擴展修復: 大量案例應透過 301 轉址或 URL Rewrite 自動對應（優先級: 高）
- 301 轉址效益: 保留 SEO 與使用者體驗，逐步讓搜尋引擎更新索引（優先級: 高）
- Slug 規格治理: 制定與凍結 slug 規則，減少後續變動（優先級: 中）
- 升級前清單: 盤點舊規則範例、建立測試案例、預備回退方案（優先級: 高）
- 標點與字元處理: 明確定義標點移除與連字號折疊策略，避免斷鏈（優先級: 中）
- 監控與告警: 升級後監控 404、分享計數異常、引用來源錯誤（優先級: 中）
- 資料對映表: 若規則不可逆，維護舊->新 URL 對映表以便轉址（優先級: 中）
- 文件化與溝通: 將規則與變更紀錄文件化，對內外部團隊同步（優先級: 低）
