canonical：临时维护页面恢复后哪些残留信号需要核对
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /fd300125334f.html
📄
canonical：临时维护页面恢复后哪些残留信号需要核对
恢复正式内容后，最容易出现的矛盾是：页面本身已经正常，但抓取工具或索引观察里仍显示旧维护页的痕迹。这通常有两种解释：一是残留信号来自缓存与历史抓取记录，会随重新抓取逐步消退；二是维护期间的 canonical、状态码或链接结构确实把信号引向了错误目标，需要人工修正。判断属于哪一种，不能只看一个指标，而要把响应头、HTML 声明、内链和抓取记录放在同一时间线上核对。
先核对维护页是否留下了指向自身的 canonical
维护期间常见的做法，是让所有请求临时返回同一张维护页，并在该页写上指向自身的 canonical。恢复后如果这张页仍可访问，或者正式页在某种条件下仍返回维护页的 HTML，那么残留的 canonical 会把代表页指向维护地址。核对方法是直接请求正式 URL，查看返回的 HTML 中 <link rel="canonical"> 指向哪里，同时确认响应头里的状态码不是 503 或 302 跳向维护页。
这里要区分两个结果：如果正式 URL 返回 200，canonical 指向自身，那么此前观察到的维护页信号更可能是抓取缓存；如果正式 URL 仍返回维护页内容或 canonical 指向维护地址，则属于必须修正的配置残留。前一种情况下，下一步是等待重新抓取并观察变化；后一种情况下，下一步是修正输出，而不是继续等待。
状态码与重定向链是否已经彻底退出
维护期间使用的 503、302 或临时跳转，恢复后不一定立刻从抓取记录里消失。需要核对的是当前响应，而不是历史记录：正式 URL 是否直接返回 200，是否还存在一跳或多跳重定向，重定向终点是否就是正式页本身。若重定向链中仍有维护地址，抓取工具会继续把维护页当作路径中的一环。
一个可区分的证据是：直接请求正式 URL 时，用不跟随重定向的方式看第一跳状态码。如果第一跳就是 200，说明服务端已恢复；如果第一跳仍是 3xx 且 Location 指向维护页，说明残留发生在服务端配置层。这个结果决定下一步是检查应用输出，还是检查反向代理与缓存层。
内链、站点地图与抓取记录里的旧指向
页面恢复后，站内其他页面可能仍链向维护地址，或者站点地图中仍保留维护页 URL。站点地图不保证收录，但持续提交旧地址会延长维护页被重新发现的机会。核对时抽取若干入口页和列表页，检查链接目标是否为正式 URL；再检查站点地图中是否还有维护页条目。
抓取记录能提供另一组证据：维护页 URL 是否仍在被抓取，正式 URL 的抓取频率是否已经恢复。但抓取量归零或某项统计下降，不能单独证明处理正确，也可能只是抓取预算重新分配或观察窗口太短。更稳妥的做法是把抓取记录与响应头、canonical 声明对照，三者一致时才判断残留已经清除。
用一个小对照把分歧变成可核对项
假设维护期间全站返回 503 并带维护页 canonical，恢复后运维认为“服务已恢复”，SEO 认为“索引里还是维护页”，两边各说各话。可以把分歧拆成三个可核对项：
- 正式 URL 的第一跳状态码是否为 200；
- 正式 URL 的 HTML 中 canonical 是否指向自身；
- 站内入口与站点地图是否还出现维护地址。
三项全部通过，残留更可能是历史抓取记录，动作是继续观察正式 URL 的重新抓取；任一项不通过，动作是先修对应输出，再重新核对。这样处理的好处是，不需要争论“恢复了没有”，而是让每个角色看到同一组事实。
核对顺序与适用条件
建议的顺序是：先看正式 URL 的响应头，再看 HTML 中的 canonical，然后看内链与站点地图，最后才看抓取与索引观察。这个顺序的原因是，前三项是站点可以控制的输出，最后一项受抓取节奏影响，不能反过来用观察结果推断输出一定正确。
适用条件是：维护期间确实使用过统一维护页或临时状态码，且恢复后正式内容已可访问。如果维护期间只是短暂停机、没有输出 canonical 或跳转，那么残留信号的范围会小得多，只需核对状态码与内链即可。不同搜索引擎对临时状态与 canonical 的处理节奏不同，涉及具体搜索引擎时应分别核查其文档与抓取表现，而不是套用同一结论。
