百度抓取，临时维护页面恢复后哪些残留信号需要核对
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /351d7fbdfe10.html
📄
百度抓取，临时维护页面恢复后哪些残留信号需要核对
维护页撤下、源站恢复后，百度抓取看到的可能仍是维护期间的响应。要核对的是四类残留信号：状态码是否仍返回 503 或 200 的维护内容、缓存层是否还留着旧响应、robots 或站点地图是否仍指向维护状态、以及被替换的 URL 是否还留在索引里。缺少日志权限时，用 curl -I 和百度搜索资源平台的抓取诊断做最小验证，但只能证明“此刻某个节点返回什么”，不能证明百度已经重新抓取。
先核对状态码：维护用的 503 是否真的撤掉了
维护期常见做法是整站返回 503 加 Retry-After。恢复后如果只替换了页面内容，状态码仍可能是 503，百度会继续按“暂时不可用”处理，而不是重新抓取新内容。用以下动作逐层确认：
- 对首页和一个内页分别执行
curl -I，看第一行状态码。若仍是 503，先查反向代理或 CDN 的规则，而不是改页面。 - 如果返回 200 但正文仍是“系统维护中”，说明维护页被缓存或路由未切回，属于内容残留而非状态码残留。
- 如果首页 200、内页 503，说明恢复不完整，优先排查内页依赖的服务。
这一步的结果直接决定下一步：状态码未恢复时，任何提交或推送都是无效动作，应先修基础设施。
再核对缓存层：源站恢复不等于边缘节点恢复
源站已经返回新内容，但 CDN、反向代理或页面缓存仍可能持有维护期响应。判断依据是同一 URL 多次请求的响应头是否一致：若 Age 较大、X-Cache 显示命中，或不同节点返回不同内容，说明缓存未刷新。
假设一个场景：源站 10:00 恢复，CDN 默认缓存 1 小时，那么 10:30 时百度抓取仍可能拿到维护页。此时可执行的动作是刷新该 URL 的缓存并确认响应头中的缓存标识已变化。结果影响下一步——缓存未清完就提交抓取，等于让百度再取一次旧内容。
核对 robots.txt 与站点地图是否仍停留在维护状态
维护期有人会临时在 robots.txt 里加 Disallow: /，或用站点地图只保留维护页。恢复后要确认：
- robots.txt 是否已移除维护期的全站禁止规则。注意，抓取限制不等于可靠的索引移除；反过来，解除限制也不等于百度会立刻重新抓取。
- 站点地图是否已换回正常 URL 列表。站点地图不保证收录，它只是发现线索。
- 若维护期提交过临时站点地图，确认它已被替换，避免百度继续按旧列表抓取。
这里的取舍是：如果维护只持续很短时间且未改 robots，通常不必额外操作；如果改过 robots 或站点地图，就必须逐项还原并记录改动时间，供后续判断抓取异常的时间起点。
核对索引与 URL 状态：被替换的地址是否需要处理
维护页有时部署在独立地址（如 /maintenance），恢复后该地址可能仍可访问且被百度抓取过。需要确认它返回 404、410 还是 200：
- 若返回 200 且内容与主站重复，考虑是否需要移除或跳转。
- 若返回 404，属于正常消失，但不要据此认为主站索引已同步更新。
- 核对主站 URL 在搜索结果中的标题与摘要是否仍是维护文案。摘要未更新可能只是缓存展示，不能单独证明百度未重新抓取。
缺少权限时，最小动作是只核对你能访问的 URL 及其响应头，并记录时间点。不能推出的结论包括：某个 URL 恢复 200 就等于全站恢复，或抓取诊断成功就等于排名会恢复。
把核对结果转成处理顺序
按“状态码 → 缓存 → robots 与站点地图 → 索引残留”的顺序处理，每步只在上一步确认后才推进。若某一步缺少数据，标记为待验证而不是跳过。完成全部核对后，再决定是否需要提交抓取或观察后续日志；在此之前，任何提交都建立在未确认的假设上。
