做站长最常被问到的一个问题：「我的站为什么收录这么慢？能不能想办法让百度快点收？」问这个问题的人通常已经在 GSC 或百度搜索资源平台点过「提交 sitemap」，等了几天没动静，然后开始怀疑是不是被惩罚了。绝大多数情况下不是惩罚，而是你的站在抓取系统的「预算」里排得太靠后——而预算这件事，有相当一部分是你自己能调整的。

这篇文章不谈玄学，讲的是搜索引擎抓取一个站时的真实机制：它怎么发现 URL、怎么决定先抓哪些、同一批 URL 里哪些会被抓、哪些会被反复抓。理解这套机制之后，你做的每一件事都能对上一个具体原因，而不是靠「多提交几次」。站点最近刚做过 sitemap 与 lastmod 的调优（那是「让引擎知道有什么」），本文补上另一半：让引擎愿意来、来得值。

一、发现：URL 是怎么被知道的

搜索引擎知道一个新 URL，只有几条路径：站内链接被爬虫顺着走到、sitemap 里的 <loc>、外部链接、站长平台手动提交、以及 IndexNow 之类的推送协议。其中质量最高、最稳的是第一条：从一个已被频繁抓取的页面上挂出一个链接。这就是为什么首页新增的文章列表对于收录速度的影响，远大于 sitemap 里多一行地址。

由此推出三个实操结论。新文章发布后，确保它同时出现在：首页列表、对应的分类页、相关文章的侧栏或底部。这三处都是爬虫常来的页面。如果站点的首页是静态 HTML 且更新有延迟（比如整站生成、或者缓存 TTL 一天），那新文章在收录层面的「隐身期」就是一天——这不是引擎慢，是你的页面还没变。

第二条路径 sitemap 的价值在于覆盖「链接走不到的地方」：翻了很多页的分页、很久以前的老文章、标签聚合页。所以 sitemap 不要求全，要求准：只放返回 200 的、能被索引的、内容值得收录的地址。把 404、重定向、noindex 的页面混进 sitemap，等于告诉引擎「我这批地址质量不高」，长期看会拉低整份文件的信任度。

二、抓取预算：它到底在限制什么

「抓取预算」常被误解成一个固定配额，好像每个站每天能抓多少张。更接近事实的描述是：引擎根据你的站点速度、稳定性、历史质量，给出一个「同时在抓的并发数 + 两次抓取之间的间隔」的组合。你的站响应越快、错误越少，它敢加大并发；一旦连续超时或 5xx，它会立刻退回到很保守的节奏，而且恢复得很慢，往往要好几天。

因此在这一层，能做的事非常具体：

• 降低服务器响应时间。爬虫抓的是 HTML，TTFB 每多一秒，单次抓取窗口能覆盖的 URL 就少一批。数据库慢查询、模板层重复查询是常见原因，先看慢日志再谈优化。
• 别对爬虫做无差别限流。很多站长为了防 CC 在 Nginx 层加了「单 IP 每分钟 30 次」，结果搜索引擎的抓取直接 429。正确做法是按 UA 做例外（虽然 UA 可伪造，但对内网限流的目的只是保护资源），或者把限流阈值设到远高于正常抓取频率。
• 彻底消灭 5xx。一次 500 对预算的伤害远大于一次 404。404 是「这里确实没有」，5xx 是「你的服务器不可靠」。
• 消除重定向链。每个 URL 都先 301 再 200，等于每次抓取花两倍请求。链越长越糟，两跳以上的重定向应该压平。

反过来，有些常见做法是无效甚至有害的：把站点所有页面都提交一遍并不会加速；频繁改 sitemap 的时间戳来「催」引擎，被识别后反而降低信任；在 robots.txt 里对爬虫做精细的分目录限速，很多引擎根本不读非标准的 Crawl-delay，而 Google 明确不支持。

三、HTML 本身的三个高频拖累

排除服务器因素后，抓取效率的瓶颈往往在 HTML 本身。三个最典型的：

页面过大。搜索引擎对单页 HTML 有解析上限（不同引擎略有差异，量级在几 MB），超过之后尾部内容可能直接被丢弃。个人站出现超大 HTML 的原因通常是：把图片以 base64 内联、把整个 CSS/JS 内联、或者正文被模板重复渲染了多遍（有些主题在移动端和桌面端各输出一份完整内容，只靠 CSS 隐藏）。用 curl -s URL | wc -c 抽查十个典型页面，超过 200KB 就值得看看里面是什么。

重复内容与参数变体。同一个内容能通过多个 URL 访问：?from=rss、?utm_source=、排序参数、大小写变体、带不带结尾斜杠。这些都会各自占一个抓取名额。处理方式是定一个规范 URL，其余 301 过去，或者用 canonical 声明；参数类则通过 robots.txt 的 Disallow: /*?from= 之类按需屏蔽（注意：被 Disallow 的页面如果有外链，权重传递会受影响，所以只屏蔽纯追踪参数）。

JS 才能渲染的内容。如果正文是前端异步拉接口再插入，爬虫看到的是空壳。现在主流引擎能执行 JS，但渲染有额外排队，比直接读 HTML 慢得多，也更消耗预算。个人站要收录稳定，正文必须在初始 HTML 里。检测方式很直接：curl -s URL | grep -c "你的正文里某个词"，返回 0 就说明正文不在源码里。

四、用访问日志判断「引擎在做什么」

站长平台上给的数据是聚合的、滞后的。最可靠的一手信息在你自己服务器的 access.log 里——前提是日志格式里有 UA，能区分爬虫（日志字段扩展的细节另一篇讲过，这里直接用）。下面几条聚合能回答关键问题：

# 1. 各爬虫每天抓了多少次
awk '{print $0}' /var/log/nginx/access.log \
 | grep -oE 'Googlebot|bingbot|Baiduspider|YisouSpider' \
 | sort | uniq -c | sort -rn

# 2. 爬虫最常抓的是哪 20 个地址（看看是不是在被无效页面消耗）
grep -E 'Googlebot|Baiduspider' /var/log/nginx/access.log \
 | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

# 3. 爬虫遇到的 5xx 次数（这个数字应该尽量接近 0）
grep -E 'Googlebot|Baiduspider' /var/log/nginx/access.log \
 | awk '$9 ~ /^5/ {print $7, $9}' | sort | uniq -c | sort -rn | head

三条结果分别对应三类问题。第一条看增量：如果某天抓取次数突然掉一半，先查那几天有没有 5xx、有没有改 robots.txt、有没有上 CDN 后返回了错误页。第二条看分布：如果排在前面的全是标签页、归档页、日历页这类低价值地址，说明抓取预算被浪费了，该屏蔽的屏蔽、该合并的合并。第三条看健康度：任何非零的 5xx 都值得逐个复现。

还有一个非常有用的指标是「抓取深度」：在日志里看爬虫访问的 URL 分布，如果几乎全部集中在首页与最新几页，说明它没有往深处走，通常是因为内链结构有问题——深层页面只能靠翻页到达，或者导航里的分类页链接坏了。这时候该做的是把重要页面从首页链接得更直接，而不是继续提交 sitemap。

五、新文章发布的推荐动作

把上面所有内容压缩成一套固定流程，每次发新文章照着做，一两周后收录速度会有明显差异：

1. 发布后立刻确认三处链接可达：首页列表第一屏、分类页、相关文章。用 curl 抓首页看源码里有没有新标题。
2. sitemap 由程序自动生成并更新 lastmod，不要手工改时间，也不要为了催收录反复改。
3. 通过 IndexNow / 站长平台推送一次即可，不重复提交。
4. 确认 curl -s URL 的输出里有完整正文，无重定向、状态码 200、robots meta 不含 noindex。
5. 24 小时后看日志里有没有这个 URL 被抓，抓了几次，状态码是不是 200。

第 5 步是最容易被跳过也最有用的一步。它把「收录慢」这个模糊的感觉，变成了具体的数字：抓没抓、抓几次、有没有出错。有了这个，你才知道下一步该改服务器、改结构还是改内容，而不是盲目地等。

六、几个被反复传播的错误说法

「新站有考核期，三个月才会收录。」新站确实因为外链少、历史短而被保守对待，但这不意味着什么都不做。把内链结构做扎实、页面速度做好、每篇文章真的有内容，收录周期可以从几个月缩短到几天。把所有原因推给「考核期」的人，往往是在掩盖站点本身的质量问题。

「提交越多收录越快。」推送协议的意义是「通知有新内容」，不是「施加压力」。重复提交同一个 URL 对引擎没有额外意义，反而可能被视为噪音。

「收录等于有排名。」收录只是进入候选池，排序是另一回事。这篇文章讲的是让页面尽快进入候选池，能不能排上来取决于内容与竞争度——那是另一个话题，别用收录的指标去衡量排名的效果。

最后一句话总结：收录慢的绝大多数原因都在你自己可以改的地方——响应速度、5xx、重定向、正文是否在源码里、内链是否让人走得到。逐项核对这些，比反复提交 sitemap 有效得多，也是把「收录问题」从玄学变成可执行清单的唯一办法。