遗留系统改不动模板,并不等于爬虫控制完全无从下手。你仍可以在服务器层、robots.txt、站点地图和响应头这几个外圈位置做调整,但每一项都只能约束“谁可以抓、抓哪里、以什么方式抓”,无法替代页面内的规范化、索引状态修正或内容质量改造。下面用一个假设情境把决策过程串起来,说明哪些动作值得先做,以及做完之后能推出什么、不能推出什么。
假设你接手一套老电商系统,模板由外部供应商锁定,页面里的 meta robots、canonical、分页链接结构都无法改动,但你有服务器配置权限和根目录文件写入权限。这就是典型的“外圈可动、内圈锁死”状态。
外圈可动的通常包括:robots.txt、XML 站点地图、HTTP 响应头、服务器层重定向、访问日志。内圈锁死的通常是:页面标题与描述、canonical 标签、结构化数据、内链结构、正文模板。
关键取舍在于:外圈手段擅长控制抓取行为,不擅长控制索引结果。robots.txt 的抓取限制不等于可靠的索引移除——被屏蔽的 URL 仍可能因外部链接而被收录,只是没有摘要。站点地图也不保证收录,它只是提交候选清单。所以如果你的真实目标是“让某批页面从结果里消失”,只改 robots.txt 往往达不到,需要配合页面级 noindex,而后者恰恰是遗留系统给不了的。这种情况下要如实向决策方说明能力缺口,而不是用抓取限制假装解决了索引问题。
在改任何东西之前,先在服务器层做一件事:按 URL 路径和响应码聚合访问日志,统计每个目录段被请求的次数,并区分状态码 200、301、404、403、5xx 各自占比。
这个动作的结果会直接改变下一步。如果发现大量请求集中在筛选参数页,且返回 200,说明抓取预算被参数组合消耗,此时服务器层对已知无价值参数返回 404 或 410 是合理方向。如果发现 5xx 占比偏高,那么优先级不是限制爬虫,而是先修稳定性——爬虫在 5xx 上重试会放大负载,此时收紧抓取反而可能掩盖真实故障。
需要提醒的是,日志里某类请求量下降或归零,不能单独证明你的处理正确。它还有别的合理解释:爬虫降低了整体抓取频率、你的 CDN 或反向代理改变了日志记录方式、机器人标识被伪装。要交叉核对来源 IP 段、User-Agent 和请求时间分布,才能判断变化来自你的动作还是外部因素。
当模板确实改不了,可以按下面的顺序推进,每一步都对应一个可观察结果:
如果只能做一件事,优先选日志分析,因为它决定了后面三步的方向。跳过日志直接写 robots.txt,很可能屏蔽掉本应被抓取的重要目录,而问题根源其实在别处。
假设你完成了上述动作,两周后观察到目标目录的抓取请求下降、5xx 比例回落。可以合理得出的结论是:抓取压力在服务器层面得到了缓解,稳定性改善可能与此相关。
不能得出的结论包括:相关页面已经退出索引、排名会因此上升、收录量会按预期变化。抓取减少与索引状态变化之间没有必然的因果链,中间还隔着搜索引擎自己的判断。同理,部署 HTTPS 也不能被当作安全或排名的保证,它只解决传输加密这一层问题。
把边界说清楚,比给出一个看似完整的方案更有用。遗留系统的爬虫控制,本质是在有限权限内做取舍:能约束抓取,未必能约束索引;能提交候选,未必能换来收录。明确这条线,后续的每一步调整才有可验证的判断依据,而不是把“改了配置”误当成“问题已解决”。