百度新闻收录，静态响应与脚本渲染结果不同时怎样定位差异
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f44aca2784a9.html
📄
百度新闻收录，静态响应与脚本渲染结果不同时怎样定位差异
拿到一个新闻页，先用curl取原始HTML，再用浏览器渲染后的DOM对照，如果两者内容不同，先不要判断收录异常。静态响应与脚本渲染结果不一致，本身只是渲染链路的差异信号；要定位它是否影响百度新闻收录，需要把差异归类、确认百度看到的是哪一版，再决定改静态输出还是改渲染方式。
先固定对照对象，别让两次请求条件不同
差异排查最容易出错的地方，是对比的两个版本来自不同条件。静态请求可能不带Cookie、不带UA、不执行JS，浏览器版本则带着登录态、地理位置和缓存。要让对照成立，至少固定URL、UA、请求头和访问时间，并确认两次请求命中的是同一台源站或同一层CDN。
可执行的最小动作是：对同一URL分别保存静态响应的HTML和渲染后的DOM，只比较正文区域。结果会直接影响下一步——如果差异只出现在导航、推荐位或页脚，通常与新闻正文收录无关；如果标题、发布时间、正文段落本身不同，才需要继续追。
把差异分成三类，分别对应不同原因
第一类是内容缺口：静态HTML里正文为空或只有占位，渲染后才出现完整段落。常见原因是正文由前端接口异步填充。第二类是内容替换：静态里有A版本，渲染后变成B版本，多与前端路由、A/B测试或缓存分层有关。第三类是结构差异：文字都在，但标题层级、时间标签、分页链接的形态不同。
这三类的处理方向不同。内容缺口优先检查服务端是否输出了正文；内容替换要确认哪一版是源站真实内容；结构差异则要看百度抓取时依赖的是HTML标签还是渲染后的DOM。把差异归错类，后面的动作会全部跑偏。
用日志和抓取记录确认百度实际看到哪一版
如果手上有服务端日志，先筛出百度蜘蛛对目标URL的请求，记录请求时间、UA、返回状态码和响应体大小。响应体大小与静态版本接近，说明它拿到的是静态HTML；如果明显偏大且时间点与渲染服务调用吻合，才可能拿到渲染结果。没有日志权限时，退一步用页面自身的服务端输出做判断：直接请求源站、绕过CDN，看返回的HTML里有没有正文。
这里要克制结论。抓取量下降或某天日志里目标URL消失，不能单独证明渲染版本被拒绝，也可能是抓取配额调整、URL改版或 robots.txt 临时限制。robots.txt 的抓取限制也不等于可靠的索引移除，它只约束抓取，不负责把已收录结果清掉。站点地图同理，提交了不保证收录。
假设例子：同一篇稿件两个版本的取舍
假设某新闻页静态HTML只输出标题和摘要，正文由接口返回；渲染后正文完整。排查时先确认接口是否对百度蜘蛛开放，再确认服务端能否在首屏直接输出正文。若服务端改造可行，把正文改为服务端输出，静态与渲染结果趋同，后续监测只需看一个版本；若改造受限于发布系统，则要保证渲染服务对百度可访问，并在日志里持续确认返回的是完整正文。
这个例子的数字只用于说明比较方法：比如静态响应体约20KB、渲染后约80KB，差值主要来自正文和评论模块，就应优先定位正文模块，而不是先怀疑整站渲染。
按动作结果决定下一步，而不是一次改完
- 保存静态与渲染两份结果，标记差异区域。
- 绕过CDN直接请求源站，确认源站输出的是哪一版。
- 查日志中百度请求的响应体大小和状态码，判断它拿到哪一版。
- 若源站静态版缺正文，先改服务端输出；若源站正常而CDN返回旧版，先处理缓存。
- 改完后用同一方法复测，确认静态与渲染的正文区域一致，再观察后续抓取记录。
每一步的结果都会缩小范围：源站正常而CDN异常，问题在缓存层；源站和CDN都缺正文，问题在服务端输出；两者都正常但日志里百度拿到的是旧版，才需要继续查抓取链路。缺少完整数据和权限时，至少能完成前两步，但不能据此断定收录一定恢复。
