聊抓取路径时，大多数人从 robots.txt 和内链结构看起。但蜘蛛要走到那一步，前提是它的请求能先落到你的服务器上。如果 CDN、WAF 或主机层面的防护先把请求挡掉，后面的 Sitemap、内链、抓取预算都无从谈起。这类问题排查起来比较隐蔽：站点对普通访客完全正常，只有蜘蛛的请求被拒。
拦截通常发生在哪一层
- CDN 的 Bot 管理或安全规则，默认对疑似自动化流量做挑战、限速或直接返回 403。
- WAF 把高频访问、特定 User-Agent、缺少 Cookie 的请求判定为攻击。
- 主机面板的防 CC 功能，或机房层的 IP 黑名单，把云服务器 IP 段整段拦下。
- 地区限制、UA 白名单设置过窄，只放行浏览器常用的几个标识。
这些规则的共同点是：它们按请求特征做判断，而不是按内容。对真实用户没影响，对蜘蛛却可能是致命的。
被拦之后，日志里会留下什么
如果你的站有独立日志，先看服务器收到的请求里，还认不认得出蜘蛛的 UA。常见有三种情况：
- 日志里完全没有蜘蛛请求。说明请求在更前面的节点就被处理掉了，源站日志看不到，需要去 CDN 或 WAF 的控制台看拦截记录。
- 有请求，但状态码集中在 403、429、503，或者返回一个验证页。这属于防护层放行到了源站，但源站或 CDN 仍给了拒绝响应。
- 有请求且状态码正常，但内容被替换过，比如返回了 JS 挑战页。这时蜘蛛拿到的是一个空壳，等于路径走到了却读不到东西。
怎么确认是拦截而不是内容问题
最省事的办法是做一次对照测试：用普通浏览器访问目标 URL，再用带蜘蛛 UA 的请求工具访问同一地址，比对状态码和返回内容。如果两者差异明显，问题基本就在防护层。
另外可以对照几件事：搜索引擎站长后台的抓取测试工具报什么错、抓取统计里目标页有没有被成功抓过、同一时间普通用户的访问是否正常。如果只有带蜘蛛标识的请求异常，方向就比较明确了。
放行的正确姿势
不建议只按 User-Agent 放行。UA 可以随意伪造，按 UA 开口子等于给出一个公开的绕过通道。更稳妥的做法是叠加验证：
- 先确认请求来源的 IP 是否属于搜索引擎官方公布的地址段。
- 对关键 UA 做反向 DNS 解析，验证域名归属，而不是只看字符串。
- 在 CDN 或 WAF 里为已验证来源单独建一条放行策略，优先级高于通用 Bot 规则。
- 如果必须限速，给已验证来源一个明显更高的阈值，避免它和普通爬虫共享配额。
顺序上，先放行官方来源，再收紧通用规则。反过来做，很容易在收紧时顺手把蜘蛛也拦了。
放行之后要复查的三件事
- 抓取是否恢复：连续观察几天的日志，看蜘蛛请求数和覆盖的 URL 是否在回升，而不是只看某一天。
- 响应是否稳定：放行后如果源站扛不住，蜘蛛仍然会因为超时减少访问，等于换了一种方式中断路径。
- 是否留下假信号：确认没有把拦截页返回成 200，也没有在验证页里塞入误导性的规范链接。
抓取路径的第一关不在站点内部，而在网络边界。入口被挡住时，任何关于内链和 Sitemap 的优化都不会产生效果，所以排查顺序上，先确认蜘蛛进得来，再谈它走得顺不顺。