核对抓取限制,实质是确认搜索引擎的抓取程序在访问你的页面时,是否被服务器、robots规则、页面代码或安全策略挡住。多人协作时,把“谁查、查什么、结果怎么判断”写进同一份清单,能避免一方说已放行、另一方仍看到抓取失败。下面按可执行顺序给出检查项。
要查的是站点根目录下的robots.txt,看其中是否有Disallow指向目标栏目或整站,以及User-agent是否单独针对某类抓取程序。查法是在浏览器打开你的域名/robots.txt,逐行核对路径;多人协作时把文件内容复制进任务记录。结果说明:若目标路径被Disallow,抓取程序通常不会继续请求该路径;若只屏蔽了某类程序,其他程序仍可能访问。
注意区分“规则写了禁止”和“实际已被抓取”。规则是声明,实际是否遵守要看服务器日志和抓取统计。
要查的是目标URL对外的HTTP状态码,以及是否对特定抓取程序返回不同结果。查法是用命令行工具或在线状态检查工具请求该URL,记录状态码、响应头和响应时间。结果说明:
403:服务器拒绝访问,可能来自防火墙、WAF或权限配置,抓取程序会被挡在门外。429:请求过多被限流,通常是抓取频率触发了保护,降低频率或调整抓取预算后再观察。503:服务暂时不可用,可能是维护或过载,抓取程序会暂时放弃。200:正常返回,但仍需确认返回的是目标内容,而不是验证页或空壳页。如果同一URL用不同User-agent请求得到不同状态码,说明限制是按抓取程序区分的,这比全站禁止更容易漏查。
要查的是页面HTML中的<meta name="robots">和HTTP响应头中的X-Robots-Tag。查法是在页面源码中搜索noindex、nofollow、noarchive等值,同时用响应头查看工具确认是否在头部下发了同类指令。结果说明:noindex表示不将页面纳入索引,nofollow表示不追踪页面上的链接。两者都不等于禁止抓取,禁止抓取要靠robots.txt或服务器拦截。
多人协作时容易出现的返工是:开发在响应头加了noindex,编辑只在页面源码里查,没看响应头,于是误判为可收录。把“源码”和“响应头”分成两个检查项,能减少这类漏项。
要查的是服务器访问日志中抓取程序的请求记录,以及搜索平台提供的抓取统计。查法是按时间范围筛选日志,看目标路径是否有来自抓取程序的请求、返回状态码是多少、请求频率是否异常。结果说明:
比较改动前后时,要考虑季节、搜索需求变化和数据采集差异,不能只用一次日志就断定限制已解除或已生效。
把以下内容做成任务表,每项包含“查什么、怎么查、结果说明什么”,交付时逐项打勾:
假设某栏目在robots.txt中被Disallow,同时服务器日志里该栏目请求为403。此时不能只改robots.txt就认为恢复,还要确认防火墙是否也拦了抓取程序。两项都放行后,再观察日志中是否出现200请求。
下一步:选一个目标URL,按上面五项各查一遍,把结果填进同一张表,再决定是改规则、改服务器配置还是继续观察。