Slug 生成器

把任意標題轉換成乾淨的 URL slug。自動去除重音、可選分隔符、控制大小寫與長度,支援去停用詞和保留 Unicode。

把標題轉換成乾淨、URL 安全的 slug。 重音字元會摺疊為純 ASCII,標點被去除,單詞用你選擇的分隔符連線。通過選項可以控制大小寫、限制最大長度或去掉常見停用詞。

什麼才算一個好的 URL slug

slug 的意義

slug 是 URL 中用來標識頁面、且人類可讀的那一段:/blog/how-to-cache-resumes-in-redis 裡的 how-to-cache-resumes-in-redis。它用一段人能讀懂、能記住、點選前就能判斷內容的文字,取代了不透明的數字 ID。搜尋引擎會在結果中展示 URL,因此一個描述性強的 slug 既讓讀者安心,也強化了頁面的主題訊號。

slug 應遵守的規則

只使用小寫 ASCII 字母、數字和一種分隔符。這一條同時避開了三類問題:多數伺服器上 URL 的路徑部分割槽分大小寫,/About/about 是兩個不同資源,大小寫混用等於給自己製造重複內容;百分號編碼會讓任何非 ASCII 字元變長三倍,複製成純文本後極難閱讀;而空格根本不被允許,只會變成 %20+

短橫線是約定俗成的分隔符。Google 多年來明確表示它把短橫線當作詞分隔符、把下劃線當作詞連線符,也就是說 cache_redis 可能被當成一個詞,而 cache-redis 明確是兩個詞。除非有特殊理由,就選短橫線。

音譯還是保留 Unicode

預設情況下本工具會把帶重音的字元摺疊為最接近的 ASCII 形式:éeßssłl。實現方式是先用 Unicode NFD 規範化分解文本、去掉組合標記,再用一張查詢表處理分解無法覆蓋的連字和特殊字母。

保留 Unicode 也是完全正當的選擇。國際化 URL 在所有現代瀏覽器裡都能正常工作,對使用該語言的讀者可讀性高得多 —— 中文或俄文標題被音譯成 ASCII 後往往毫無意義。代價是原始 URL 裡會出現百分號編碼的位元組,粘進郵件或終端時看起來相當嚇人,而且部分老舊工具仍會處理出錯。如果你的受眾讀得懂該文字,就開啟「保留 Unicode 字母」;如果 slug 必須在各種未知系統間流轉,就保持關閉。

長度與停用詞

技術上沒有值得擔心的長度限制,但超過大約 60 個字元的 slug 會在搜尋結果裡被截斷,分享起來也不方便。截斷最好落在詞邊界上而不是詞中間,本工具的長度選項就是這麼做的。

去掉停用詞(theaofand)能在幾乎不損失含義的前提下縮短 slug。這是風格選擇而非排名因素,現代搜尋引擎完全有能力忽略它們。但要小心那些停用詞本身承載意義的標題 —— 把 "The Who" 或 "To Be or Not to Be" 的停用詞去掉,整個短語就毀了。

穩定性比完美更重要

slug 一旦釋出並被連結,改動它就會打斷所有入站連結,除非你配置重定向。一個上線一年、略有瑕疵的 slug,幾乎總是好過一個更乾淨但會讓你丟掉外鏈的新 slug。上線前定好格式,之後就別動了。

開源說明:音譯基於 Unicode NFD 規範化加一張小型連字表,直接實現,未使用第三方庫。

常見問題

用短橫線還是下劃線?
用短橫線。搜尋引擎把短橫線當作詞分隔符、把下劃線當作詞連線符,所以短橫線 slug 會被拆成獨立單詞。而且下劃線在連結預設的下劃線樣式下幾乎看不見。
slug 一定要小寫嗎?
是的。多數伺服器上 URL 的路徑部分割槽分大小寫,/About 和 /about 可能指向兩個不同頁面,從而分散排名訊號。強制小寫能徹底消除這類問題。
可以用中文等非英文字元嗎?
可以,現代瀏覽器完全支援,而且對母語讀者可讀性高得多。代價是原始 URL 會變成百分號編碼,在瀏覽器之外顯示時比較雜亂。如果這個取捨適合你的受眾,就開啟「保留 Unicode 字母」。
slug 多長合適?
長到能說明內容,短到一眼能讀完。大約三到六個詞、或 60 個字元以內,能在多數搜尋結果裡完整顯示。
要不要去掉停用詞?
通常無害,還能讓 slug 更清爽,但這只是外觀選擇,對排名沒有幫助。當停用詞是關鍵成分時(如樂隊名或引語)就別去。
以後還能改 slug 嗎?
只有配上從舊 URL 到新 URL 的 301 重定向才安全。否則你會失去所有已有連結和收藏,以及積累的排名訊號。儘早確定格式並保持不變。