浏览器很宽容。地址栏里輸入带中文、带空格的 URL，敲回车照样能打開，複製粘贴到別處也看着正常。但這種宽容只存在于浏览器界面上。当同一個地址被寫進内鏈、sitemap、canonical 标簽或者提交入口时，寫法稍有差別，就可能變成蜘蛛眼里的另一個 URL。
浏览器帮你补了什么
URL 規范里允许直接出現的字符是有限的。中文、空格、以及一部分符号並不在其中，需要做百分号编碼（percent-encoding）才能成為合法地址。浏览器在發請求之前會自動完成這一步：空格變成 %20，一個中文字通常變成三個字节的编碼，比如 %E4%B8%AD。
問题就出在這個自動轉換上。你在頁面里手寫連結、在後台配置跳轉、或者從 Excel 里複製一批 URL 时，工具不一定帮你轉換，或者轉換用的编碼方式不一样。结果是同一份内容，站内出現了几套不同寫法的地址。
几個常见的出错场景
- 空格處理不一致。路径里的空格必须是 %20；查询參數里的空格有时被寫成加号，而加号在路径中就是加号本身，不是空格。同一個關鍵詞，两種寫法指向的可能是不同结果。
- 编碼字符集不同。同一段中文，用 UTF-8 编碼和用 GBK 编碼得到的百分号串完全不同。舊系統導出連結时容易出現這種情况。
- 十六進制大小寫混用。%e4 和 %E4 在多數服務器看来等價，但作為字符串它們並不相同，缓存、去重、日誌統計都可能把它們分開。
- 把斜杠编碼進路径。%2F 表示的是斜杠字符本身，而不是目錄分隔符。有些服務器會直接拒绝，有些會還原成目錄层級，行為不一致。
- 中文域名與中文路径混用。域名部分的國际化處理和路径编碼是两套規則，放在一起时更容易出错。
统一寫法比選哪種编碼更重要
規范並没有强制規定站内必须用哪一種编碼形式，真正影响收錄的是一致性。同一個頁面，如果導航里是一種寫法、正文推荐連結是另一種寫法、sitemap 里又是第三種，蜘蛛抓到的就是几個内容相同、地址不同的頁面。接下来就會触發規范化判断：它需要自己决定留哪一個，而這個過程未必按你的意愿走。
建议的做法是固定一套：
- 路径和參數统一使用 UTF-8 的百分号编碼，十六進制字母统一大寫。
- 能不用中文路径就不用。用拼音或英文做目錄名，中文只在參數值里出現，出問题的概率會小很多。
- 頁面里的内鏈、sitemap、canonical、跳轉規則，都從同一個来源生成，不要各處手寫。
- 如果歷史原因已经存在多種寫法，選一個作為标准，其余用 301 指向它。
编碼問题很少直接導致頁面被拒收，它的杀伤力在于制造出一批看起来像重复内容的地址，让蜘蛛在几個等價 URL 之間做選擇。
發現疑似重复地址後的排查顺序
- 先確認是不是编碼差异。把几個可疑地址手工解碼一次，看解碼後的字符串是否相同。
- 检查服務器日誌，看這些寫法是否都真實被請求過，各被請求了多少次。
- 用抓取工具請求每一種寫法，观察返回的狀態碼、最终落地的 URL 和頁面内容是否一致。
- 查 canonical 标簽和 sitemap 里寫的是哪一種，和實际被抓取最多的是否一致。
- 确定标准寫法後，统一站内連結，把其他寫法做 301，並在 sitemap 里只保留标准版本。
顺手检查的两個地方
一是站内搜尋、篩選、分頁生成的連結。這類 URL 往往由程序拼接，參數里带中文關鍵詞时最容易出現编碼不统一，數量還可能很大。二是從舊站迁移過来的連結，尤其是手工整理過的列表，寫法常常五花八门。
编碼本身是個小問题，處理起来也不复杂，但它属于基础设施层面的東西。地址寫法不统一，後面做 canonical、做站点地图、看日誌，都會多出一层解释成本。花点時間把 URL 生成規則固定下来，比事後一個個纠正要省事得多。