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

seo实战密码 - 抓取限制核对：从日志到robots的交付清单

核对抓取限制，关键是确认搜索引擎实际能抓到什么、被什么挡住，而不是只看配置文件。最可靠的做法是：用服务器访问日志或爬虫命中记录，对比robots.txt、页面meta robots、HTTP响应头和内链可达性，找出“声明允许”与“实际抓取”之间的差异，并把结论写成可复核的交付记录。

准备：先固定核对范围与证据来源

多人协作最容易返工的地方，是每个人看的对象不同。开始前先约定三件事：核对哪些目录或模板、以哪份日志为准、由谁负责导出。证据优先级建议如下：

• 服务器访问日志或CDN爬虫命中记录：反映真实抓取行为，优先级最高。
• robots.txt：只声明允许或禁止，不代表一定被抓取。
• 页面级meta robots与X-Robots-Tag：控制单页或整类响应的索引与跟进。
• 内链与站点地图：决定能否被发现，属于可达性问题而非抓取限制本身。

把这几类证据整理成一张表，每行一个URL或模板，列写“日志是否命中”“robots是否放行”“响应头是否禁止”“内链是否可达”。这张表就是后续交付的核心。

实施：逐层核对抓取限制

按从外到内的顺序检查，避免一上来就改配置。

1. 看robots.txt是否对目标爬虫关闭了目录。注意通配符和结尾斜杠的写法差异，例如Disallow: /search与Disallow: /search/覆盖范围不同。
2. 看目标URL返回的HTTP状态码。403、429、503都会让抓取失败，其中429和503可能是临时限流，需要结合日志时间分布判断，而不是直接判定为永久封锁。
3. 看响应头中的X-Robots-Tag和页面内的meta robots。两者同时存在时，限制更严的一方生效。
4. 看内链和站点地图能否到达该URL。拿不到链接的页面，即使没有禁止规则，也可能长期不被抓取。

假设某分类页日志中长期没有命中，同时robots.txt放行、返回200、meta为index,follow，那问题更可能出在内链深度或站点地图未包含，而不是抓取限制。这个判断需要日志与配置同时对照，不能只凭单一现象下结论。

验证：用改动前后对比确认结论

修改任何限制后，不要只看配置文件是否生效，要回到日志验证。比较时注意三点：

• 区分“可能原因”和“已经定位的原因”。日志无命中可能有多种解释，只有排除其他层之后才能写进结论。
• 对比窗口要覆盖相同星期和相近搜索需求，避免把季节性波动当成改动效果。
• 数据采集口径要一致，比如都按同一爬虫UA统计，不要一次用全量日志、一次用抽样。

验证结果可以写成一句话结论加证据编号，例如“模板A在改动后7天内出现命中，证据为日志第X行区间”，方便同事复核。

维护：把核对变成可重复的交付项

抓取限制会随模板迭代、活动页上线、CDN规则调整而变化。建议在每次发版或大促前，固定跑一遍上面的表格，并记录变更人和日期。交付时只提交结论、证据位置和待确认项，不提交整段日志。这样多人协作时，接手的人能直接定位到具体限制，而不是重新排查一遍。

下一步：挑一个当前没有抓取记录的模板，按上面的表格填一遍，标出哪一层是真正的阻断点。