URL 里出現中文、空格、大寫字母，是很多站点运营一段時間後才會注意到的問题。它通常不會让頁面立刻出状况，但当同一批内容存在多種寫法时，核對收錄就變得麻烦：日誌里、站点地图里、内鏈里各是一套地址，最後很难判断到底有多少個頁面真的進了索引。
先分清：URL 在传輸时會先被编碼
浏览器地址栏里顯示的中文，實际發出請求时通常已经變成 %E4%B8%AD 這样的百分号编碼。搜尋引擎抓取时看到的也是编碼後的形式。所以同一個中文地址，可能以原始字符形式出現在你的連結里，以编碼形式出現在服務器日誌里。這两種寫法指向同一個资源，不算两個頁面，排查时不要把它們当成重复 URL 去計數。
需要留意的是编碼方式本身要稳定。同一個字用 UTF-8 编碼是固定结果，但如果站点中途換過编碼，或者部分連結手工拼错了百分号序列，就可能真的产生一個無法解析的地址。
大小寫：取决于服務器，而不是搜尋引擎
URL 的大小寫敏感性由服務器和框架决定。Windows 上的 IIS 預設不区分，多數 Linux 环境区分。/Article/1 和 /article/1 在区分大小寫的服務器上是两個不同地址，返回的可能是一個頁面加一個 404，也可能两個都是 200，還可能其中一個做了跳轉。
麻烦的地方在于，搜尋引擎只是按照你服務器返回的结果来處理。如果两種寫法都返回 200，它就有理由把它們当成两個 URL 分別抓取。统一寫法比事後补救省事得多：站内連結、導航、站点地图、canonical 尽量使用同一套小寫路径。
大小寫混乱的常见来源
- 程序自動生成路径时保留了标题或分類的原始大小寫；
- 編輯手工填寫内鏈，凭记忆敲路径；
- 舊版頁面用大寫，改版後统一小寫，但舊連結没有做跳轉；
- 外部連結、论坛、社交平台上流传的地址寫法不一致。
空格、下划线和连字符
URL 里出現空格並不合适，虽然浏览器會自動轉成 %20，但複製、粘贴、被第三方系統處理时容易断掉。用连字符代替空格是更常见的做法，下划线也可以用，只是连字符在可讀性和連結识別上更普遍一些。
關键不在于選哪一種，而在于不要同一批頁面两種都用。如果 /site-map 和 /site_map 同时存在且都能打開，那就是两個地址。
结尾斜杠與扩展名
带斜杠和不带斜杠的寫法，在很多服務器上是两個不同路径。/about 與 /about/ 都可能返回 200。這时要么用 301 把其中一種固定跳到另一種，要么用 canonical 指明首選地址。只靠内鏈统一往往不够，因為外部連結不受你控制。
是否保留 .html、.php 這類扩展名，本身不影响收錄。真正影响的是同一個頁面能否通過带扩展名和不带扩展名两種地址打開。如果两種都返回 200 且内容一致，就需要考虑合並。
參數的顺序與冗余參數
?id=12&page=1 和 ?page=1&id=12 在大多數服務器上返回同样的内容，但對搜尋引擎来说，URL 字符串不同就是不同地址。常见的處理方式是在服務器或 CDN 层做參數排序，或者用 canonical 指向規范形式。
另外，那些對内容没有影响、只是用来标记来源的參數（會话 ID、追踪碼），最好不要出現在站内連結里，否則每分享一次就可能多出一個地址。
排查與统一的顺序
- 從服務器日誌或索引狀態报告中，導出一段時間内被訪問的 URL 列表；
- 按路径分组，找出指向同一内容的多套寫法；
- 确定每一组里的首選地址，其余寫法做 301；
- 检查站内連結與站点地图，確認只出現首選地址；
- 给頁面补上 canonical，作為外部連結寫错时的兜底；
- 改完後观察一段時間，確認舊寫法不再被频繁抓取。
如果只是個別頁面的小寫大寫不一致，不必大動干戈；真正值得處理的是那些已经产生多個 200 响應、並且都被抓取過的地址。
几個常见誤区
- 以為大小寫問题搜尋引擎會自己判断。它按照服務器返回的结果判断，服務器不区分，它就没有理由合並。
- 只看浏览器地址栏。浏览器會帮你补全或隐藏编碼，日誌和源碼里的寫法才是抓取时看到的样子。
- 做了跳轉就不再检查。重定向鏈過長或跳错目标，會让抓取路径變复杂，定期抽查仍有必要。
總结一下：URL 寫法問题大多不致命，但會持續消耗核對收錄資料的成本。把编碼、大小寫、斜杠、參數這几項统一到一套規則上，並让站内所有出口都遵守這套規則，後續看索引資料时會轻松很多。