文章 slug 與 SEO 友善網址怎麼設計：不要只剩 /post/1
很多內容站一開始都會直接用文章 ID 當網址，例如 /post/1、/post/2、/post/3。這種方式當然能用，而且對開發初期很方便。但只要你開始在意可讀性、分享、SEO 與後續維護，slug 這件事通常很快就會變得重要。 先講 slug 是什麼。你可以把它理解成文章的網址名稱，也就是把標題轉成一段適合放在網址裡的識別字串。例如一篇...
很多內容站一開始都會直接用文章 ID 當網址，例如 `/post/1`、`/post/2`、`/post/3`。這種方式當然能用，而且對開發初期很方便。但只要你開始在意可讀性、分享、SEO 與後續維護，slug 這件事通常很快就會變得重要。
先講 slug 是什麼。你可以把它理解成文章的網址名稱，也就是把標題轉成一段適合放在網址裡的識別字串。例如一篇文章標題是「Flask 小站 vs Node.js 小站」，slug 可能會是 `flask-vs-nodejs-small-site`。這樣網址就會從 `/post/17` 變成更有語意的形式。
slug 的第一個好處是可讀性。當使用者看到網址時，大概就能猜到這篇文章在講什麼，而不是只看到一個數字。第二個好處是分享。當文章被貼到社群、訊息或筆記裡，有語意的網址通常更容易辨識。第三個好處是對 SEO 比較友善，因為網址本身也是搜尋引擎理解頁面的一部分。
但 slug 也不是只要加一個欄位就好，它還牽涉到幾個設計問題。
第一，slug 應該要唯一。因為兩篇文章不能用同一個網址。
第二，slug 最好穩定。你不能每次改標題就把網址完全洗掉，否則舊連結很容易失效。
第三，slug 要考慮語言。中文標題要不要直接進網址，還是轉拼音、英文或手動自訂，這都需要決定。對很多站來說，最務實的做法通常是後台提供一個可手動編輯的 slug 欄位，而不是完全自動化。
第四，當你從 `/post/1` 轉向 `/post/<slug>` 時，還要想資料庫查詢方式、舊網址轉址、canonical 與 sitemap 的更新。也就是說，slug 其實會連到整個內容站的網址策略。
如果把 slug 的核心目的濃縮成一句話，大概就是：
讓網址可讀、可分享、可維護對第一版小站來說，先用 ID 完全沒問題；但如果你已經開始經營內容、在意搜尋引擎、希望文章網址更像真正的內容站，那 slug 幾乎都是值得補的。
所以比較好的思路通常不是一開始就過度追求完美網址，而是在網站開始穩定後，逐步把文章從純 ID 網址升級成更有語意的結構。這樣讀者、搜尋引擎和未來的你，都會輕鬆很多。