可行边界是:不改模板的前提下,你只能调整模板之外的信号层——URL 形态、服务器响应头、robots.txt、站点地图、页面内可注入的少量标记,以及提交入口本身的使用方式。一旦某个问题必须改模板才能解决(例如批量修正正文里的错误链接、给全站加 canonical),那就超出边界,只能走局部覆盖或数据层替换,而不是继续在提交入口上反复试。
遗留系统最常见的误判,是把抓取层的问题当成提交层的问题。提交入口只负责把 URL 告知百度,它不承诺抓取,更不承诺收录。所以第一步不是再提交一次,而是取一个具体 URL,分别核对三件事:
noindex 或等价标记挡住。这三项都能在模板之外检查或调整。如果第一项就不成立,继续用提交入口只是重复劳动。反过来,如果三项都正常,提交入口的使用才有意义。
把“能改的”和“不能改的”分开,决策会快很多。以下动作通常不依赖模板文件:
Last-Modified、ETag 等缓存校验头,让爬虫判断内容是否更新。超出这个范围的需求——比如全站统一改 URL 结构、批量替换正文内链——属于模板或路由层改动,不在不改模板的边界内。
假设某遗留站有 5000 个商品页,模板不可改。运营每天向提交入口推送 200 条 URL,连续两周,提交记录正常,但收录数几乎不变。这时有三种成立条件不同的解释:
三种解释对应的动作完全不同:第一种改网关,第二种在数据层或站点地图里做收敛,第三种应先清理 URL 清单再提交。如果只看“提交了没收录”这一个现象,就会把三种原因混成一种。
再补一个假设例子说明动作链条:假设日志显示爬虫对某目录返回 403,你在网关放行该目录。下一步不是立刻看收录,而是先看该目录的抓取请求是否出现、状态码是否变为 200。抓取恢复后,再判断收录变化。这样每一步都有可核对的中间结果,而不是把“放行”和“收录”直接连线。
提交入口适合做两件事:告知新 URL、告知已更新 URL。它不适合当作修复工具。以下做法通常无效或收益很低:
判断提交是否“生效”,应看抓取日志而不是提交回执。提交量、抓取量或收录数归零,都不能单独证明某次处理正确——它也可能是爬虫调度周期、站点整体抓取预算变化、或日志采样缺失造成的。要区分这些解释,至少需要同一时间段内多个目录的对照数据。
面对不可改模板的遗留系统,建议按以下顺序推进,每一步都要求有可核对证据再进入下一步:
如果第 2 步之后抓取仍不出现,而服务器、robots、页面标记均无异常,那么问题很可能已经落到模板或路由层,此时应明确告诉相关方:不改模板就无法继续推进,而不是在提交入口上增加频次。这个边界判断,比任何一次提交动作都更影响后续决策。