Baiduspider抓取 - 与开发交接问题：先定症状再定责任

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

Baiduspider抓取 - 与开发交接问题：先定症状再定责任

和开发交接 Baiduspider 抓取问题，核心是把“百度没抓”翻译成可复现、可验证、可分工的技术事实。交接前先确认现象属于哪一类：抓取请求根本没到服务器、请求到了但被拒绝、请求成功但内容不符合预期。三类问题的责任人和排查入口不同，混在一起提需求，开发只能反复回复“我这边看是正常的”。

交接前先把现象收窄到一条可验证的记录

不要用“收录不好”“蜘蛛不来”作为交接描述。打开服务器访问日志或 CDN 日志，用 Baiduspider 的 User-Agent 过滤，取最近一段时间的记录，确认三件事：有没有来自 Baiduspider 的请求、请求命中了哪些 URL、返回的状态码是什么。这一步的产物是一张表，字段至少包含时间、URL、状态码、响应大小、User-Agent。没有这张表，交接会退化成猜测。

如果日志里完全没有 Baiduspider 记录，问题在“到达之前”，可能涉及 DNS、防火墙、IP 段拦截、robots.txt 抓取失败，也可能只是该目录从未被提交过。如果日志里有记录但状态码是 403、429、503，问题在“到达之后被挡”，责任更偏服务端策略。如果状态码是 200 但响应体为空或与浏览器看到的不同，问题在渲染或内容返回逻辑。这三种结论对应的开发工作量差别很大，交接时必须先分开。

用 robots.txt 和状态码做第一轮责任划分

robots.txt 的抓取限制不等于可靠的索引移除，它只表达“不希望被抓”，不能替代 noindex 或删除操作。交接时如果开发说“robots 里没拦”，这只排除了一个可能原因，不能证明抓取链路正常。可以实际执行以下检查：

判断规则：robots.txt 返回 200 且未禁止目标路径，只能说明“规则层没挡”；若此时日志仍无 Baiduspider 请求，要继续查网络层和提交层，而不是停在 robots 这一项。若 robots.txt 本身返回 5xx，抓取方可能按不可用处理，需要开发修复服务端返回。

把前端渲染问题写成开发能直接复现的用例

如果日志显示 Baiduspider 已抓取但拿到的是空壳页面，交接重点转向渲染。先区分两种可能：内容由 JavaScript 在客户端生成，或服务端根据 User-Agent 返回了不同内容。不要直接断言“百度不执行 JS”，这会把讨论带偏。更有效的做法是给开发一条命令或一个请求样例，让他们自己看到差异。

例如，假设目标页面是 /product/123，可以这样描述：用 Baiduspider 的 User-Agent 请求该 URL，返回的 HTML 中不包含商品名称和价格文本，而浏览器打开后可见。请确认这些文本是服务端渲染输出，还是由前端接口异步填充。若为异步填充，需要评估是否改为服务端渲染或预渲染。这个例子的判断结果是：服务端返回的 HTML 里有没有目标文本，决定了问题属于渲染链路还是内容接口。

适用条件：页面依赖前端框架、内容由接口返回、或做过 UA 分流。若页面本身就是静态 HTML，且日志中响应体完整，则不必走这条路径，应回到状态码和抓取频率继续查。

按代价排序，决定先改哪一项

交接不是把所有可能原因列给开发，而是给出优先级。可以按修改代价和影响范围排序：

  1. 先修返回 5xx 或 robots.txt 异常，这类问题影响整站抓取，代价通常较低。
  2. 再处理误拦截 Baiduspider 的防火墙或安全规则，需要确认规则来源和放行范围。
  3. 然后处理渲染差异，若涉及架构调整，代价高，需要单独评估排期。
  4. 最后才是抓取频率低、提交后未抓取等需要观察的问题，这类不宜作为紧急缺陷。

判断结果：如果第一项检查就发现 robots.txt 返回 500，那么后续渲染讨论可以暂时搁置，先恢复规则文件可访问。反之，如果状态码全部正常、响应体完整，只是抓取次数少，就不应要求开发改架构，而应转向提交和观察。

交接时留下可复查的验证条件

每次交接结束前，约定一个可复查的条件，而不是“优化一下抓取”。例如：修复后，用相同 User-Agent 请求目标 URL，返回 HTML 中包含指定文本；或 robots.txt 返回 200 且不再包含整站禁止规则。把验证条件写进任务描述，开发完成后由提出方按同一方法复测。这样下一轮沟通有共同基准，也能避免把未修复的问题重复提交。

下一步：从访问日志中导出最近一段时间的 Baiduspider 请求记录，按状态码分组，挑出数量最多的一类，用上面的检查项写成一条带复现命令和验证条件的交接说明。

图1 图2
nginx