先把一个常见误解摆正：「收录慢」和「收录不了」是两件事，处理方式完全不同。

很多人看到文章没被 Google 或百度收，第一反应是去买外链、堆关键词。但如果你的页面根本没被爬取，或者在抓取后被判定为「不值得索引」，那么任何站外操作都是无效投入。得先把管道疏通。

第一步：把「抓取」和「索引」拆开看

搜索引擎处理一个页面的流程是三段：

1. 发现（Discovery）：从 sitemap、内链、外链里知道有这个 URL；
2. 抓取（Crawl）：机器人真的来读了 HTML；
3. 索引（Index）：内容入库，有资格出现在搜索结果里。

这三段任何一段断掉，你看到的现象都是「搜不到」，但病因天差地别。所以排查的第一步不是改代码，而是定位卡在哪一段。

你看到的现象	大概率卡在	去哪看
site:你的域名 结果数远少于文章数	抓取或索引	GSC「网页」报告
GSC 显示「已发现，尚未编入索引」	抓取预算不足 / 优先级低	GSC「网页」→ 未编入索引
GSC 显示「已抓取，尚未编入索引」	内容质量（薄内容为主因）	对比同站已收录页面的字数
GSC 显示「已排除，被 robots.txt 屏蔽」	robots 配置错误	/robots.txt
完全查不到这个 URL，GSC 里也没记录	发现环节断了（孤岛页面）	用「网址检查」手动提交

根因 1：robots.txt 误屏蔽

最常见也最容易被忽略的一条。典型误伤是把动态参数屏蔽了，结果 CMS 的搜索页、分页全部阵亡：

User-agent: *
Disallow: /*?s=
Disallow: /search/
Disallow: /wp-admin/

更要命的是有人写成了 Disallow: /，全站直接出局。检查方式很简单，浏览器打开 https://你的域名/robots.txt，逐行看有没有把正文路径圈进去。

判断标准：robots.txt 只应该屏蔽「你不想让搜索引擎浪费预算的页面」——后台、购物车、站内搜索结果页、参数组合页。正文页、分类页、标签页（如果你想收录）一律不要出现在 Disallow 里。

根因 2：noindex 误加或漏删

测试环境留下的 <meta name="robots" content="noindex"> 忘了删，是上线事故的经典款。还有一种隐蔽情况：主题或 SEO 组件给某个自定义文章类型批量打了 noindex，你在后台完全看不出来，只能看源码。

批量检测整个站点的 noindex，用 curl 配合 grep 最快：

for u in / /about.html /183.html; do
  printf "%-20s " "$u"
  curl -s "https://blog.nvcb.cn$u" | grep -o 'noindex' | head -1 || echo "OK"
done

注意：noindex 只在页面自身被爬取时才生效。如果你同时在 robots.txt 里屏蔽了这个页面，爬虫根本读不到 noindex 标签，页面会以「被屏蔽」的方式长期留在索引里。这两个指令不能同时用于同一个 URL。

根因 3：canonical 指错了地方

canonical 是「我认为哪个 URL 才是正版」的声明。它一旦指错，页面即使被爬取，权重和索引名额也会被让渡给别的地址。

典型错误场景：

• 分页第 2 页的 canonical 指向第 1 页（等于告诉搜索引擎「第 2 页是重复内容」，那么第 2 页的文章永远收不了）；
• 带参 URL（?utm_source=、?from=）没做 canonical 归一，搜索引擎把同一篇文章当成几十个页面；
• canonical 写成了 http:// 版本，而站点实际跑在 https://。

检查命令：

curl -s https://blog.nvcb.cn/183.html \
  | grep -oE '<link[^>]*rel="canonical"[^>]*>'

判断标准：canonical 必须与当前页面的真实地址完全一致，包括协议、www 前缀、末尾斜杠。不同就是错的。

根因 4：sitemap 没提交，或者提交了但内容是空的

sitemap 是「发现」环节的高速公路。它出问题的表现很隐蔽：文件能打开、返回 200，但里面全是分类页、标签页，正文页一篇都没有。

WordPress 原生 sitemap 地址是 /wp-sitemap.xml，Yoast 是 /sitemap_index.xml，zibll 主题一般沿用原生。检查三件事：

1. sitemap 里是否包含 post 类型的子 sitemap；
2. 子 sitemap 里的 URL 是否都能返回 200；
3. 每个 URL 的 <lastmod> 是否是真实修改时间（全是同一天的，搜索引擎会认为你在批量刷日期）。

根因 5：服务器对搜索引擎机器人返回异常状态

这是最容易被误诊的一条。你用浏览器打开一切正常，但搜索引擎拿到的可能是 403、503，或者一个需要等 30 秒的响应。原因通常是：CDN 的 WAF 把机器人当攻击流量拦了，或者服务器开了 IP 限速。

必须用机器人的 UA 实测：

curl -sI -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  https://blog.nvcb.cn/183.html

curl -sI -A "Baiduspider/2.0" \
  https://blog.nvcb.cn/183.html

判断标准：前者应返回 200，响应时间应在 1 秒内。如果返回 403 或 503，先解决服务器放行，其他优化都别做。

根因 6：内容太薄（thin content）

页面被抓取了，但索引报告显示「已抓取，尚未编入索引」，且这个状态持续几周不变——大概率是内容质量判定没过关。

搜索引擎需要页面有足够的信息量来判断它「能解决什么搜索需求」。一篇 100 多字的文章，很难承载任何一个真实查询。

自查方法：统计全站文章正文字数，看中位数和最短值。如果中位数低于 300 字，问题就不在技术层，而在内容层。

# WordPress 环境，统计文章正文长度（去标签后）
wp post list --post_type=post --format=ids | while read id; do
  wp post get $id --field=content | sed 's/<[^>]*>//g' | wc -m
done | sort -n | awk '{a[NR]=} END {print "最短:", a[1], "中位:", a[int(NR/2)], "最长:", a[NR]}'

根因 7：孤岛页面——没有任何内链指向它

搜索引擎主要通过链接发现新页面。如果你的文章只存在于 sitemap 里，首页、分类页、其他文章都不链它，那它被发现的优先级会非常低，通常要等几周到几个月。

修复动作：每篇新文发布后，至少从两个已有页面加上指向它的内链——一个来自相关文章，一个来自分类页或专题聚合页。这件事花的时间比等收录少得多。

根因 8：抓取预算被低价值页面吃掉

对中小站点来说，每天能获得的抓取次数是有限的。如果你的 sitemap 里有几百个内容雷同的标签页、日期归档页、参数页，机器人会把预算花在这些页面上，正文页反而排到队尾。

一个实用的自查：比较 sitemap 里「正文 URL 数」和「其他 URL 数」。健康的比例是正文占 70% 以上。

修复方向：把只有 1–2 篇文章的标签页设为 noindex, follow，把日期归档页从 sitemap 移除，把参数页统一 canonical 到干净 URL。

根因 9：新站或改版后的正常延迟

如果前 8 条都排查干净了，站点上线不到 3 个月，或者刚做过大规模改版，那么「慢」本身可能就是正常的。搜索引擎对新站点的信任建立需要时间，这个阶段要做的是稳定更新、保持 URL 不变、把 sitemap 提交好，而不是频繁改动结构。

按这个顺序排查，最省时间

顺序	检查项	耗时	工具
1	robots.txt 是否误伤正文	1 分钟	浏览器
2	页面有无误加 noindex	3 分钟	curl + grep
3	canonical 是否指向自己	3 分钟	查看源码
4	机器人 UA 是否拿到 200	2 分钟	curl -A
5	sitemap 是否含正文且 lastmod 真实	5 分钟	浏览器 + GSC
6	GSC 索引报告的具体原因分布	10 分钟	Search Console
7	正文字数中位数是否 < 300	15 分钟	WP-CLI / 脚本
8	每篇是否有至少 2 个站内入口	10 分钟	后台搜索
9	低价值页面占比是否过高	10 分钟	sitemap 统计

前 4 项加起来 10 分钟，能排除掉一半以上的收录问题。剩下的才是需要长期投入的内容工程。

常见问题

提交了 sitemap，为什么还是收录慢？

提交 sitemap 只解决「发现」，不解决「抓取」和「索引」。它相当于把地址告诉快递员，但快递员什么时候来、包裹是否符合入库标准，是另外两件事。提交后仍需关注 GSC 的抓取统计和索引报告。

被 robots.txt 屏蔽的页面，删掉屏蔽规则后多久恢复？

规则删除后，页面会重新进入抓取队列，通常几周内恢复。由于被屏蔽期间搜索引擎读不到 noindex，页面的旧快照可能还会在索引里停留一段时间，不要因此反复改动配置。

用 site: 命令统计收录数准确吗？

不准确，官方明确说明 site: 的返回数是粗略估计，且波动很大。判断收录情况应使用 Search Console 的索引报告，以其中的有效页面数为准。