排查内容加载差异,最直接的办法是分别用“禁JS抓取”和“渲染后抓取”各取一次页面,对比同一段正文是否都能拿到。如果禁JS时缺失、渲染后出现,问题在客户端渲染;如果两者都缺,问题在服务端输出、缓存或抓取路径。下面用一个假设例子把步骤拆开。
假设你负责一个商品列表页,用户反馈“页面内容有时少一截”,你在浏览器里看是完整的。此时不要先改代码,先固定变量:同一URL、同一User-Agent、同一地区出口、同一时间窗口,各抓两次。
把A、B两个文件里的正文段落、价格、库存状态、分页链接逐项对照。判断规则很简单:A缺B有,说明内容依赖脚本注入;A和B都缺,说明服务端没输出或抓取被拦;只有某条线路缺,优先怀疑CDN缓存、地区分流或WAF。
内容加载差异通常来自四层,排查顺序应从最靠近源站的一层开始,避免一上来就怀疑搜索引擎。
每一层都要记录“现象—证据—结论”,不要把“可能原因”写成“已经定位的原因”。例如“可能是接口超时”和“日志显示接口在14:03返回504”是两回事。
先处理影响面最大、验证成本最低的项。可按下面的检查项排序:
如果只有一两个模板页异常,优先修模板;如果全站正文都依赖JS,才考虑服务端渲染或预渲染这类成本更高的方案。改动前后比较时,要避开大促、季节需求波动和统计口径变化,否则容易把流量自然起伏误判成改动效果。
最常见的错误是只测首页、只测已登录状态、只看浏览器开发者工具里的Elements面板。Elements显示的是渲染后的DOM,不能代表抓取端拿到的原始响应。另一个错误是把“页面能打开”等同于“内容可被抓取”,状态码200并不保证正文存在。
判断结果可以这样归类:禁JS与渲染后都完整,说明内容加载没有障碍;禁JS缺失而渲染后完整,说明存在渲染依赖,需要评估抓取端是否执行JS;两者都缺失但浏览器正常,说明差异出在请求头、Cookie、地区或缓存;多次请求结果不一致,说明问题在缓存或接口稳定性,而不是页面结构。
下一步,挑一个你怀疑的模板页,按上面的A/B文件法抓两次并逐项对照,把差异落到具体那一层,再决定改模板、改缓存还是改渲染方式。