先给结论:这类问题几乎都不是 robots.txt 语法本身写错,而是错误页面在 HTTP 层被当成正常页面输出,导致状态码与页面内容互相矛盾。核对方法只有一条主线——分别确认“服务器返回的状态码”“页面里实际渲染的内容”“抓取工具看到的最终响应”三者是否指向同一件事。三者不一致时,优先修状态码,再谈 robots.txt 的抓取规则。
把一个出问题的 URL 当作核对对象,按下面顺序取证据,不要跳步:
Content-Type。例如 curl -I https://example.com/missing-page。这样排序的原因是:如果状态码本身就错了,robots.txt 无论怎么写都无法把错误页变成“不存在的页面”。抓取限制只影响是否允许抓取,不改变服务器对外的响应语义。
robots.txt 的 Disallow 只是请求抓取工具不要抓取某段路径,它并不等于移除索引,也不等于告诉搜索引擎“这个页面不存在”。一个返回 200 的错误页,即使被 Disallow 挡住,已经建立的索引记录仍可能保留,而新抓取又拿不到内容去更新判断。结果是页面长期停在“状态正常但内容无意义”的状态。
反过来,如果错误页正确返回 404 或 410,抓取工具能明确识别该资源不存在,这比任何 robots.txt 规则都更直接。所以核对顺序必须是:先让状态码与内容一致,再决定 robots.txt 里是否需要写、写哪条。
以你手上任意一个可疑 URL 为对象,做下面这组动作,并记录每步结果如何影响下一步:
完成前四步后再改 robots.txt,动作才有意义。若前四步已确认状态码错误,此时改 robots.txt 只会掩盖问题,让后续排查更难。
假设某站点把不存在的商品页统一返回 200,并显示“商品已下架”。你按上面的步骤改成返回 404,同时保留一段有意义的提示文案。改动后可能出现两种结果:
需要说明的是,状态码从 200 变成 404 之后,抓取量或请求量的变化不能单独证明处理正确。请求量归零也可能是抓取工具暂时降低了对该路径的访问频率,或该 URL 本来就没有被大量引用。判断依据仍应回到响应头与正文是否一致。
只有在两种条件下,才考虑用 robots.txt 处理这类页面:
如果该 URL 对应的是已下架但有替代页面的资源,更合适的做法是返回 301 指向替代页,而不是 404 或 Disallow。选择哪种,取决于这个地址未来是否还有对应内容,而不是取决于 robots.txt 写起来是否方便。
无论选哪种,核对动作都应在改动后重新执行一遍:先看响应头状态码,再看正文,最后看 robots.txt 是否按预期拦截或放行。三者一致,才算这次处理完成。