Baiduspider抓取：临时维护页面恢复后哪些残留信号需要核对
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b2d69b38674a.html
📄
Baiduspider抓取：临时维护页面恢复后哪些残留信号需要核对
恢复正式页面后，最该核对的不是“有没有重新放行”，而是维护期间留下的三类残留：返回码与重试头、robots与页面级指令、以及缓存与跳转链路。它们不会因为删除维护页就自动消失，而且各自该保留、改写还是退出，取决于维护页当时承担的角色。
先区分维护页是“挡路”还是“替代”
如果维护页是返回503并带Retry-After的挡路页，恢复后应让它彻底退出：正式URL返回200，维护URL不再参与任何跳转。如果维护页是替代正文、返回200的占位页，风险不同——它可能已经被当作正常内容处理，恢复后需要改写或退出，而不是简单删除。
判断依据可以看恢复后短时间内的返回码分布：正式URL是否稳定为200，维护URL是否仍被请求。若维护URL持续被请求而正式URL请求很少，说明旧入口还在被沿用，下一步应检查内链、站点地图和跳转配置，而不是继续改维护页本身。
返回码与重试头：最容易残留的一层
维护期间常见的组合是503加Retry-After。恢复后如果维护URL仍返回503，或者正式URL继承了Retry-After，抓取端会继续按“稍后再来”处理。核对动作是逐条请求正式URL和维护URL，记录状态码与响应头；确认正式URL为200且不带Retry-After，维护URL要么410要么301到正式URL，二选一，不要既保留503又加跳转。
这里有一个容易误判的现象：日志里抓取量下降，可能来自维护期的正常退避，也可能来自恢复后仍被限制。抓取量归零本身不能证明处理正确，还要结合正式URL的返回码和最近一次成功抓取时间一起看。
robots与页面级指令：保留、改写还是退出
维护期间若在robots.txt里整体Disallow，恢复后应尽快退出该规则，但要注意：解除限制不等于内容会被重新处理，robots限制本身也不是可靠的索引移除手段。若维护页的HTML里带了noindex，恢复正式页时这个标签必须一并移除；如果维护页和正式页共用模板，残留的noindex会直接作用到正式内容上。
取舍上可以这样分：
- 临时全站Disallow——恢复后退出，前提是确认没有其他规则依赖它。
- 维护页noindex——随维护页一起退出，正式页单独确认无该标签。
- canonical指向维护页——必须改写为正式URL或自引用，不能保留。
若维护页曾被当作替代内容长期返回200，仅删除页面不够，还要确认canonical和内部链接不再指向它。站点地图同理：把维护URL从站点地图移除只是减少一个信号，不保证收录状态立刻变化。
缓存、跳转与外部入口的连锁残留
CDN或反向代理缓存可能仍保存维护页响应。恢复后请求正式URL却拿到维护页内容，通常先怀疑缓存层。核对动作是带缓存绕过参数请求一次，对比是否返回正式内容；若绕过参数正常、普通请求异常，下一步应处理缓存刷新，而不是改HTML。
跳转链路也要逐跳看：301到302再到维护页的链条，恢复后可能只改了最后一跳。核对时记录每一跳的目标和状态码，确认没有回环或指向维护URL。外部入口方面，若维护公告页曾被分享或引用，这些链接不会自动消失，可以在维护页上放置指向正式页的说明，而不是让它继续返回维护内容。
一个假设例子：三种残留同时出现
假设某站维护期做了三件事：全站robots Disallow、维护页返回503带Retry-After、CDN缓存维护响应一小时。恢复时只删了维护页。此时正式URL可能仍被robots挡住、缓存仍返回维护内容、抓取端仍按Retry-After退避。按顺序核对：先确认robots已放行，再绕过缓存验证正式内容，最后检查响应头无Retry-After。三步都通过后，再观察正式URL的抓取记录；若仍异常，再回到跳转和canonical排查，而不是反复调整维护页。
