URL Slug 設計指南：長度、關鍵字與中文的取捨

slug 是 URL 裡你唯一能完全控制的部分

一條 URL 的構成裡，網域、協定、路徑結構都輪不到內容作者說話，slug——那截標題變成的路徑——是唯一逐字由內容決定的。它同時服務三個讀者：搜尋爬蟲（詞形與相關性）、搜尋使用者（結果頁裡 URL 的可讀性影響點擊）、以及未來貼上這個連結的人。

設計 slug 的本質是四個決策：分隔符號、長度、關鍵字、語言。這篇逐個講清楚，最後給批次產生的動線。

決策一：連字號，幾乎無條件

Google 的官方 SEO 文件寫得很直白：用連字號分隔 URL 裡的詞，不要用底線。歷史上 Google 的分詞器把底線當詞內字元處理過（url_slug 可能被讀成一個詞 urlslug），連字號則始終是分隔符號。其他主流引擎與 CMS（WordPress 預設）都按連字號生態運作。底線的正確用途是檔名和程式識別字（snake_case）——那是另一個場景。

決策二：長度是資訊密度問題

slug 不是標題的完整複刻——標題為吸引點擊可以長，slug 只需要承載檢索訊號：

• 3-5 個詞、60 字元以內是經驗甜點：搜尋結果頁 URL 展示空間有限，超長會截斷
• 第 6 個詞之後的 SEO 權重趨近於零，把虛詞、停用詞、語氣詞刪掉
• 保留資訊量最大的實體詞：《The Beginner's Guide to Café Marketing in 2026》→ cafe-marketing-guide 而不是全標題轉寫

決策三：關鍵字放前面，但別堆

把內容的核心關鍵字放進 slug（儘量靠前），一個就夠。url-slug-design 優於 some-thoughts-about-url-and-slug-design。堆砌（url-slug-slug-url-generator）在演算法上是負面訊號。

決策四：中文的取捨

中文標題產生 slug 有兩條路線，各有適用場景：

1. 保留中文（中文標題-測試 形態）：URL 編碼後依然可收錄，現代瀏覽器網址列直接顯示原文字，中文使用者貼上分享無障礙——中文站（知乎、嗶哩嗶哩等）大量使用
2. 僅 ASCII（移除中文得純英文 slug）：面向國際受眾、技術社群（程式碼倉庫、文件站）更穩，避免編碼長度膨脹與跨系統顯示差異

沒有唯一正確答案，但站內要統一。混合輸入（標題裡夾英文產品名）在保留模式下中文與英文各成詞正常連接。

轉換規則速查

設計定了，轉換時的硬規則：

批次產生的動線

真實場景是一批標題：遷移部落格、給產品列表補 slug。slug 產生器支援逐行批次——標題清單一次貼上每行獨立產生；中文預設保留、「僅 ASCII」一鍵切純英文；分隔符號連字號/底線切換。產生的 slug 放進 URL 前用 URL 編碼工具預覽編碼形態；配套的大小寫轉換器處理變數命名場景的 camelCase/snake_case——命名的兩類需求一站覆蓋。

常見問題

URL slug 用連字號還是底線？

連字號。Google 官方文件明確把連字號當作詞分隔符號推薦使用，底線在部分系統（包括 Google 的分詞歷史行為）裡被當作詞的一部分，url-slug 和 url_slug 的權重傳遞可能不同。底線留給檔名與程式識別字場景。

URL slug 的長度控制在多少合適？

經驗值 3-5 個詞、60 個字元以內：足夠承載關鍵字，又不會在搜尋結果裡被截斷。超長 slug 的資訊增量極低（第 6 個詞之後的權重幾乎為零），把標題前幾個資訊量最大的詞留下即可。

中文標題應該產生中文 slug 還是英文 slug？

看站點受眾：中文站的中文 slug（URL 編碼後依然可收錄可點擊，瀏覽器網址列會顯示原文字）對中文搜尋是合法且常見的形態；面向國際受眾或技術社群的內容用英文 slug 更穩。「僅 ASCII」開關兩類需求都能覆蓋，混合輸入會保留中文並連接英文部分。

標題裡的變音符號和特殊字元怎麼處理？

變音符號折疊到基礎字母：café → cafe、Việt → viet（這是 slug 的通行規則，保住可讀性）；撇號直接刪除（Facebook's → facebooks）；其他特殊符號去除且不轉寫（$34B → 34-b，不會變成 dollar34b）。