遇到错误页面却返回 200 OK,先别急着改服务器配置。更稳妥的做法是:把该 URL 当作一个待判定的对象,分别记录“响应状态”“页面正文实际表达的含义”“页面上是否仍保留有价值内容”三项证据,再决定是恢复为正常内容页,还是改为带正确状态码的退出页。三项证据不一致时,以内容意图为准,而不是以状态码为准。
从你手里那个具体 URL 开始,而不是从“网站收录状态”这种整体描述开始。取一条仍被链接、仍可能被访问的旧地址,用命令行请求它的响应头,例如 curl -I https://example.com/old-page。假设返回 HTTP/1.1 200 OK,同时页面正文写着“该产品已下线”或只剩一段空白模板,这就构成了典型的不一致:状态码说“这里是正常内容”,正文说“这里已经没有内容”。
记录时要区分三种情况,它们对应的处理方向完全不同:
把这三类分开记录后,你会发现问题往往集中在少数模板上,而不是全部旧 URL,这直接决定下一步是修模板还是逐页处理。
状态码是给抓取和缓存系统看的,正文是给用户看的。两者必须表达同一件事。如果正文说“页面不存在”,状态却返回成功,抓取方可能把它当作可索引的正常页面,用户则看到一个自相矛盾的页面。此时先确认这是模板默认行为,还是个别页面的特殊处理。假设某旧系统对所有请求统一返回 200,只在正文里输出错误提示,那么问题根源在应用层,不在单条 URL。
有些旧页面本身内容已过时,但被外部链接引用,或承担着站内导航作用。这类页面不宜直接退出。可以先保留一个精简版本,把仍有效的部分集中呈现,并明确标注当前状态。判断依据不是页面新旧,而是它是否还被引用、是否还有用户会到达。若无法确认引用情况,可先观察一段时间的访问来源,再决定保留还是退出。
内容永久移除、且没有替代地址时,返回表示“已永久移除”的状态更合适;内容只是临时不可用,则应返回表示“暂时不可用”的状态;内容已迁移到新地址,应使用跳转并保留原地址的可访问性。这里的关键不是记住状态码编号,而是让状态与正文说同一件事。若正文写“已迁移”,状态却是成功,用户和抓取方都无法从响应本身得知迁移事实。
Content-Type。这个流程的价值在于:它把“收录状态异常”拆成了可复核的动作。假设你处理了 20 个旧页面,其中 18 个来自同一模板,那么修模板后只需抽查少数页面即可确认整体方向,而不必逐页重做。
旧系统或旧合作关系退出,不等于所有旧页面都要消失。可以保留三类内容:仍被外部引用的说明页、仍能回答用户问题的核心段落、以及指向当前有效内容的导航入口。保留时要注意,页面必须自洽——如果只保留片段,就要让状态与这个片段的性质匹配,而不是继续沿用原来的成功响应。
另外,robots.txt 的抓取限制不等于可靠的索引移除,站点地图也不保证收录。用抓取限制来“隐藏”一个误返回成功的错误页,只是减少了被抓取的机会,并不能解决状态与内容不一致的问题。若页面已无价值,正确做法是让它以明确的状态退出,而不是靠抓取规则掩盖。
处理完成后,重新请求目标 URL,确认状态码与正文语义一致,并记录处理前后的响应差异。后续观察时,抓取量或某项统计归零,并不能单独证明处理正确——它也可能来自抓取频率正常波动、站点整体调整或外部链接变化。要结合响应状态、正文内容、站内链接指向三项一起看,才能判断这次处理是否达到预期。
如果发现同一模板下仍有页面返回成功却无实质内容,说明模板修复没有覆盖全部分支,需要回到第二步重新分类。若个别页面状态正确但正文仍指向旧信息,则问题在内容层,不在状态层,应单独更新正文或补充跳转。把这两类问题分开,才不会用同一种改法反复试错。