火车头采集器使用，产品停用后原有页面保留还是退役
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e31dd39541d1.html
📄
火车头采集器使用，产品停用后原有页面保留还是退役
结论先给出：不要因为产品停用就整批删除或整批保留。判断依据是页面是否仍能独立满足搜索需求，以及它是否还有可承接的替代内容。满足其一就保留并改造，两个都不满足才退役。下面用两种条件展开，并给出可执行的动作与例外。
条件一：页面仍有独立搜索需求，保留并改造
产品停用不等于需求消失。用户可能仍在搜索该产品的使用方法、参数、兼容配件、替代方案或故障处理。这类页面如果直接删除，原本积累的链接和访问入口会一起断掉，后续再想恢复成本更高。
判断证据可以看三点：页面是否长期有自然访问；访问者是否在页面上继续点击或停留；站内是否还有同类产品可以承接。三点里满足两点，就按保留处理。
具体动作是改标题和首段，把“购买”“下单”这类指向停售产品的表述改为“已停用说明”“替代型号”“历史版本资料”。同时保留原有可用的参数和教程正文，在页面顶部加一条状态说明，并指向当前在售的替代页面。
这个动作的结果会直接影响下一步：改造后如果页面访问没有明显下滑，说明需求仍在，可以继续补充替代对比内容；如果访问持续走低且没有站内点击，再考虑退役，而不是一开始就删。
条件二：页面只服务于已停售交易，退役并做承接
如果页面存在的唯一目的是让用户完成购买，正文只有价格、库存和下单入口，产品停用后没有任何可读信息，那么保留它只会让访问者落到一个无法完成动作的页面。这类页面适合退役。
退役不等于直接返回 404。更稳妥的做法是设置 301 跳转到最接近的替代产品页或品类页，让原有入口继续可用。只有当站内确实没有相关替代内容时，才让页面返回 404 或 410。
实施时先导出这批页面的 URL 清单，逐条确认跳转目标是否存在且内容相关。跳转目标不相关，比保留一个停用页面更伤体验。
用采集器批量处理时，先分组再动手
用火车头采集器使用批量规则处理这类页面时，容易犯的错误是把“停用”当成统一条件，对所有页面套同一条删除或改写规则。更合理的顺序是先分组。
- 第一组：有自然访问、有替代产品，标记为保留改造。
- 第二组：无访问、有替代产品，标记为跳转退役。
- 第三组：无访问、无替代产品，标记为直接退役。
分组完成后，再分别配置采集规则：第一组只替换状态字段和首段模板；第二组生成跳转映射；第三组生成删除清单。这样每组动作的结果可以单独观察，不会互相干扰。
一个假设例子：改造后访问下滑该怎么读
假设某产品页停用后按保留处理，改掉了购买按钮并加了替代链接。两周后自然访问下降。这个下降不能单独证明改造做错了，也不能单独证明该退役。
合理解释至少有三种：搜索需求本身在衰减；页面标题改动后与用户查询的匹配度下降；替代链接把访问分流到了别的页面。要区分原因，可以对比同期同类停用页面的访问变化，并查看站内点击去向。如果只有改过标题的页面下滑，问题更可能在标题；如果整批停用页都在下滑，问题更可能在需求本身。
这个判断会决定下一步：前者应回调标题措辞，后者才进入退役评估。
例外：有外链或作为资料引用的页面不要轻易退役
有些页面虽然产品停用，但被外部文章、论坛或文档当作资料引用。这类页面即使自身访问不高，也不适合直接删除。删除会让引用方链接失效，也会丢失已有的外部入口。
处理方式是保留页面并明确标注停用状态，把正文中的失效信息修正，但不移除可引用的参数、版本说明或历史资料。只有在确认没有任何外部引用、站内也无承接时，才按退役处理。
抓取、索引和排名是不同环节，页面被删除后不再被抓取，不等于原有入口自动转移到新页面，所以退役动作必须配好跳转或承接，否则访问会直接断掉。
