📍 WDQWDWQD987AAAAA:216.73.217.17
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /cc46837f29bc.html
📄

搜索引擎爬虫：临时维护页面恢复后哪些残留信号需要核对

维护页撤下、源站恢复 200 之后，爬虫看到的往往不是“新页面”，而是它上次记住的那一版维护页。所以恢复后真正要核对的，不是首页能不能打开，而是缓存、状态码、抓取频次和索引版本之间是否还留着维护期的痕迹。先判断残留属于哪一类，再决定是等待重抓、主动刷新，还是回退某一步改动。

先分清两种残留：缓存型与配置型

恢复后出现“页面正常但搜索结果仍是维护提示”，常见有两种解释，处理方式完全不同。

• 缓存型残留：源站已恢复，但中间层（CDN、反向代理、页面缓存插件）仍按维护期的规则返回旧内容。特征是直接请求源站 IP 或带随机参数的 URL 时内容已正常，而公开 URL 仍返回维护页。
• 配置型残留：维护期的规则没有被完全撤销，例如 Retry-After、临时 503、robots 屏蔽、跳转规则、站点地图里的维护说明还留着。特征是换任何网络、任何参数，返回的响应头或状态码仍与维护期一致。

能区分两者的证据是响应头而不是页面外观。用带请求头输出的抓取方式对比公开 URL 与源站 URL，看 Cache-Control、Age、X-Cache 一类字段是否显示命中缓存，以及状态码是 200 还是 503。若公开 URL 命中缓存而源站正常，属于缓存型；若两者响应头一致且仍带维护特征，属于配置型。

需要逐项核对的残留信号

无论属于哪一类，下面几项都值得在恢复后一小时内过一遍，因为它们会直接影响爬虫下一步怎么抓。

1. 状态码与响应头：维护期常用的 503 是否已全部改回 200；如果当时用了 Retry-After，恢复后应移除或改为合理值，否则爬虫可能继续按旧间隔退避。
2. robots.txt：维护期若临时加了全站 Disallow，恢复后必须确认已撤回。注意抓取限制只影响抓取，不等于索引移除，索引里的旧版本不会因为放开 robots 就立刻消失。
3. 跳转与规范化：维护页是否通过 302 跳转实现，恢复后跳转是否已取消；维护期临时改过的 canonical 是否改回自指。
4. 站点地图：维护期若把 sitemap 替换成维护说明，恢复后要换回真实 URL 列表。站点地图是发现线索，不保证收录，不要把“已提交”当成“已恢复”。
5. 缓存与 CDN 规则：维护期的强制缓存或边缘规则是否还生效，尤其是有较长 TTL 的静态资源。

一个可执行动作是：先对首页和一个代表性内页各发一次带完整响应头的请求，记录状态码、缓存字段和跳转链。如果首页已 200 而内页仍 503，说明维护规则是按路径或按规则集残留的，下一步应去查规则集而不是清整站缓存。

用抓取日志判断爬虫是否已经回来

恢复后抓取量没有立刻回升，并不一定代表处理失败。合理解释至少有三种：爬虫尚未重新调度、退避间隔还没走完、或者它回来了但抓的是缓存版本。要区分这些，看日志里恢复时间点之后的请求。

• 如果恢复后出现 200 响应且 URL 覆盖在扩大，说明重抓已经开始，此时应重点核对返回内容是否为新版本。
• 如果只有零星请求且集中在少数 URL，可能是退避尚未结束，继续观察比立即再改配置更稳妥。
• 如果请求量正常但日志里返回的仍是维护页特征，回到上一节，问题在缓存或配置，不在调度。

需要提醒的是，抓取量归零或某项统计为零，不能单独证明维护处理正确，也不能证明索引已更新，它只说明这一时间段内没有观察到请求。

假设例子：什么时候该等，什么时候该动手

假设某站维护 6 小时，期间返回 503 并设置 Retry-After: 3600，恢复后撤下维护页但忘了移除该响应头。

• 若公开 URL 已返回 200 且无该响应头，只是搜索结果仍显示维护提示，这属于缓存型残留，等待重抓并配合一次缓存刷新即可，不必改服务器配置。
• 若公开 URL 仍返回 503 或仍带 Retry-After，属于配置型残留，需要先修响应头，再考虑是否请求重新抓取。

这个例子的关键判断点不是“恢复用了多久”，而是响应头是否还带维护期特征。先修配置、再处理缓存、最后才谈索引刷新，顺序反了会把可区分的信号搅在一起。

恢复后仍需分别核查的边界

不同搜索引擎对临时维护状态、robots 限制和重新抓取请求的支持情况并不一致，需要分别核查，不能拿一个引擎的表现推断另一个。另外，robots.txt 的抓取限制不等于可靠的索引移除；站点地图不保证收录；HTTPS 也不保证页面安全无漏洞或排名提升。这些边界决定了恢复后的动作应以响应头、日志和实际返回内容为依据，而不是以“已经改回来了”这种主观判断收尾。