宕机不仅会在当下让你损失访客。它还会抑制搜索和 AI 爬虫回访的频率 — 这种影响会在网站恢复之后很久仍出现在你的日志和 Search Console 中。
uptime（正常运行时间）常常被当作运维问题来谈论，而即便在 SEO 语境中被提起，也只是被当作一种模糊的声誉风险。基于对一系列不同规模网站（包括一些每月请求量极高的网站）抓取行为的审计，我们可以给出比这更具体的说法：downtime（宕机）对搜索和 AI 爬虫如何看待你的网站有一种机制性的、可追踪的影响，而且这种影响并不会随着网站恢复而结束。只要你知道该看哪里，它在日志中一目了然，而大多数团队从来不去看。
爬虫在宕机期间实际看到了什么
当你的源站不可达或返回 5xx 错误时，在该时段内命中你的每一个爬虫 — Googlebot、Bingbot、GPTBot、ClaudeBot、PerplexityBot — 都会记录一次抓取失败。从爬虫一侧来看，这就是整个事件：没有页面内容、没有关于什么发生了变化的信号，只有一次失败。接下来会发生什么取决于失败持续了多久，以及该特定爬虫的重试逻辑是如何调校的，但各大主流爬虫的总体模式是一致的：零星的几次失败会被视为暂时性的，并按正常时间表重试；而持续不断的失败模式则会被视为网站不可靠的信号，爬虫于是会退避。
这种退避正是大多数人忽略的部分。它不仅仅是“我们在宕机期间无法抓取你”。而是“我们现在会在一段时间内更少地抓取你，包括在你恢复之后”，因为如果不给爬虫时间去证明事实并非如此，它就无法区分一次一小时的短暂波动与一段更长模式的开端。对于大型网站而言，这种降低的抓取频率会直接抑制新页面、更新内容和已修复问题被重新拾取的速度 — 这正是“crawl budget”的实际含义，我们在 Crawling & Indexing 指南中对此有更深入的介绍。
这在服务器日志中是什么样子
如果你拉取跨越宕机时段的服务器日志，这个模式通常毫不含糊：针对已知爬虫 user-agent 的 5xx 响应出现激增，随后是每日爬虫总请求量的可测量下滑，且这种下滑会持续到网站修复之后 — 通常持续数天，对于一开始抓取历史就较薄的网站，偶尔会更长。原本抓取频率就很强的网站往往恢复得更快；而一开始就很少被抓取的网站可能要花明显更长的时间才能回到基线，因为能告诉爬虫这个网站值得按紧凑时间表回访的既有信号更少。
这在实际中之所以重要，原因在于：如果你只从访客侧监控 uptime（首页现在是否能在浏览器中加载），你会知道宕机本身，却看不到这第二个更安静的、对抓取频率的影响。它会出现在 Search Console 的抓取统计和你自己的服务器日志中，而不是浏览器标签页里。
同样的问题，也发生在 AI 爬虫身上
以上一切同样直接适用于 AI 应答引擎背后的爬虫。GPTBot、ClaudeBot 和 PerplexityBot 都依赖于能够抓取你的内容来进行索引并最终引用它 — 一次宕机对它们而言不可见的方式，与对 Googlebot 不可见的方式完全相同，而持续不断的抓取失败模式也会对它们回来检查更新的频率产生同样的寒蝉效应。如果你正在积极致力于 GEO 可见度（参见我们的 GEO 与 AI 可见度指南），一次未被监控的宕机正在悄无声息地抵消其中的一部分工作，而且没有任何错误信息指向原因。
在它恶化之前发现它
解决办法在原理上并不复杂：在几分钟内而非几天内就知道你的网站停止了响应，这样宕机时段的长度是以分钟来衡量的，而不是以有人自然发现它所需的小时来衡量。在实践中，这意味着：一种按固定间隔、独立于你自身流量来检查网站的合成监控（仅靠真实用户监控无法快速发现低流量网站的宕机，因为你是在等待一个真实访客去撞上那次故障）、一个能立即送达真人的告警而不是躺在没人盯着的仪表盘里，以及 — 那个容易被跳过的部分 — 一份事件记录（何时开始、持续了多久、响应码是什么样的），这样你才能真正把之后的抓取频率下滑与某个具体的已知原因关联起来，而不是靠猜。
SearchVitals 的 uptime monitoring 会对你追踪的每个网站运行持续检查，记录带有开始/结束时间和响应详情的事件，并在网站宕机或恢复的那一刻通知你 — 正是你日后在 Search Console 中解释抓取频率下滑时希望手头具备的那份事件记录。
这只是更大可靠性图景中的一块
宕机是一类更广泛问题中最尖锐的表现 — 缓慢的 TTFB、负载下未缓存的响应、只有在流量高峰时才会暴露的 CDN 配置错误 — 这些问题都会削弱抓取行为，却从不会产生一个干净利落的“网站宕机”事件。我们在那篇关于损害 SEO 的架构问题的文章中深入探讨了这更广泛的架构图景，包括 JavaScript 渲染和 CDN 配置如何影响爬虫实际接收到的内容。