本文约 3,117 字，预计阅读 8 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：它知道，但它没来过
「已发现，当前未编入索引」和「已抓取，当前未编入索引」只差两个字，处理思路却完全相反。前者意味着 Google 从 sitemap 或某个链接里知道了这个 URL 的存在，但还没有真正抓取它——所以此刻它还谈不上质量判定。
一个做跨境电商的站点有 12 万个 URL（SKU × 颜色 × 尺码 × 排序参数的笛卡尔积），GSC 里 8 万个处于「已发现未索引」。团队以为是内容问题，把商品描述全部重写了一遍，两个月后状态毫无变化。真正的瓶颈是：Google 每天给这个站点分配的抓取配额，连新发现的 URL 都覆盖不完，更别说回访。
原理分析：抓取预算由什么决定
Google 官方文档把抓取预算拆成两个概念：抓取速率限制（crawl rate limit） 与 抓取需求（crawl demand）。前者是服务器能承受的并发上限，后者是 Google 认为“这个站点值不值得多抓”。
影响抓取速率限制的：服务器响应速度（响应慢 → 抓取线程被长时间占用）、错误率（5xx 会直接降低配额）、robots.txt 里的 Crawl-delay（Google 不支持该指令，写了没用，反而可能错过其他优化）。
影响抓取需求的：站点权威度与流行度、内容更新频率、URL 是否长期不变化。一个 URL 空间越大、有效内容密度越低的站点，抓取需求评分越低，因为 Google 的经验是“抓了也大概率是低价值页面”。
这就形成了一个恶性循环：URL 空间膨胀 → 有效密度下降 → 抓取配额降低 → 新页面更晚被发现 → 站长认为是内容问题 → 继续发新页面 → URL 空间继续膨胀。打破循环的入口只有一个：先把 URL 空间收敛下来。
| 站点类型 | URL 空间 | 典型表现 |
|---|---|---|
| 精选型（几百页） | 紧凑 | 新页面天级收录 |
| 成长型（数千页） | 可控 | 需 sitemap 辅助，数天到数周 |
| 膨胀型（十万级参数页） | 失控 | 大量「已发现未索引」，配额枯竭 |
| 低更新站 | 小但停滞 | 抓取需求低，回访周期长 |
保姆级实操
步骤 1：量化你的 URL 空间。 从 GSC 的「网页索引」报告和 sitemap 里，统计一下真实有价值的 URL 有多少、参数化 URL 有多少。如果后者占比超过 60%，先做收敛再谈其他。
步骤 2：在服务器层给无效参数 URL 加 noindex 响应头。 注意：不要对需要被索引的页面用 robots 屏蔽 + noindex 同时处理（这是常见误用，见 noindex 与 robots 屏蔽的区别）。对筛选页、排序页这类 URL，正确做法是允许抓取但用响应头声明 noindex，这样 Google 能读到指令：
# 对筛选/排序参数 URL 输出 noindex 响应头（允许抓取，只是不索引）
map $args $noindex_header {
default "";
"~*(^|&)(sort|orderby|filter|color|size)=" "noindex, follow";
}
server {
listen 443 ssl http2;
server_name www.example.com;
location / {
# Nginx 的 add_header 在 map 变量为空时也会添加空值，需用 if 包裹
if ($noindex_header != "") {
add_header X-Robots-Tag "noindex, follow" always;
}
try_files $uri $uri/ /index.php?$args;
}
# 搜索结果页同样处理：不占用索引配额
location = / {
if ($arg_s) {
add_header X-Robots-Tag "noindex, follow" always;
}
try_files $uri $uri/ /index.php?$args;
}
}
步骤 3：修正 sitemap，只放值得索引的 URL。 sitemap 是给抓取排优先级的信号，不是 URL 清单。里面混着 noindex、重定向、404 的 URL，会降低 Google 对整份 sitemap 的信任。清理后重新提交。
步骤 4：提升服务器响应速度。 抓取预算与响应时间强相关。把 TTFB 从 800ms 降到 200ms，实际抓取量往往有肉眼可见的提升。静态资源上 CDN、开启页面缓存、数据库查询加索引，这三件事的性价比最高。
步骤 5：降低错误率。 反复 5xx 会让 Google 主动降低抓取速率。在 GSC 的「抓取统计信息」报告里看响应码分布，把 5xx 归零。
步骤 6：用内部链接提权。 Google 发现新页面主要靠链接。把重要新页面从首页或高权重栏目页链一次，比在 sitemap 里躺着有效得多。这与 Google 对重复内容的处理机制 里讲的权重分配是同一套逻辑。
步骤 7：控制发布节奏。 一次性放出 5000 个新 URL 会瞬间打满抓取队列。分批发布、每批观察收录情况，反而更快。
常见踩坑
- 用 robots.txt 屏蔽参数 URL 想节省预算。 robots 屏蔽后 Google 读不到 noindex，URL 反而可能以“无摘要”形式留在索引里。
- sitemap 里放全部 URL 以求“都被发现”。 发现不等于索引，反而稀释优先级。
- 服务器慢却只做前端优化。 LCP 好看不代表 TTFB 好看，抓取看的是 TTFB。
- 频繁改 URL 结构。 每次改动都会产生一批需要重新发现的新 URL。
- 认为「已发现未索引」会随时间自动解决。 在 URL 空间不收敛的情况下，它只会越来越多。
- 忽略分页层级。 分类页翻到 200 页的深度分页，几乎不可能被抓完，应该用「加载更多 + 真实分页 URL」或限制层级。
- 案例： 一个工业品站的分类页支持 7 个筛选维度，理论组合超过 200 万个 URL，sitemap 里放了 30 万个。结果核心产品页的收录周期长达两个月。后来改为：只对“单维度筛选 + 有真实搜索量”的 4000 个组合开放索引（配 canonical 与差异化标题），其余组合一律 noindex 且不放 sitemap，同时把 TTFB 从 900ms 优化到 180ms。三个月后新产品页的收录周期缩短到 3–5 天。收敛 URL 空间是提升抓取效率最立竿见影的一步。
总结
「已发现，尚未编入索引」处理的核心不是催 Google 抓取，而是让有限的抓取配额花在值得的页面上。行动顺序：统计并收敛 URL 空间 → 参数页与搜索页加 noindex 响应头 → 清理 sitemap → 降 TTFB 与错误率 → 用内链给重要页面提权 → 控制发布节奏。判断标准看两个比值：sitemap 中最终进入索引的比例，以及新页面从发布到收录的天数——这两个数只要持续改善，说明抓取预算用对了地方。
