seo实战教程：怎样核对抓取限制

📍 WDQWDWQD987AAAAA:216.73.216.145
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /000ed6633242.html
📄

seo实战教程：怎样核对抓取限制

核对抓取限制的核心方法是：先确定限制发生在哪一层，再用“请求—响应—日志”三组证据交叉验证，最后用一次最小化改动做前后对比。抓取限制可能来自robots.txt、页面级meta指令、服务器返回状态码、防火墙或CDN规则，也可能来自站内链接结构过深。不先定位层级就改配置，很容易把“没被抓取”误判成“被抓取但没收录”。

先分清两类限制：规则声明与实际拦截

规则声明是站点主动告诉爬虫“不要抓”或“可以抓”，典型是robots.txt和页面里的<meta name="robots">。实际拦截是服务器或中间层在请求到达时拒绝、超时或返回异常，典型是403、429、503、连接重置、防火墙封禁。两者现象可能都是“页面没被抓”，但处理方案完全不同。

判断依据：如果robots.txt里对应路径是Disallow，属于规则声明；如果robots.txt允许，但服务器日志里同一URL频繁出现403或超时，属于实际拦截。只有日志能证明请求真的到达过服务器，没有日志就不能断言是拦截，也可能是链接没被发现。

方案一：从robots.txt和meta指令核对声明层限制

适用条件：你怀疑页面被主动禁止抓取，或者不确定某条规则是否误伤了目标目录。

  1. 打开站点根目录的robots.txt，逐条看User-agent和Disallow、Allow的匹配关系。注意规则按路径前缀匹配，Disallow: /news会同时挡住/news和/news-2024这类同前缀路径。
  2. 检查目标页面的HTML源码，确认是否存在<meta name="robots" content="noindex">或nofollow。noindex影响的是收录，不等于禁止抓取，这两个概念要分开。
  3. 检查HTTP响应头里是否出现X-Robots-Tag。它对非HTML文件同样有效，容易在只查HTML时被漏掉。

验收信号：修改robots.txt后，用抓取测试工具或直接请求该文件，确认返回的是更新后的内容，而不是缓存版本。meta指令的验收要看页面源代码，不是看渲染后的可见文字。

方案二：从服务器日志和响应码核对拦截层限制

适用条件：robots.txt和meta都允许抓取，但页面长期没有抓取记录，或者抓取量突然下降。

  1. 在访问日志中筛选目标URL和爬虫User-agent，统计状态码分布。403偏多指向权限或防火墙，429指向频率限制，503指向服务端过载或维护。
  2. 对比同一时间段内其他目录的抓取情况。如果只有某个目录异常，问题更可能在目录级规则；如果全站都异常，优先查服务器和CDN。
  3. 用命令行请求目标URL，观察响应头和耗时。示例：curl -I -A "Mozilla/5.0 (compatible; Googlebot/2.1)" https://example.com/page。这里只是演示请求方法，实际User-agent以你所用工具的说明为准。

判断结果：如果带爬虫UA的请求被拒、普通浏览器UA正常，可能是UA识别或反爬规则误伤；如果两种UA都被拒，问题在服务器配置或网络层。

两种方案的比较与选择

一次改动前后比较时，要考虑季节性和搜索需求变化，也要考虑日志采集口径是否一致。抓取量回升不等于收录或排名一定改善，只能说明限制可能被解除。

可执行的核对清单

  1. 确认目标URL在robots.txt中是被允许还是被拒绝。
  2. 确认页面HTML和响应头没有冲突的noindex或X-Robots-Tag。
  3. 在日志中确认该URL是否真的被请求过，以及返回的状态码。
  4. 用最小改动只调整一处限制，保留改动前后各一段时间的日志做对比。
  5. 如果日志中没有该URL的任何请求，先查内链和站点地图，而不是继续改robots.txt。

下一步：选一个当前抓取异常的具体URL，按上面清单逐项记录证据，再决定是改声明层规则还是联系服务器侧排查拦截。

图1 图2
nginx