Google 已发现但尚未收录：从 Sitemap 到 Googlebot 的排查顺序

先区分三个阶段，避免把原因归错

Google 发现一个 URL，不等于已经请求这个 URL，更不等于决定把内容纳入搜索索引。Search Console 的“已发现，尚未编入索引”重点指向抓取尚未发生或尚未反映在报告中；“已抓取，尚未编入索引”则是另一类问题。

遇到大批量未收录时，不要先给每页补几百字，也不要重复点击几十次“请求编入索引”。首先选主页、栏目页、详情页各一个样本，核对它们是否被真正抓取。

• 已发现：检查发现来源、站点地图读取情况和站内链接。
• 尚未抓取：检查 Googlebot 实际请求、服务器容量、429/5xx、DNS 与 WAF。
• 已抓取但未收录：才进一步检查重复内容、规范网址、页面独特价值和质量。

第一层：检查正式网址与页面可访问性

用不自动隐藏跳转的方式查看状态码，再检查 http、https、带 www 与不带 www 的结果。重要页面应该只有一个规范地址，旧地址跳转到它；不应出现每种主机名都返回 200 的多个版本。

robots.txt 返回 200 和 Sitemap 可以访问，是必要检查，但不代表搜索引擎一定会抓取。还应核对最终页面是不是完整 HTML、有没有 noindex、Canonical 是否指向自身，特别关注 CDN 缓存造成的新旧版本不一致。

curl -sSIL --max-redirs 6 https://www.example.com/agents
curl -sS https://www.example.com/robots.txt
curl -sS https://www.example.com/sitemap.xml

第二层：确认 Googlebot 到底有没有来

服务器日志应至少记录请求时间、路径、HTTP 状态、耗时、响应大小和可核验的客户端来源。统计 Googlebot 对重要页面的请求，查看是否遇到 403、429、500、502、503 或异常超时。

普通浏览器、curl 或把 User-Agent 写成 Googlebot 的请求，即使返回 200，也不能证明真实 Googlebot 能通过防火墙。对真实爬虫身份应采用 Google 官方推荐的反向 DNS 等核验方法。

• 按 URL 路径对比请求量，分清从未访问和访问失败。
• 按时段检查 429、5xx 与限流策略，关注偶发故障而非单次测试。
• 核对代理、CDN 与源站日志：不能只看一个入口的成功响应。

第三层：让重要页面有清晰的发现路径

Sitemap 应只列希望被索引的规范页面。每个栏目应该通过可抓取的 HTML 链接连接到关键详情页；首页、栏目、案例与文章之间建立有意义的上下文，而不是把所有链接塞进页脚。

一个网站可以有 50 多个正确返回 200 的 URL，但搜索引擎未必认为它们值得优先抓取。先保障有价值的业务入口、独特内容和自然内链，再逐步扩大文章数量。

• 产品和服务页：解释适合谁、解决什么问题、怎么交付以及限制。
• 案例页：区分真实项目、Demo、内部实验，保留证据边界。
• 文章页：明确解决的问题、可操作方法、示例与权威参考资料。

修完怎么验收？

把代码验收和搜索引擎收录分开。代码侧可以自动遍历 Sitemap，检查 200、Canonical、robots 与所有旧路径重定向；线上侧核对部署版本和 Googlebot 日志；Search Console 再观察实际抓取与索引变化。

不存在可以保证 Google 立即收录的按钮。若问题仍在，使用具体的失败 URL、时间与状态码继续追踪，而不是靠反复提交来试运气。

• 构建和本地 HTTP 黑盒均通过。
• 正式站点响应与构建版本一致。
• Googlebot 真实请求可达，且没有异常 403/429/5xx。
• Search Console 中代表性页面的抓取结果持续变化。