URL 是頁面的门牌号。用戶複製分享要用它，搜尋引擎抓取和收錄要用它，後台排查問题也要靠它對上号。可現實中，很多站点的地址是随手上线时生成的，栏目調整几轮之後就變成一堆拼不出含义的字符串。等到需要改版、迁移或者排查流量異常时，這些地址就成了最难處理的遗留問题。
這篇自查清單不谈跳轉配置，只聊最前面的一步：地址本身怎么起名、目錄怎么分、哪些信息不该寫進 URL。
一、命名規則先统一
規則不需要复杂，但必须全站一致。
- 分隔符统一用短横线。英文短语之間用 - 连接，避免下划线、空格和加号。下划线在部分场景下不顯示或被识別成其他字符，複製粘贴时也容易出错。
- 尽量全小寫。服務器對大小寫的處理並不一致，有的环境 /News 和 /news 是两個地址，會凭空多出一份重复内容。
- 不用中文和特殊符号。中文地址在複製、分享、日誌分析时容易出現编碼差异，出問题时排查成本高。
- 長度控制。能表達大意即可，不要把整個标题塞進去，也不要堆關鍵詞。
二、目錄层級與栏目對應
理想狀態下，看地址就能猜到内容归在哪個栏目。常见做法是：栏目頁 /tech/，子栏目 /tech/server/，文章 /tech/server/xxx.html 或直接挂在栏目下。
层級別太深
三到四层基本够用。层級過深會让地址變長，也给後期改版增加负担——每動一次目錄，下面所有頁面都要跟着處理。
也別全都平铺在根目錄
所有文章都放在根目錄，短時間看着简單，數量上去之後既不好管理，也没法通過目錄看出内容分類。到那时再想补目錄，改動量會大得多。
一個可以随时問自己的問题：如果只看到這條地址，能不能大致说出它讲什么、属于哪一類内容？
三、要不要把日期和 ID 寫進地址
這是两種常见做法，各有代價，關键是選一種並坚持。
- 带日期，例如 /2024/05/xxx.html。适合新闻、公告這類时效性明顯的内容，缺点是長期内容會顯得過时，也让栏目结构被日期切碎。
- 带 ID，例如 /article/1024.html。稳定、不會因為改标题而變化，但對用戶不友好，看地址不知道内容是什么。
- 混合，例如 /article/1024-seo-basics.html。ID 保證唯一，後面的词帮助阅讀，是折中較多的選擇。
需要提醒的是，标题改動时，如果地址里嵌了标题词，就會出現地址和内容不一致的情况。是否跟着改，要提前想清楚：改就要處理跳轉和已有連結，不改就接受這個偏差。
四、參數與動態地址
篩選、排序、分頁這些功能往往會产生带參數的地址。可以让功能正常使用，但要把主要入口指向形態干净的那一版，避免同一個列表被不同參數组合拆成很多地址。哪些參數應该保留、哪些應当被合並或屏蔽，最好在栏目上线时就定下来，而不是等日誌里出現大量重复路径後再补救。
五、上线前的地址自查清單
- 全站分隔符是否统一，有没有混用下划线和短横线。
- 是否存在大小寫不一致、可訪問多個版本的頁面。
- 目錄层級是否超過四层，能否合並。
- 地址里是否含無意义參數、會话 ID、跟踪碼。
- 结尾斜杠是否统一，带與不带是否都能訪問到同一頁面。
- 地址是否與栏目结构大致對應。
- 新頁面命名是否和已有頁面保持同一套風格。
六、變更要留记錄
地址一旦對外發布，就尽量不要再動。确實需要調整时，先整理出舊地址清單，再准备對應的跳轉映射，並在相当長一段時間内保留這些跳轉——外部連結、用戶收藏和缓存都不會因為你改版而同步更新。运维层面，最好有一條简單的變更记錄：什么时候改的、改了哪些路径、映射關系放在哪里。下次排查时，這份记錄比翻聊天记錄有用得多。
URL 規范不是一次性任務，更像是一種习惯。每次新建栏目、上线頁面时顺手遵守，比事後成批修正省力得多。