核对抓取限制,不能只看robots.txt。常见误解是“robots.txt里没写Disallow,页面就一定能被抓取”。实际上,抓取限制可能同时来自robots.txt、页面meta robots、X-Robots-Tag响应头、登录或防火墙拦截、服务器返回状态码等多个层面。正确做法是:先确认目标URL,再逐层检查这些位置,最后用抓取工具或日志验证实际结果。任何一层拦截生效,都可能导致搜索引擎无法抓取或无法索引。
这两个概念经常被混在一起,但处理方式完全不同。
Disallow,或服务器直接拒绝请求。<meta name="robots" content="noindex">或HTTP响应头X-Robots-Tag: noindex。如果robots.txt禁止抓取,爬虫就不会读取页面里的noindex。结果是页面既不被抓取,也无法通过页面标签被移除索引。这是核对抓取限制时最容易踩的坑。
按下面顺序检查,可以避免漏项。每一步都针对同一个测试URL,不要中途换地址。
https://你的域名/robots.txt,找到对应User-agent分组,看目标路径是否被Disallow。注意通配符和结尾符号,例如Disallow: /private/会拦住该目录下所有内容。<head>部分,确认是否有noindex或nofollow。如果页面由模板生成,要检查模板而不是单个页面。curl -I或浏览器开发者工具的Network面板,查看是否返回X-Robots-Tag。它可能由服务器、CDN或应用框架统一添加。403、401、503或跳转到登录页,都说明抓取被拦截。连续跳转也可能让爬虫放弃。发现抓取限制后,常见选择是“直接放开”和“保留限制但改用noindex”。两者适用条件不同。
Disallow规则,同时确认没有noindex标签。放开后需要观察日志中爬虫是否重新访问,但不要期望立即恢复,抓取频率受网站权重和需求影响。noindex。这样爬虫能读到noindex,才有可能将已有索引移除。判断依据是:页面是否需要出现在搜索结果里。需要,就放开抓取并移除noindex;不需要,就允许抓取但保留noindex。不要用robots.txt来阻止索引,因为它阻止的是抓取,不是索引。
假设要核对https://example.com/landing是否被限制抓取。
https://example.com/robots.txt,搜索landing或/,确认没有匹配的Disallow。curl -I https://example.com/landing,查看返回状态码和响应头。如果看到X-Robots-Tag: noindex,说明抓取可能正常,但索引被限制。meta name="robots",确认content值。这个例子中,robots.txt和meta标签是页面级限制,响应头和服务器规则是传输层限制。核对时要分别对待,不能因为robots.txt干净就断定没有抓取限制。
一次改动前后比较时,要考虑搜索需求变化、数据采集差异和缓存。比如放开robots.txt后,爬虫不会立刻按你期望的频率访问;日志中爬虫减少也可能是因为整体抓取预算调整,而不是你的规则生效。判断结果时,应结合多个时间点的日志和抓取工具报告,而不是只看某一天的数值。
下一步:选一个你怀疑被限制的URL,按上面的检查顺序逐项记录结果,再把“抓取限制”和“索引限制”分开标注。这样你才能确定该改robots.txt、该改页面标签,还是该查服务器配置。