核对抓取限制,核心是确认搜索引擎实际能抓到的URL数量、抓取频次和受阻原因,而不是只看robots.txt写了什么。起点是:先找出被限制的URL范围,再判断限制来自站点配置、服务器响应还是外部规则,最后用日志或抓取工具验证。下面从一个假设例子展开。
假设某站点有10万个产品页,近期发现搜索引擎每天只抓取几百个,而之前是几千个。此时不要直接改robots.txt,应先核对三类限制:
常见错误是只检查robots.txt就下结论。实际上,robots.txt允许抓取,不代表服务器愿意响应;服务器响应正常,也不代表页面没有被noindex或canonical指向其他URL。
从服务器日志中筛选搜索引擎爬虫的User-Agent,统计每个目录或参数模式的请求次数和响应码。重点看:
200:正常抓取;403或429:可能被防火墙或限流拦截;5xx:服务器错误,爬虫可能降低抓取频次;301或302:跳转链过长会消耗抓取预算。如果日志中某类URL几乎没有请求,而robots.txt并未屏蔽,优先检查服务器是否对该类请求返回了非200状态码。
robots.txt只控制抓取,不控制索引。核对时逐条检查:
Disallow是否误屏蔽了CSS、JS或分页参数;Allow覆盖了必要的目录;noindex或nofollow;判断结果:如果robots.txt屏蔽了某目录,日志中该目录请求应为零;如果日志中仍有请求,说明屏蔽未生效或爬虫忽略了规则。如果页面有noindex,抓取可能正常,但索引会受限,这属于索引限制而非抓取限制。
服务器层面常见限制包括:
核对方法:用curl -I模拟搜索引擎User-Agent请求一个已知URL,观察返回状态码和响应时间。如果返回429或403,说明服务器主动拒绝了请求。此时需要调整限流规则,而不是继续修改robots.txt。
一次改动前后比较要考虑季节、搜索需求变化和数据采集差异。例如,假设你在某月调整了分页参数,抓取量从每天5000降到3000,不能直接归因于改动。应同时对比:
判断结果:如果只有分页URL抓取量下降,而其他目录正常,问题可能出在分页规则;如果全站抓取量下降,优先检查服务器限流或robots.txt全局规则。
从日志中导出最近7天搜索引擎爬虫的请求记录,按响应码和URL目录分组统计。找出请求量为零但未被robots.txt屏蔽的目录,逐一用curl模拟爬虫请求,确认服务器返回状态。根据结果决定是调整robots.txt、放宽限流还是修复页面指令。