谷歌收录慢还是没收录：三个真实案例的卡点复盘
收录慢和没收录，是两种病。前者只需要等，后者必须查。这篇不讲通用理论，只把三个真实卡点拆开：sitemap 不更新、渲染不可读、canonical 指错，再附上我们 7 页金丝雀从发布到全部收录的完整时间线。
Key Takeaways
- 收录慢是时间问题，没收录是链路问题。用感觉判断这两件事，十次有九次会误判，用 Search Console 的网址检查看状态才作数。
- 刚发布三五天没有收录，不构成任何结论。我们自己的金丝雀实测里，7 个页面要到第 14 天才全部进索引。
- 三个卡点里，sitemap 不更新和渲染不可读都属于零报错的静默故障，插件后台一切正常，只有探针能戳穿。
- canonical 指错最容易被忽略：内容没问题、抓取也正常，但页面把该给自己的一票投给了别人。
- 排查顺序比排查力度重要。顺序错了，改内容、改标题、反复提交请求，全是白做。
收录慢和没收录，到底怎么区分？
先说清楚这两个词。收录慢，意思是页面最终会进索引，只是要等；没收录，意思是它卡在某一步不再往前走了，你等到明年也一样。两者的动作完全不同：前者什么都别做，等着就行；后者必须动手查。
实务里最容易犯的错，是把慢当成没收录。文章发出去第三天搜不到，就开始改标题、改首段、反复点提交请求，甚至怀疑内容质量要重写。这套动作没有帮助，还把原本干净的变量搅乱，后面真要排查连基线都没有。
判断方法不靠感觉，靠一个具体动作：把完整 URL 贴进 Search Console 顶部的网址检查框。它给出的状态，会直接告诉你页面卡在哪一档，以及这一档该做什么。这套读法在收录检查方法里写得更细，我这里只留结论。
有一个反直觉的事实值得先说：内容质量只影响四档状态里的一档。也就是说，多数站在急着改内容的时候，真正卡住的往往不是内容。我们在收录问题排查的原始记录里统计过自己站的状态分布，凶手的分布和直觉差得很远。
先查状态：你的页面卡在哪一档？
网址检查的结果基本落在下面四档里。把未收录的页面各抽几个过一遍，你就能看出这是普遍问题还是个别问题。
| 状态 | 意思 | 该做什么 |
|---|---|---|
| URL is unknown to Google | Google 根本不知道这个页面存在 | 查 sitemap 里有没有它、站内有没有链接指向它 |
| Discovered – currently not indexed | 知道了，但还没来抓 | 加内链、等，或有限度地手动请求收录 |
| Crawled – currently not indexed | 抓了，看完决定先不收 | 这时才轮到检查内容价值和重复度 |
| 已收录到 Google | 在索引库里了 | 别动它，去救别的页面 |
看这张表时注意一点：如果大量页面停在 unknown，那是发现层出了问题，改内容毫无意义；如果大量停在 Discovered，通常意味着页面是孤岛，Google 知道它存在却没有理由优先来抓。这两种情况在下面三个案例里都能对号入座。
还有一种情况是页面压根没进过 sitemap，入口本身就错了。sitemap 的作用和写法可以参考sitemap 是什么，这里不重复。
案例一：sitemap 不更新，Google 手上是旧版本
第一个案例的表面现象很普通：一个内容站持续更新，排名和收录却几个月没有变化，日志里也没报错。站长一直以为 sitemap 每天在更新，因为插件后台挂着一个绿色的勾。
真实情况是，sitemap 的输出被缓存冻住了。这台站开了对象缓存（Redis），sitemap 生成结果被 transient 缓存住了，新文章写进数据库，但 Google 请求 sitemap.xml 时拿到的还是冻结前那一版。对爬虫来说，这个站几个月没有新页面。
这类故障的特点是零报错。插件认为自己交付了 sitemap，缓存认为自己命中了，站长的后台看不到任何异常。你只有两个办法戳穿它：一是直接在浏览器里打开 sitemap.xml，看最新那篇文章在不在里面；二是去 Search Console 的 sitemap 报告，核对 Google 实际读取的时间与已发现的条数，而不是看插件后台上次生成的时间。
怎么确认 sitemap 是活的？
最可靠的一招是发一篇探针文章，发布后立刻打开 sitemap.xml，看它有没有出现。如果没出现，先清缓存再看一次；清了缓存才出现，说明缓存策略就是元凶。这台站最后是用 mu-plugin 把 sitemap 从缓存里摘出去才彻底解决的，改完当天新页就进了 sitemap。
顺带提醒一个排查死角：缓存文件的命名如果不含 sitemap 字样，按文件名去服务器上找永远找不到它。排查时别只按文件名搜，要按目录和时间戳搜。
有人会问，sitemap 不更新，是不是提交一次请求收录就能救回来？不能。手动请求收录是加速器，前提是页面本身能被发现。robots、noindex、canonical 与 sitemap 的索引控制这几个基础没打通，加速器加速的是零。
案例二：渲染不可读，页面在 Google 眼里是空的
第二个案例更隐蔽。页面在浏览器里打开完全正常，文字、图片、表格都在，但在 Google 抓到的 HTML 里，正文部分是空壳——内容全靠 JavaScript 在客户端注入。
Google 确实会渲染 JavaScript，但渲染是要排队的，而且它渲染出的结果不保证和你浏览器里看到的一致。当正文只在渲染后才出现、且渲染资源被主题脚本拦在后面时，爬虫拿到的就是一个没有内容的页面。它不会报错，只会把这份空壳拿去判断价值，结论自然是不收录。
站长的直觉往往是”我的页面明明有内容”，于是去改文案、加字数，方向从头就错了。判断这件事要看两个版本的 HTML，而不是看浏览器截图。
怎么判断是渲染问题，还是内容问题？
在网址检查里对比两样东西：一是”查看已抓取的网页”里的 HTML，这是 Google 第一次拿到的原始版本；二是”测试实际网址”里渲染后的结果。如果原始 HTML 里没有正文、渲染后才出现，那就是渲染问题，跟内容质量无关。
修复方向有三个，按成本从低到高：把关键正文改为服务端输出，让首屏内容直接进初始 HTML；把阻塞渲染的脚本改成延后加载；用预渲染或静态化把渲染结果提前生成。核心原则只有一条——正文必须在初始 HTML 里就能读到，别把它交给某个可能不执行的脚本。
同类问题还包括内容藏在标签页、折叠面板或需要交互才加载的模块里。凡是”要点一下才看得到”的内容，都要假设爬虫看不到，除非它确实在初始 HTML 里。抓取、索引与速度这条链路的关系，在技术 SEO 的抓取与索引指南里系统讲过。
案例三：canonical 指错，页面把票投给了别人
第三个案例最冤：页面能抓、能渲染、内容也扎实，就是长期不进索引。查到最后，问题出在 canonical 标签上——页面声明自己的规范版本是另一个 URL。
canonical 的作用是告诉 Google”这一堆相似页面里，请以哪一个为准”。一旦某个页面的 canonical 指向了别处，Google 就会把它的信号合并到目标页，被指向的那个页面收不到票，自己也可能被排除在索引之外。常见成因有三类：模板变量写错，所有页面都指向了首页；迁移或换域名后旧地址没跟着换；分页与筛选参数处理不当，变体页互相指向。这类错误不报错，只看页面本身发现不了。
怎么核对 Google 实际选中的规范网址？
别只看 HTML 里写了什么，要看 Google 选了哪个。网址检查里有一栏明确写着 Google 选择的规范网址，如果它和你页面的真实地址不一致，就是这里出了问题。批量排查可以抓一批页面的源码，比对自己声明的 canonical 与自身 URL 是否一致，成本很低。
修复时注意一个坑：改完 canonical 后要清缓存再验证，带缓存返回的 200 是假象。canonical 的定义与常见误用，可以参考Canonical 是什么意思那一篇，里面把该指向自己的几种场景列全了。要读懂 Google 眼里的页面版本，URL Inspection 实战是必须过的一关。
收录到底要多久？7 页金丝雀的 D+14 时间线
说完三个卡点，回头讲”慢”。很多老板的焦虑来自一个错误预期：以为页面发出去，隔天就该在 Google 里搜到。事实不是这样。
我们做过一次金丝雀实测：7 个页面在 09-18 当天发布，此后逐日检查收录状态。前面几天是零收录，中途陆续进来，直到第 14 天才达到 7/7 全部收录。整个过程没有做任何特殊操作，也没有出故障——这就是一个权重正常的站在当下的正常速度。
这个实测有两个直接结论。第一，收录以周为单位计时，不是以小时。第二，发布后第三到第七天没有收录，属于正常区间，此时任何”抢救”动作都是多余，还会污染变量。真正该做的是等，并且在等待期里把内链和 sitemap 这些确定性的工作做扎实。
顺带说一句，外面那些”多少天收录”的经验谈，多半是不可复现的。Reddit 上有一篇公开讨论，原帖题名《Recently hit 6.4 mil monthly organic traffic for a SaaS website. Here’s the 40 tips that h…》，参与者包括 /u/levi815、/u/DrJigsaw 等。来自 Reddit 公开讨论的这类帖子，读时要分清哪些是长期动作、哪些只是单次结果——收录卡点从来不是靠一条技巧点着的。
如果你想知道哪些页面在拖后腿，抓取预算和日志是更靠得住的证据，方法见日志分析与抓取预算。
一张排查顺序表
把上面的内容压成一张表。顺序是按”证伪速度”排的，能在几分钟内排除的放前面。
| 顺序 | 查什么 | 怎么验 | 常见凶手 |
|---|---|---|---|
| 1 | 未收录页的状态分布 | GSC 网址检查逐页看状态 | 大量 unknown = 发现层问题 |
| 2 | sitemap 的真实状态 | 浏览器打开 sitemap.xml，核对该页在不在 | 缓存冻结、新页不在其中 |
| 3 | Google 拿到的 HTML | 网址检查对比已抓取版本与渲染结果 | 正文靠 JS 注入，初始 HTML 是空壳 |
| 4 | canonical 指向 | 看 Google 选择的规范网址是否等于自身 | 指向首页、旧域名或变体页 |
| 5 | 内链入度 | 看未收录页有没有站内链接指向 | 孤岛页、只有分页入口 |
| 6 | 这时才轮到内容 | 对照已收录页找差距 | 重复、拼凑、无独立价值 |
顺序的重要性在于止损。市面上的教程大多让你从第 6 步开始，直接改内容；而我们经手的收录排查里，凶手几乎都藏在前 5 步。前 5 步全部干净，再谈内容，才不算浪费。Google 收录完整指南和抓取、索引、排名的流程两篇，可以作为这张表的背景阅读。
修好之后，该盯哪几个数字？
修好不等于结束。收录是会被重新弄坏的，换主题、装插件、迁服务器、改缓存策略，任何一个动作都可能让今天正常的链路重新断掉。所以要留下可复查的数字。
我盯四个：全站已编入索引的页面数、sitemap 上次被读取的时间、未收录页的状态分布、canonical 与自身 URL 的一致率。前两个按周看，后两个按月抽查一批就够。异常会先变成一个数字，再变成事故。
还有一个杠杆值得单独说：内链。未收录页大多是孤岛，从已收录、主题相关的页面给出链接，是最快也最可控的动作。锚文本用目标页的真实标题，别堆关键词。批量页面尤其要注意模板化站点的索引风险，可参考程序化 SEO 模板页与索引风险，以及 WordPress 站常见的插件—索引—内容联动问题，见WordPress 插件与索引速度。
最后一句提醒：收录只是入场券，进了索引库不等于有排名，有排名也不等于有询盘。若收录和流量都修好、询盘仍无变化，那是另一个问题，别在收录线上继续加码。
常见问题
文章发布多久没收录才算异常？
按我们的金丝雀实测，7 个页面到第 14 天才全部收录。因此两周以内没有收录，先不要下结论，把它当成正常等待期，同时确认 sitemap 里有它、站内有内链指向它。超过这个周期仍未收录，再按上面的顺序表逐项排查。
反复点”请求编入索引”能加快收录吗？
不能。请求收录的配额有限，而且官方提示写得很清楚：多次提交同一网址并不会改变排队顺序。它只是加速器，前提是页面本身能被发现。给已收录的页面提交，等于白烧配额。
插件后台显示 sitemap 正常，还需要自己核吗？
需要。sitemap 冻结属于零报错的静默故障，插件认为自己交付了、缓存认为自己命中了，后台一切正常。唯一可靠的办法是直接打开 sitemap.xml 看最新页面在不在，再去 Search Console 核对 Google 实际读取的时间和条数。
canonical 写错了，Google 会不会自己纠正？
不要指望它。Google 有时会忽略明显错误的 canonical，但这属于例外，不是你可以依赖的机制。正确做法是让每个页面的 canonical 指向自身，改完后清缓存，再用网址检查确认 Google 选择的规范网址是否已经跟上。
收录慢的站，是不是内容质量不行？
不是。内容质量只影响四档状态里的”Crawled – currently not indexed”这一档。大量页面卡在 unknown 或 Discovered，说明问题在发现与抓取层，改内容等于修错了零件。
信息来源＝实测：tianwenseo 收录排查记录（三个卡点：sitemap 不更新／渲染不可读／canonical 指错；sitemap 冻结事故根因＝twwl Redis transient 缓存冻结，已用 mu-plugin 修复）；金丝雀实测：7 个页面 09-18 发布，D+14 达成 7/7 收录。公开资料：Reddit 公开讨论帖《Recently hit 6.4 mil monthly organic traffic for a SaaS website. Here’s the 40 tips that h…》（参与者 /u/levi815、/u/DrJigsaw 等）；tianwenseo.com/google-indexing-problems-three-real-cases-tw/（繁体原版，可核）。
{
“@context”: “https://schema.org”,
“@type”: “FAQPage”,
“mainEntity”: [
{
“@type”: “Question”,
“name”: “文章发布多久没收录才算异常？”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “按金丝雀实测，7 个页面到第 14 天才全部收录。因此两周以内没有收录先不要下结论，把它当成正常等待期，同时确认 sitemap 里有它、站内有内链指向它。超过这个周期仍未收录，再按排查顺序表逐项排查。”
}
},
{
“@type”: “Question”,
“name”: “反复点请求编入索引能加快收录吗？”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “不能。请求收录的配额有限，多次提交同一网址并不会改变排队顺序。它只是加速器，前提是页面本身能被发现。给已收录的页面提交，等于白烧配额。”
}
},
{
“@type”: “Question”,
“name”: “插件后台显示 sitemap 正常，还需要自己核吗？”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “需要。sitemap 冻结属于零报错的静默故障，插件和缓存都认为自己正常。唯一可靠的办法是直接打开 sitemap.xml 看最新页面在不在，再去 Search Console 核对 Google 实际读取的时间和条数。”
}
},
{
“@type”: “Question”,
“name”: “canonical 写错了，Google 会不会自己纠正？”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “不要指望它。Google 有时会忽略明显错误的 canonical，但这属于例外。正确做法是让每个页面的 canonical 指向自身，改完后清缓存，再用网址检查确认 Google 选择的规范网址是否已经跟上。”
}
},
{
“@type”: “Question”,
“name”: “收录慢的站，是不是内容质量不行？”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “不是。内容质量只影响四档状态里的 Crawled – currently not indexed 这一档。大量页面卡在 unknown 或 Discovered，说明问题在发现与抓取层，改内容等于修错了零件。”
}
}
]
}
