Google 的关于 URL 结构的文档称支持非 ASCII 的 URL。我们自己的网站就是一个值得一看的反例，因为它无意中跑出了我们见过的、针对这一说法最干净的测试：同一个网站、同一种语言、同一套发布流程、两种 URL 格式——一边收录 63 页，另一边 0 页。
这个实验不是我们设计的，而是偷懒的副产品。早期文章用的是手写的英文 slug。后来，为了每篇省下一分钟，我们让 WordPress 根据中文标题自动生成 slug。在浏览器里，地址看起来是中文；到了传输层，它就是 %e8%b0%b7%e6%ad%8c...——一长串百分号编码。仅仅这一个习惯的改变，就把我们的存档分成了两组，而 Google 对它们的处理截然不同。
数字
2026 年 8 月，我们用 Search Console 的网址检查工具，把这个网站上已发布的 196 篇文章逐一检查了一遍。64 篇已收录，132 篇在 Google 看来根本不存在。
| URL 格式 | 已收录页数 | 内容语言 |
|---|---|---|
英文语义化 slug（/canonical-tag-seo-guide/） |
63 | 中文 |
百分号编码 slug（/%e8%b0%b7%e6%ad%8c.../） |
0 | 中文 |
两组的内容都是中文，选题有重叠，模板完全相同，唯一系统性的差异就是 URL 的编码方式。零收录那一列的每一页，都是百分号编码的字符串。
方法（便于你复现或质疑）
- 样本：tianwenseo.com 上全部 196 篇已发布文章，2026 年 8 月。不是抽样——是全量存档。
- 工具：Search Console 网址检查，逐条 URL 检查，记录 Google 报告的四种覆盖状态。
- 分组：页面是在事后按 slug 格式划分的，并非事先指派。这是自然实验，不是对照实验。
- 我们没能控制的变量：发布日期与 slug 格式相关（英文 slug 出现得更早）。网站年龄是一个可能的混杂因素，我们在“局限”一节里也如实说明。
如果你想在自己的网站上做同样的检查，有用的不是总数，而是各状态的分布：
| Search Console 状态 | 实际含义 | 该修什么 |
|---|---|---|
| URL is unknown to Google（Google 不知道此 URL） | Google 从未听说过这个页面 | 发现环节：它真的在 sitemap 里吗，有页面链接到它吗 |
| Discovered – currently not indexed（已发现——目前未收录） | 已知，但从未抓取 | 加内链，然后等；请求编入索引只是催一下，不是解决办法 |
| Crawled – currently not indexed（已抓取——目前未收录） | 读过了，Google 决定不要 | 只有这一种情况，才是内容质量的问题 |
| URL is on Google（URL 已在 Google 上） | 已收录 | 别动它，去救别的页面 |
大多数收录建议都从第三行讲起。但在我们经手的网站里，问题几乎总是出在前两行。
为什么百分号编码的 URL 表现不同
官方说法是 Google 支持非 ASCII 的 URL，这没错——知乎和维基百科用中文路径照样排得很好。但那些域名有的是权重。百分号编码的路径又长又不透明，提供不了任何词汇信号。在一个基本零信任的网站上，这类 URL 只能排在抓取队列的最后面，而队列永远轮不到它们。
所以，对我们数据的诚实解读不是“Google 无法收录非拉丁字符的 URL”，而是：在低权重域名上，百分号编码的 URL 是一笔你根本负担不起的成本。老站扛得住，新站扛不住。
我们改了什么，以及改动中的两个坑
我们把 34 个中文 slug 改写成英文语义化 slug。有两件事出了问题，在你照做之前值得知道：
- WordPress 原生的
_wp_old_slug重定向对百分号编码的 slug 并不可靠。我们实测过。有些旧 URL 能正确 301，有些不能。最后我们在一个 mu-plugin 里写了硬映射，才做到 100% 覆盖。 - 缓存返回的 200 不算通过测试。清缓存之后要再验证，否则你测的是缓存，不是重定向。
两个完全没有报错的静默故障
第二个网站——一家机械出口商，内容和链接都没问题——收录量连续几个月纹丝不动。两个故障叠在一起，而且都没有留下任何日志：
sitemap 缓存冻结。（Google 关于构建 sitemap 的说明）Rank Math 会把 sitemap 缓存写成名为 rank_math_{md5}.xml 的文件。文件名里不含 “sitemap” 字样，所以在文件系统里搜 “sitemap” 什么也找不到。我们在 2026 年 7 月实测的默认有效期是 100 天。后台界面显示 sitemap 一切正常，可 Google 拿到的却是三个月前的文件，新文章根本不在里面。
定时文章永远发不出去。WP_CRON 在 wp-config.php 里被关掉了，也没有配置系统 cron 来替代它。定时文章就无声无息地永远停在“定时”状态。那个网站有 176 篇文章卡在那里。同一台服务器上其他所有站点都有这条 cron 记录，唯独漏了这一个。
普遍教训是：不要相信配置，要相信探针。发一篇一分钟后发布的定时测试文章，看它到底会不会触发。去看 sitemap 报告里真实的下载时间戳和 URL 数量，而不是插件那个绿色的对勾。
规模悖论
一个拥有 2,900 多个产品页的目录站，收录率只有 36%——大约 1,916 个产品页卡在“已发现”状态（2026 年 8 月的完整 90 天 Search Console 数据）。Google 知道它们存在，却从未来抓。
反直觉的地方在于：型号词长尾查询贡献了该站 71% 的点击，而站长想拿下的大词只有展现、没有点击。收入在长尾里——而长尾页面恰恰就是没被收录的那些。
我们自己的网站从另一个方向呈现出同样的形状：有一个月我们发布了 150 多篇文章，收录率反而跌到 33%。发得更多并没有用，反而稀释了我们本就有限的抓取注意力。
我们实测过杠杆最高的一个修复
我们从 64 个已收录页面指向 98 个未收录页面，做了 294 条内链。4 天之内，已收录页面从 64 涨到 112（2026 年 8 月，这段时间内没有部署任何其他改动）。
未收录页面通常是孤岛。爬虫抓到一个已收录页面、发现一条链接就会跟过去——实践中的“已发现”其实就是这个意思。加内链时有两点很关键：链接应当来自已经收录且主题相关的页面；锚文本应当用目标页面的真实标题，而不是你希望排名的关键词。
外链也重要。但对新站来说，内链是你唯一能完全掌控、而且当天就能上线的杠杆。
关于“请求编入索引”
Search Console 的请求编入索引配额大约是每个资源每天 10 条 URL。我们浪费在两件事上，希望你不用再踩：
- 提交已经收录的页面。先看状态；只有“已发现”和“未知”的页面才值得占一个名额。
- 同一条 URL 提交两次。Google 自己的确认弹窗就说了，重复提交不会改变队列位置。我们还是测了一遍。确实不会。
请求编入索引是加速器，不是急救。如果一个页面没有任何内链，也不真的在你的 sitemap 里，请求十次也什么都加速不了。
排查顺序
| # | 检查项 | 工具 | 常见元凶 |
|---|---|---|---|
| 1 | 未收录页面的状态分布 | 网址检查 | 大量“未知”= 发现环节有问题 |
| 2 | URL 形态 | 直接看地址栏 | 百分号编码、参数、长度过长 |
| 3 | sitemap 是否真的新鲜 | sitemap 报告的下载时间 | 缓存冻结；新页面不在其中 |
| 4 | 内链入度 | 爬虫或数据库查询 | 孤岛页；只有分页能进 |
| 5 | 定时任务是否真的运行 | 一篇探针文章 | WP_CRON 关闭且没有系统 cron |
| 6 | 这时候再看内容 | 与已收录页面做对比 | 内容单薄、重复、没有独立价值 |
顺序才是重点。在我们维护的各个站点里，元凶几乎总在 1–5 步，而大多数公开的建议都从第 6 步讲起。
本研究的局限
- 不是对照实验。slug 格式并非随机分配。英文 slug 的页面平均更老，而网站年龄有助于收录。用这份数据，我们无法把两种效应分开。
- 单一站点、单一语言。这是否适用于西里尔字母、阿拉伯字母、泰文或韩文路径，尚未验证。我们提出的机制——编码后的长度，加上在低信任域名上没有词汇信号——会预测它也适用，但那是假设，不是我们的发现。
- n=196。大到足以让 63 比 0 的差距看起来惊人，也小到可能被单个站点的特殊因素左右。
- 内链的结果是前后对比，不是对照试验。那段时间我们没有部署其他改动，但无法排除 Google 的抓取计划因无关原因发生了变化。
我们把这些提醒一并写出来，是因为“63 比 0”这种标题数字，恰恰是最容易被摘出来反复引用、却丢掉这些前提的那一类。
如果你的网站不是中文，这意味着什么
可以迁移的结论很窄，但我们认为站得住脚：如果你的域名权重很低，就不要在会让爬虫多花力气的 URL 格式上浪费任何东西。非拉丁字符的百分号编码路径是极端情况。超长 slug、会话参数和筛选类 URL 都在同一条谱系上。
而排查顺序则可以完全照搬。在改写任何一个标题之前，先弄清楚你有多大比例的页面 Google 从未抓取过。如果这个数字很大，那你投入的内容工作，正在花在没人会读的页面上。
常见问题
Google 真的无法收录非拉丁字符的 URL 吗？
不是。在有权威度的网站上，Google 是收录它们的。我们的发现针对的是一个毫无权威度的网站：在那里，编码后的 URL 从未排到队列前面。
我应该改写现有的非拉丁 slug 吗？
只有当那些页面没有被收录时才值得。如果它们已经收录并且有排名，改 URL 的风险大于收益。先看状态。
恢复用了多久？
从改写 slug、建内链，到已收录页面数量明显翻倍：一个多月。在近乎零权重的域名上，每一个反馈循环都以周为单位。
被收录就等于有流量吗？
不等于。收录只是入场券，不是结果。我们有一个客户站，点击量涨了 4.7 倍，询盘却跌到原来的十二分之一。那是另一个问题，也需要另一项研究。
同一站点的相关实测
这是我们用英文发布的第一手实测系列中的第二篇。第一篇：我们测试了 497 个中文查询，发现其中 80.9% 已经返回 AI Overview——据我们所知，这是对中文 SERP 上 AI Overview 覆盖率的首次系统测量。
收录这项工作的中文原文，以及全文提到的内链和工具，在这里（中文）。
本页由英文版机器翻译，尚待人工审核。
