午夜时分

太平洋时间凌晨3点，我的生产站点处理的请求量超过了工作日任何时段。这些请求不是来自用户，而是来自爬虫。

Googlebot 正在抓取21,000个页面。Bingbot 正在抓取10,000个。我的综合夜间检查正在遍历15,000篇博客文章和公司页面。一轮预热正在为 Cloudflare 边缘缓存灌入次日流量所需的数据。这些夜间进程触及的页面总量，超过了所有人类访客的总和。

白天构建的站点并非最重要的那个。最重要的，是凌晨3点爬虫所看到的那个。

抓取普查

我每天运行一次抓取普查，统计过去24小时内爬虫访问的内容。普查使用 Cloudflare 的分析 API，按用户代理过滤。这些数字揭示了搜索引擎重视什么：

Google:     21,463  (67%)
Bing:       10,620  (33%)
Combined:   32,083

Jobs:       16,111  (50% of all crawls)
Blog:       298
Locale:     1,233
Programmatic: 257
Companies:  14

招聘页面消耗了一半的抓取预算。Googlebot 每天抓取10,654个招聘页面。招聘站点地图没有上限，每个符合条件的职位列表都被纳入其中。抓取预算的分配告诉我，Google 认为这些是站点上价值最高的内容。

博客文章每天仅获得298次抓取，尽管它们是质量最高的内容。抓取投入的比例（招聘是博客的50倍）与内容投入的比例（博客每页所需的精力是招聘的100倍）完全不匹配。搜索引擎抓取的是能大规模索引的内容，而非投入最多精力的内容。

公司页面每天仅获得14次抓取，尽管站点地图中有7,000多个页面。这是一个抓取预算饥饿问题：招聘页面消耗了大量预算，公司页面几乎无法被发现。夜间数据揭示了这个问题。没有普查，我根本不会知道7,000个公司页面对爬虫来说几乎是隐形的。

410 状态码的启示

普查追踪 HTTP 状态码。其中最值得关注的是 410：Gone（已删除）。

Google 410s:  7,614  (35.5% of crawls)
Bing 410s:    4,494  (42.3% of crawls)

超过三分之一的爬虫请求命中了已过期的招聘页面并返回410。这些职位在爬虫首次发现时确实存在，被索引后又被移除。410告诉爬虫：”此页面曾经存在但已永久删除，请停止请求。”

410比率正在下降。上周 Google 的数据是8,858，本周降至7,614。爬虫正在学习。每天，随着搜索引擎更新索引，幽灵请求的数量都在减少。但学习过程缓慢。Bing 的410比率（42.3%）高于 Google（35.5%），因为 Bing 处理移除信号的速度更慢。

410趋势是最清晰的夜间信号。它告诉我搜索引擎向站点当前状态收敛的速度。410比率上升意味着内容移除的速度超过了爬虫的适应能力；下降则意味着索引正在追赶。均衡状态是零410——即爬虫请求的每个页面都仍然存在。

524 问题

当源服务器在超时窗口内未响应时，Cloudflare 返回524。在一个高频部署日（87次提交），普查显示：

Google 524s:  68  (0.3%)
Bing 524s:    0

24小时内68次源站超时。每一次都意味着 Googlebot 请求了一个页面，Cloudflare 将请求转发给 Railway，而 Railway 未能及时响应。最可能的原因是频繁部署期间 Railway 工作进程重启。每次部署都会重启应用，产生一个短暂的请求超时窗口。

在0.3%的抓取中，Google 看到的是一个故障站点。这些524错误不会出现在任何应用日志中，因为错误发生时应用根本没有运行。错误仅存在于 Cloudflare 和 Railway 之间的空隙中，只能通过抓取普查才能观察到。

次日早晨，524计数降为零。部署已停止，工作进程恢复稳定。夜间数据证实，问题源于短暂的部署波动，而非结构性缺陷。

预热流程

在爬虫到来之前，预热流程先行运行。它通过 Cloudflare 边缘缓存获取每篇博客文章、每个语言版本以及50个公司页面。目标是确保当 Googlebot 访问页面时，获得的是缓存响应而非等待源站渲染。

这一差异举足轻重。缓存后的博客文章80毫秒返回，未缓存的则需要从源站花费1.5秒。Googlebot 的抓取速率预算以每秒请求数衡量。响应越快，相同窗口内抓取的页面越多。温热的缓存能将有效抓取覆盖率提升一倍。

预热流程对用户不可见。没有任何人类访客会从凌晨2点缓存的博客文章中受益。但预热流程决定了 Googlebot 在夜间窗口内发现300篇还是600篇博客文章。SEO 影响是实实在在的，尽管没有人看到这一机制。

黑夜揭示的真相

每天早晨我都会查阅夜间日志。模式始终相同：大部分正常，少数异常，一两个值得深入调查的问题。这个节奏很平淡。价值恰恰在于这份平淡。

平淡的夜晚意味着部署没有破坏任何东西，爬虫找到了预期的内容，缓存正常运作，站点已为次日流量做好准备。不平淡的夜晚意味着有变化发生：新的错误模式、失效的缓存规则、或暗示排名信号变化的抓取预算偏移。

抓取普查向我揭示了7,000个公司页面对 Google 而言是隐形的。白天的任何指标都无法发现这一点。用户分析显示公司页面零流量，我曾将其归因于需求不足。普查显示的是公司页面零抓取，这意味着 Google 甚至还没有评估这些页面。问题不在于需求，而在于发现。

524分析向我揭示了 Railway 部署会产生源站超时窗口，恰好被 Googlebot 触及。任何应用监控都无法发现这一点，因为超时期间应用并未运行。问题存在于部署与可用性之间的基础设施间隙中。

410趋势向我揭示了 Bing 处理移除信号的速度比 Google 慢20%。这对 SEO 至关重要：过期的招聘页面在 Bing 索引中存留更久，可能向通过 Bing 驱动的搜索界面（DuckDuckGo、Yahoo）搜索的用户展示过时的结果。

这些洞见均来自夜间数据。白天告诉你用户做了什么，黑夜告诉你无人值守时基础设施在做什么。两者都重要。对 SEO 而言，黑夜更为关键。

常见问题

抓取普查是如何运行的？

普查使用 Cloudflare 的 GraphQL 分析 API（httpRequestsAdaptiveGroups），按用户代理模式（%Googlebot% 和 %bingbot%）过滤。它根据 URL 路径前缀对页面分类并汇总状态码。脚本在30秒内完成运行，生成 Google 和 Bing 抓取行为的对比报告。

为什么不用 Google Search Console 获取抓取数据？

Google Search Console 的抓取统计有2-3天的延迟，且粒度有限。Cloudflare 普查是实时的（过去24小时），包含 GSC 不提供的状态码、内容分类和缓存状态。GSC 适合观察趋势，普查适合做运营决策。

预热流程会增加 Cloudflare 费用吗？

不会。Cloudflare 缓存由任何请求触发填充，无论来源。预热流程使用标准 HTTP 请求，计入正常请求配额。在免费计划中，缓存响应没有请求限制。预热期间的源站请求计入 Railway 的带宽，但以15,000个页面、平均每页50KB计算，每次预热总量约为750MB。

如果爬虫改变行为怎么办？

普查捕获爬虫的一切行为，不受变化影响。抓取模式的偏移（更多招聘页面、更少博客页面）会立即反映在下一次普查中。跨天的趋势数据能揭示这种偏移是一次性异常还是持续性变化。

来源

本文基于2026年3月以来通过 Cloudflare GraphQL API 收集的每日抓取普查数据。普查工具：~/Projects/Utility/crawl_census.py。夜间检查工具：~/.claude/skills/nightcheck/。