爬虫控制临时维护页面恢复后哪些残留信号需要核对
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e6fe75dbbb1a.html
📄
爬虫控制临时维护页面恢复后哪些残留信号需要核对
维护页撤下后，最该核对的是那些“看起来还在维护”的残留信号：返回码、页面内容、缓存头、robots 规则、站点地图与站内链接。它们不一定都还在拦截，但只要有一处仍指向维护状态，爬虫就可能继续按旧信号处理，恢复后的抓取节奏和收录判断都会受影响。
先看一个矛盾现象：页面恢复了，抓取却没恢复
常见情况是：维护页已经撤掉，正常页面也能打开，但日志里对同一批 URL 的请求仍偏少，或者抓到的还是旧版本。这里有两个解释，需要分开验证。
- 解释一：残留信号仍在生效。比如服务器对部分路径仍返回 503，或 robots.txt 里还留着对维护路径的 Disallow，或页面响应头带着很长的 Cache-Control。
- 解释二：残留信号已清，但恢复本身需要时间。爬虫降低抓取频率后，不会因为一次 200 就立刻回到原节奏；旧缓存也可能在中间层继续提供维护页。
区分这两种解释的证据不是“页面能不能打开”，而是响应元数据：状态码、响应头、robots 内容、站点地图里的 URL 状态，以及站内链接是否还指向维护页。如果这些全部正常，抓取偏少更可能是节奏恢复问题；如果还有异常项，先处理它，不要急着调其他设置。
返回码与响应头：最容易漏掉的残留
维护期间常见的做法是返回 503 并带 Retry-After。恢复后需要确认三件事。
- 正常页面返回 200，而不是 503、502 或 302 跳到维护页。
- 维护页本身如果保留，应明确返回 410 或 404，而不是继续返回 200；否则它仍是一个可被抓取的正常页面。
- 检查 Cache-Control、Expires、Retry-After 是否还带着维护期的长值。响应头残留会让中间缓存继续提供旧内容。
一个假设例子：某栏目维护时对全部子路径返回 503 并设置 Retry-After: 86400。恢复后只把首页改回 200，子路径仍返回 503。此时爬虫对子路径的抓取会继续被推迟，而首页看起来完全正常。动作是先抽查若干子路径的响应码，结果决定下一步是修服务器规则还是只等抓取节奏恢复。
robots.txt 与站点地图：两个独立核对项
维护期临时加上的 robots.txt 规则经常被遗忘。需要确认：Disallow 是否还指向已恢复的路径；是否误把整站或关键目录挡住。这里要记住一个边界：robots.txt 的抓取限制不等于可靠的索引移除——它阻止抓取，不保证已收录内容从结果中消失。反过来，删掉 Disallow 也不代表立刻恢复收录。
站点地图同样要单独核对：维护期如果把它替换成只含维护页的版本，恢复后应换回正常 URL 列表；站点地图不保证收录，它只是发现入口。若站点地图仍指向维护页或已下线的旧地址，爬虫会继续拿到无效线索。动作是抓取一次 robots.txt 和站点地图原文，逐条比对当前真实 URL；若两者都正常，残留信号的范围就缩小到响应头和站内链接。
站内链接与旧合作关系：哪些该留、哪些该退
维护页恢复后，站内导航、面包屑、旧专题页和外部合作方留下的链接，可能仍指向维护地址或已退出的旧系统。这里要做的不是全删，而是区分保留与退出。
- 仍然有价值的旧内容：恢复其正常入口，确认链接指向最终 URL，而不是经维护页跳转。
- 已退出的旧系统或旧合作关系：把指向它的链接改为 410 或移除，避免爬虫反复抓取无效地址。
- 临时维护页：如果不再需要，返回 410；如果还要复用，保留但不要让它出现在导航和站点地图中。
动作是抽查站内主要入口和外部可见链接的落点，结果会告诉你残留信号是集中在少数模板，还是分散在多个旧页面。若是模板问题，改一处即可；若是分散链接，需要按“保留有价值部分、退出无效部分”逐项处理。
核对顺序与判断依据
建议按以下顺序核对，每一步的结果决定下一步：
- 抽查正常页面与子路径的状态码和响应头。若仍有 503 或长缓存，先修服务器与缓存层。
- 读取 robots.txt 和站点地图原文。若仍指向维护状态，先更新这两处。
- 检查站内链接与旧入口。若仍跳维护页，按保留或退出分别处理。
- 以上都正常后，再观察抓取日志。此时请求偏少更可能是节奏恢复，而不是残留拦截。
需要提醒的是，请求量、抓取量或某项统计归零，不能单独证明处理正确。它也可能是抓取预算转移、日志采样变化或页面本身不再被需要。把响应元数据和链接状态作为主证据，统计只作辅助参考，才能判断残留信号是否真的清干净。
