robots txt协议：临时维护页面恢复后哪些残留信号需要核对
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /13110fff6fec.html
📄
robots txt协议：临时维护页面恢复后哪些残留信号需要核对
临时维护页撤下后，真正需要核对的是恢复动作本身留下的痕迹：robots.txt 是否仍保留维护期规则、维护页是否仍返回可抓取状态、以及搜索引擎端是否还缓存着旧信号。这些残留不会因为页面恢复而自动消失，判断依据要分两种情况——维护期是否改过 robots.txt，以及维护页是否用了 503 或 200。
先分清维护期的两种做法
第一种做法：维护期只把全站返回 503，robots.txt 完全没动。恢复后要核对的是 503 是否已彻底撤销，而不是 robots.txt。用 curl -I 对首页和几个代表性 URL 逐个取响应头，确认状态码回到 200，且不再带 Retry-After。如果某些路径仍返回 503，说明恢复不完整，下一步应继续排查这些路径而非改 robots.txt。
第二种做法：维护期在 robots.txt 里加了 Disallow: /，或用 Disallow 指向维护页。这种情况下，页面恢复不等于抓取恢复——robots.txt 是独立文件，必须单独改回。核对时直接请求 /robots.txt，逐行看是否还残留维护期规则，尤其是写在文件末尾、容易被忽略的整站封禁行。
核对残留信号的具体动作
把 robots.txt 拉回本地，和恢复前的备份逐行对比，而不是凭印象判断。重点看三类行：整站 Disallow: /、指向维护页路径的 Disallow、以及维护期临时加的 Sitemap 指向。任何一条还在，抓取就仍被限制。
改回 robots.txt 后，用一个此前被维护规则命中的 URL 实测：请求该 URL 的响应，确认状态码正常，再对照 robots.txt 规则判断它现在应处于允许范围。这一步的意义在于区分两种解释——页面能打开，可能是缓存或直接访问的结果，并不等于爬虫已被放行。只有规则和响应都对上，才能进入下一步。
如果维护期用的是 503，还要确认服务器没有把 503 缓存到 CDN 或反向代理层。做法是对同一 URL 从不同网络位置各请求一次，比较状态码是否一致。不一致说明边缘节点仍有旧响应，恢复动作需要延伸到缓存刷新，而不是只改源站。
哪些信号不能单独当作恢复完成的证据
抓取日志里某段时间该 URL 的请求量归零，或恢复后突然出现少量请求，都不能单独证明处理正确。归零可能只是爬虫调度周期未到，突然出现也可能来自其他路径的连带抓取。这些现象存在多种合理解释，需要和 robots.txt 内容、响应状态码一起看。
robots.txt 放行也不等于索引状态立即恢复。抓取限制只约束爬虫行为，不负责移除已有索引；如果维护期页面被收录，恢复后旧快照可能仍存在一段时间。站点地图重新提交同样不保证收录，它只是提供发现线索。把这几件事混为一谈，容易在恢复后误判进度。
一个假设的核对顺序
假设某站维护期同时做了两件事：全站返回 503，并在 robots.txt 顶部加了 Disallow: /。恢复时只撤了 503，忘了改 robots.txt。此时直接访问首页正常，但爬虫仍被拒绝。
按以下顺序核对：先取 /robots.txt 确认无整站封禁；再对首页取响应头确认 200 且无 Retry-After；然后抽查维护期被命中的 URL，确认规则与响应一致；最后检查缓存层是否残留 503。每一步的结果决定下一步——robots.txt 仍有封禁就先改它，响应仍异常就先查服务端，两者都正常再考虑缓存与索引层面的观察。
例外情况：如果维护期从未改动 robots.txt，且全站始终返回 200 只是内容替换，那么残留信号主要在内容层和缓存层，robots.txt 核对可以跳过，重点转向确认维护页内容是否已从可抓取路径中移除。
