先做一件不依赖日志和权限的事:把旧模板页面与新模板页面各自另存为完整HTML,用文本比较工具逐行对比。重点看三处——正文是否被拆进额外容器、导航与页脚是否重复、结构化数据是否丢失。这个动作能发现大部分“肉眼看不出来”的差异,但它只能证明两个快照不同,不能直接推出搜索表现会怎么变。
新模板上线后,页面往往由脚本拼接内容。直接对比浏览器里“看到的”HTML,容易把渲染时机差异误判成模板差异。可执行的最小动作是:对同一个URL,在旧站和新站各取一份原始响应源码,再各取一份渲染后的DOM快照,分成两组对比。
如果只能拿到渲染后结果,就明确记录这个前提,不要把它当成服务端输出结论。缺少日志时,这一步仍然可做,因为源码和DOM都在你手里。
发现差异后,先归类再动手,否则容易改错地方。下面这组证据能把常见原因区分开:
<div>层级,且渲染后仍如此——多为模板结构变化。<title>或结构化数据缺失——多为模板变量未传入。假设一个页面在旧模板中正文直接位于主容器,新模板多了一层懒加载占位。若原始响应已包含全文,而渲染后需要滚动才出现,那么差异来自前端行为而非服务端。此时下一步应是检查该脚本的触发条件,而不是改模板的HTML结构。
按影响面从大到小处理,能避免反复返工:
每修一项,重新取一次源码快照并与修复前对比。如果差异消失,说明定位正确;如果没变,说明原因在别处,应回到上一步重新归类,而不是继续叠加修改。
改动前后做对比时,季节、搜索需求波动和采集时间差都会影响观察结果。某段时间抓取量或请求量下降,可能是采集窗口不同、站点整体调整或外部需求变化,不能单独作为“这次模板改动导致”的证据。更稳妥的做法是:固定同一时间段、同一批URL、同一采集方式,只比较结构差异,不急着把结构差异等同于效果差异。
如果缺少完整数据和权限,最小可交付的结论是:哪些页面在源码或DOM层面确实不同、差异属于哪一类、下一步该验证哪个脚本或变量。这个结论足以支撑后续修复,但不足以判断最终搜索表现。