SEO 友善的網址結構：路徑、參數與無副檔名網址
網址是使用者與搜尋引擎 共同的第一印象，也是 重複內容 最常見的來源。它的麻煩之處在於：上線之後很難改，改網址就要處理轉址，處理不好就掉流量。
所以網址結構值得在專案初期就決定好。
好網址的四個特徵
✗ https://example.com/p?c=12&id=8891&ref=nav&lang=zh
✓ https://example.com/shoes/running-shoes| 特徵 | 說明 |
|---|---|
| 可讀 | 看網址就知道會連到什麼內容 |
| 簡短 | 層級不超過三層，路徑不超過一行 |
| 穩定 | 內容改標題不必改網址 |
| 一致 | 全站遵循同一套規則 |
連字號，不要底線
這兩個對搜尋引擎意義不同
| 寫法 | 搜尋引擎怎麼看 |
|---|---|
running-shoes | 兩個詞：running 與 shoes |
running_shoes | 一個字串：running_shoes |
連字號被視為 字詞分隔，底線則被當成字元的一部分。新專案一律用連字號。
其他字元的處理：
| 字元 | 建議 |
|---|---|
| 大寫字母 | 一律小寫（伺服器可能區分大小寫） |
| 空白 | 換成連字號 |
| 連續連字號 | 合併成一個 |
| 檔案副檔名 | 拿掉（見 無副檔名網址與尾斜線） |
層級不要太深
✗ /category/subcategory/sub-subcategory/type/product-name
✓ /category/product-name目錄結構不必反映網址結構
最常見的誤解是「網址層級要對應資料庫的分類階層」。實際上不必，商品可以直接掛在 /products/名稱，分類關係用 麵包屑 表達就好。
網址層級深的實際壞處：字串變長、容易超出搜尋結果的顯示寬度、分類改名時要處理轉址。
不過網址階層與麵包屑保持一致還是有價值的，它讓「這一頁在網站的哪個位置」這件事在三個地方（網址、麵包屑 HTML、結構化資料）說法相同。
中文網址的取捨
中文網址在瀏覽器上會顯示成可讀的中文，搜尋引擎也支援。但複製出來是這樣：
https://example.com/文章/網頁效能優化
↓ 實際傳輸的形式
https://example.com/%E6%96%87%E7%AB%A0/%E7%B6%B2%E9%A0%81%E6%95%88%E8%83%BD%E5%84%AA%E5%8C%96| 中文網址 | 英文或拼音 | |
|---|---|---|
| 瀏覽器顯示 | 可讀 | 可讀 |
| 複製貼出 | 一長串編碼 | 正常 |
| 貼到不支援的環境 | 可能損壞 | 安全 |
| 分享到通訊軟體 | 部分軟體會截斷 | 安全 |
| 後端與日誌處理 | 需注意編碼 | 單純 |
內容型網站建議用英文
不是因為 SEO，而是因為 可攜性。編碼後的網址在貼到程式碼、寫進設定檔、出現在日誌裡時都很難處理。
這個文件站的做法就是全部用英文 slug：/seo/indexing-url-structure。
無副檔名網址與尾斜線
拿掉副檔名
✗ /about.html
✓ /about副檔名洩漏了實作技術（.php、.aspx、.html），而且換技術就要改網址。多數框架有現成的設定：
多數靜態網站產生器與框架都有對應的設定項，名稱不一（cleanUrls、trailingSlash、 trailing_slash⋯），效果都是把 /about.html 對到 /about。純靜態主機沒有這個選項時， 在伺服器層改寫也可以：
# 對外只露出無副檔名的網址，內部才補回 .html
try_files $uri $uri.html $uri/ =404;尾斜線只能有一種
決定一種，然後把另一種 永久轉址 過來：
# 選擇「不加尾斜線」，把帶斜線的轉走
rewrite ^/(.*)/$ /$1 permanent;決定之後，這四個地方都要照著寫：
| 位置 | 要一致 |
|---|---|
canonical | 指向選定的版本 |
| sitemap | 只列選定的版本 |
| 站內連結 | 全部用選定的版本 |
| 轉址 | 另一種永久轉到選定的版本 |
同一組要統一的還有：
| 項目 | 選一種並轉址 |
|---|---|
| 通訊協定 | https（http 轉過來） |
| www 前綴 | 有或沒有，選一種 |
| 大小寫 | 全小寫 |
查詢參數
參數是爬取預算的最大殺手。三種排序方式，加上兩個各有五個選項的篩選條件，就是七十五種組合，每一個都是獨立網址。
| 參數類型 | 例 | 處理方式 |
|---|---|---|
| 內容決定性 | ?page=2、?id=123 | 保留，正常收錄 |
| 排序與篩選 | ?sort=price、?color=red | canonical 指向無參數版本 |
| 追蹤 | ?utm_source=fb、?fbclid= | canonical 指向無參數版本 |
| 工作階段 | ?sessionid=abc | 不該出現在網址裡 |
自我參照的 canonical 就能解決大半
/products?sort=price 這一頁輸出的 canonical 若指向 /products，那些排序變體就不會被當成獨立頁面。
爬取預算的問題則用 robots.txt 處理：
Disallow: /*?sort=
Disallow: /*?filter=不要用 robots.txt 擋掉「內容決定性」的參數
擋掉 ?page= 會讓分頁列表的第 2 頁以後完全爬不到，那些商品就再也不會被發現。分頁的處理見 分頁與無限滾動的爬取 。
網址包含日期嗎
/blog/2024/01/15/post-title
/blog/post-title| 含日期 | 不含日期 | |
|---|---|---|
| 內容時效性一目了然 | 是 | 否 |
| 舊文章看起來過時 | 是（缺點） | 否 |
| 更新內容後 | 日期會誤導 | 不影響 |
| 網址長度 | 長 | 短 |
檢查清單
| 項目 | 標準 |
|---|---|
全站統一 https | 必備 |
| www 與非 www 統一並轉址 | 必備 |
| 尾斜線統一並轉址 | 必備 |
| 網址全小寫 | 必備 |
| 用連字號而非底線 | 建議 |
| 沒有副檔名 | 建議 |
| 層級不超過三層 | 建議 |
追蹤與排序參數有 canonical 處理 | 必備 |
| 網址階層與麵包屑一致 | 建議 |
| 常青內容的網址不含日期 | 建議 |
常見問題
網址裡放關鍵字有幫助嗎？
有，但影響很小。網址中的字詞是搜尋引擎理解頁面主題的線索之一，也會在搜尋結果中被標成粗體。真正的價值在於可讀性：使用者一看網址就知道會連到哪裡，比較願意點擊與分享。
連字號和底線有差嗎？
有。搜尋引擎把連字號視為字詞分隔，底線則被當成字元的一部分。所以用連字號寫的網址會被拆成獨立的詞，用底線寫的會被當成一個長字串。新專案一律用連字號。
中文網址可以用嗎？
可以，搜尋引擎支援，瀏覽器也會顯示成可讀的中文。但複製出來時會變成一長串百分號編碼，貼到不支援的環境會很難看，也容易在傳遞過程中損壞。內容型網站建議改用英文或拼音。
尾斜線要加還是不加？
兩種都可以，但全站必須一致，並把另一種永久轉址過來。加與不加對伺服器來說是兩個不同的網址，同時存在就會產生 重複內容 。決定哪一種之後，網站地圖、內部連結與正規網址都要照著寫。
查詢參數會造成問題嗎？
會。排序、篩選與追蹤參數的組合可能產生數以萬計的網址變體，每一個都被當成獨立頁面，大量浪費爬取預算。處理方式是自我參照的正規網址加上封鎖不必要的參數路徑。
延伸閱讀
參考資料：Google 搜尋中心：網址結構最佳做法