收录好的域名，临时维护页面恢复后哪些残留信号需要核对
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /28d64d4192a1.html
📄
收录好的域名，临时维护页面恢复后哪些残留信号需要核对
临时维护页撤下后，先核对残留信号再判断是否继续处理。最容易被忽略的是缓存层：源站已返回正常内容，但CDN或反向代理仍向部分爬虫返回维护页，这会让抓取记录看起来像“还没恢复”。判断依据不是首页是否正常，而是同一URL在不同请求头、不同节点下返回的状态码与正文是否一致。
先分清两种条件：整站维护还是部分路径维护
整站维护通常会把所有请求导向一个维护页，恢复后残留信号集中在状态码、缓存和站点地图三处。部分路径维护只影响特定目录，残留问题往往藏在<link rel="canonical">、内链和分页上。
- 整站维护：优先核对首页、栏目页、详情页三层是否都返回200且正文为真实内容。
- 部分路径维护：优先核对被维护路径的出链是否已从维护页改回目标URL，canonical是否仍指向维护页。
选择依据很简单：如果维护期间所有URL都返回同一页面，属于整站条件；如果只有某个目录返回维护页，属于部分路径条件。两种条件的核对顺序不同，混在一起查会浪费大量时间。
状态码与缓存头：最先要排除的残留
维护期间常见做法是返回503并带Retry-After，恢复后如果源站已返回200，但边缘节点仍缓存503，抓取工具会持续记录失败。核对动作：用带Cache-Control: no-cache的请求和普通请求分别访问同一URL，比较返回的状态码与Age、X-Cache等响应头。
如果两者不一致，说明缓存层有残留，下一步应清理该URL的缓存并等待其自然过期，而不是立刻改robots.txt。robots.txt的抓取限制不等于索引移除，它只影响抓取，不会让已收录的维护页从索引中消失。反过来，如果两者一致且都是200，缓存就不是原因，应转向检查正文和链接。
正文与canonical：维护页内容可能仍被当作有效页面
有些维护页返回200而非503，恢复后如果模板残留，页面正文里仍可能出现“系统维护中”字样，同时canonical指向维护页自身。这种情况下，搜索引擎可能把维护页当作正常内容保留。
核对动作：抓取恢复后的页面，检查<title>、<h1>和正文首段是否已替换为真实内容，并确认canonical指向当前URL而非维护页。如果canonical仍指向维护页，应修正模板并重新发布，然后观察下一次抓取是否带回正确内容。
例外：如果维护页是独立URL且已返回410或301到首页，则不需要逐页核对canonical，只需确认跳转链没有形成循环。
站点地图与内链：恢复后仍指向维护页的入口
站点地图不保证收录，但它能反映站点当前对外声明的URL集合。恢复后如果站点地图仍包含维护页URL，或内链仍指向维护页，爬虫会继续沿这些入口访问旧内容。
- 下载当前站点地图，检查是否还有维护页URL。
- 抽查首页和栏目页的内链，确认没有指向维护页的链接。
- 如果发现残留，更新站点地图并提交，同时修正内链模板。
这一步的结果决定下一步：如果站点地图和内链都已干净，但抓取记录仍显示维护页，问题更可能在缓存或外部链接，而不是站内入口。
一个假设例子：两种条件下的处理差异
假设某站点在维护期间对/product/目录返回503，恢复后源站已返回200。条件A：CDN缓存仍返回503。此时应清理缓存，而不是提交站点地图。条件B：CDN已返回200，但该目录的内链仍指向维护页。此时应修正内链，而不是清理缓存。
两种条件的区分证据是：用无缓存请求访问同一URL，若返回200而普通请求返回503，属于条件A；若两者都返回200但正文含维护字样或内链指向维护页，属于条件B。先确认属于哪一种，再执行对应动作，可以避免在错误层面反复操作。
最后核对一次：状态码、缓存头、正文、canonical、站点地图和内链都指向正常内容后，再观察抓取记录的变化。如果仍有异常，应检查是否有外部链接指向维护页URL，而不是继续修改站内配置。
