从后台复制一条带中文标题的文章链接，粘贴到聊天工具里，再复制回来，往往就变成了 %E4%B8%AD 这样的百分号编码。两个地址指向同一篇内容，但从 URL 字符上看完全不同。这类差异平时不影响用户打开，却会在收录环节留下一些需要理清的麻烦。

URL 里哪些字符会被编码

URL 标准里只允许一小部分 ASCII 字符直接出现，其余都要转成百分号编码。中文、日文、空格，以及 #、?、& 这类在 URL 中有特殊含义的符号，都属于需要处理的字符。

• 中文：按 UTF-8 转成多个字节，再逐个写成 %XX，一个汉字通常会变成三组编码。
• 空格：路径里的标准写法是 %20。写成加号只在查询串的某些场景下被当作空格，在路径中加号就是加号本身。
• 井号及其后面的片段：这部分不会发给服务器，由浏览器自己处理。它不产生新的服务端请求，但复制出来容易让人误以为是另一个地址。

同一内容出现多个地址的常见来源

• 后台模板直接把标题拼进链接，没有做编码。
• 浏览器地址栏复制时自动编码，十六进制大小写还不固定，%E4 和 %e4 都可能出现。
• 编辑器和表格粘贴时带进全角字符、零宽字符，肉眼看不出来。
• 手工在 sitemap 或内链里写地址，写法跟页面实际使用的对不上。

这些版本如果都返回 200，内容又完全一样，从抓取的角度看就是一组长得不同的地址。

会不会变成重复页面

取决于服务端怎么处理。有的框架会把请求路径先解码再匹配路由，中文原样和编码形式最终落到同一个页面；有的按原样匹配，两条路径各自返回一份内容，甚至生成两个不同的 canonical。后一种情况风险更高。

判断方法并不复杂：拿服务器日志里实际出现的请求路径，和页面里的 canonical、sitemap 里的地址对一遍。如果同一个内容对应多条路径，而服务器没有把它们指向同一个规范地址，就值得处理。

把编码统一，是减少一个变量，不等于收录一定会变好。它解决的是同一个页面被拆成多个地址这类可控问题。

日常可以做的几件事

• 生成链接时统一编码一次，内部链接、导航、面包屑用同一套规则。
• 页面里的 canonical 固定指向编码后的规范版本。
• sitemap 里的地址与 canonical 保持一致，不要一处用中文一处用编码。
• 如果确认某些编码版本不该单独存在，可以用 301 指向规范地址，注意别绕成重定向链。
• 定期抽查日志里的 404 和 200，看有没有肉眼看不见的字符混进来。

容易和哪些问题混在一起

编码差异经常和大小写、结尾斜杠、追踪参数同时出现，但它们的处理方式并不一样：编码是字符层面的转换，大小写取决于服务端是否区分，结尾斜杠往往由服务器配置决定。排查时把这几类分开看，比混在一起猜要快得多。

URL 编码本身并不复杂，麻烦的是它散落在模板、编辑器、复制粘贴的各个环节。把生成和输出的规则定死，后面看日志、看索引覆盖报告时会省下不少来回。