URL 是頁面的地址，也是蜘蛛、用戶和統計工具理解站点的第一层线索。很多站点在早期為了快速上线，栏目路径随手起名，後来内容越加越多，就出現同一類文章散落在 /news/、/article/、/zixun/ 几個前缀下，或者日期、ID、參數混在一起。命名不規范不會立刻让網站出問题，但會让栏目規划、内鏈维護、日誌分析和改版迁移都變得麻烦。下面是一份偏保守的 URL 命名自查清單，适合在栏目新建、内容批量導入和站点改版前過一遍。
一、先把已有 URL 拉出来看一遍
不要凭印象判断。從 sitemap、站内搜尋、資料库或服務器日誌中導出主要 URL，按前缀和目錄层級分组，看看是否存在這些情况：
- 同一類内容用了多個前缀，比如新闻栏目既有 /news/ 也有 /article/。
- 大小寫混用，/News/ 和 /news/ 同时存在，服務器却区分大小寫。
- 路径里带中文、空格或未编碼字符，複製和分享时容易出错。
- 無意义的數字 ID 或哈希串，用戶看不出頁面主题。
- 參數過多，同一個列表頁因為排序、篩選參數生成大量近似地址。
- 层級過深，重要内容被放在四层甚至五层目錄之後。
這一步的目的不是马上改，而是先知道問题集中在哪些栏目。
二、命名規范定几條底线
規范不需要太复杂，但最好寫下来，让後来的人有據可依。可以參考以下几條：
- 尽量短且可讀。 用少量英文單词或拼音，能看懂頁面主题即可，不必把标题全塞進去。
- 统一小寫，用连字符分隔。 避免下划线、空格和大小寫混用，减少服務器和跳轉层面的歧义。
- 目錄层級保持克制。 一般栏目到内容頁控制在两到三层，太深不利于用戶返回，也不利于蜘蛛理解。
- 避免無意义 ID 作為唯一路径。 如果系統必须带 ID，可以放在目錄之後，但不要让 ID 成為用戶唯一能看到的线索。
- 參數能静態化就静態化。 列表頁的排序、篩選參數尽量收敛，別让每個篩選组合都變成獨立入口。
- 定下来就別频繁改。 URL 的稳定性比“看起来更漂亮”更重要，改一次就要承担一次映射和跳轉成本。
三、URL 要和栏目结构對齐
URL 命名不是孤立的，它通常跟着栏目規划走。新建栏目时，先确定這個栏目在站点里承担什么角色：是長期更新的主栏目，還是阶段性专题，還是聚合頁。主栏目适合用稳定、简短的前缀，比如 /guide/、/review/；阶段性专题可以用 /topic/ 加主题词，並在結束後保留或归档，而不是直接刪除。聚合頁則要谨慎，避免把不同栏目的内容混在一個没有明确主题的路径下。
如果栏目規划本身在變，URL 却已经铺開，就會出現“内容還在，路径已经没人维護”的情况。此时要么調整内鏈和導航，要么把舊路径保留為入口，不要让頁面變成孤岛。
四、改動前先做映射和重定向
一旦决定調整 URL，不要直接在服務器上重命名目錄。先做三件事：
- 整理舊 URL 到新 URL 的映射表，確認一一對應，避免多條舊連結指向同一個新頁面时产生冲突。
- 為舊地址設定 301 跳轉，並检查跳轉鏈是不是只有一跳，不要舊跳新、新又跳另一個。
- 更新站内連結、導航、sitemap 和 feed，让蜘蛛下次抓取时直接看到新地址。
改完後观察一段時間日誌，看舊地址是否仍有大量訪問、跳轉是否正常、新地址是否開始被正常抓取。如果有異常，優先检查映射表和服務器規則，而不是反复提交。
五、日常维護可以检查這些点
- 新增栏目时，先確認前缀是否和現有栏目重复或含义冲突。
- 批量導入内容前，检查系統生成的 URL 是否符合規范，必要时在後台配置規則。
- 定期抽查站内連結，看看有没有指向舊路径或參數地址的内鏈。
- 在統計工具中按目錄分组，观察各前缀的流量和收錄變化，異常时回头查命名和结构。
- 站点改版前，把 URL 迁移列入检查清單，而不是等上线後再补救。
URL 命名規范不會直接带来流量，但它能减少重复入口、降低维護成本，也让栏目規划和資料統計更容易對齐。先把規則定清楚，再让内容和功能往上長，通常比事後修补更省事。