动态页面的可见内容不能只看浏览器里“看起来有字”,而要以初始HTML、渲染后DOM和可抓取文本三者交叉确认。对同ip网站查询这类工具页来说,用户输入的IP、查询结果和错误提示往往由JavaScript或后端接口生成,若只保存截图或口头说“能打开”,协作交付时就容易返工。可靠做法是:先确认目标URL返回的原始HTML里有什么,再确认脚本执行后页面实际呈现什么,最后确认这些内容是否以文本形式存在于DOM中,并留下可复核的证据。
动态页面至少存在三种状态。第一种是服务器返回的初始HTML,查看源代码就能看到;第二种是浏览器执行JavaScript、请求接口并更新DOM后的渲染结果,也就是用户肉眼看到的页面;第三种是搜索引擎或抓取工具能够读取到的文本。三者可能完全不同。
确认动态页面可见内容时,要把“用户可见”和“机器可读”分开记录,不能用其中一个替代另一个。
这是最直接、适合多人协作交付的方法。以同ip网站查询结果页为例,假设页面地址是https://example.com/ip?q=203.0.113.10,按以下步骤操作:
document.body.innerText,检查输出中是否包含该结果。innerText更接近用户可见文本,但会受CSS显示状态影响。验收信号是:目标文本同时出现在渲染后DOM和innerText输出中,且对应接口返回成功。若只在截图里出现,不能作为“可见内容已确认”的交付依据。
动态渲染的内容即使人眼可见,也可能因为依赖用户交互、滚动触发或登录状态而无法被稳定读取。检查时关注以下几点:
这里要区分“可能原因”和“已经定位的原因”。页面空白可能是接口失败、脚本报错、跨域限制或渲染条件未满足,不能只看一个现象就断定是某一种。要结合Console报错和Network响应逐项排除。
多人协作时,减少返工的关键不是写“已检查”,而是留下别人能复现的材料。针对同ip网站查询动态页,建议每次交付包含:
?q=203.0.113.10。document.body.innerText的输出片段,只保留结果相关部分。如果目标页面是历史服务或旧功能,不要凭记忆描述“以前在某个位置显示”。应重新打开当前页面,按上述步骤核对现状;无法访问时,只能记录“当前无法复核”,不能把旧界面当作今天仍然可用。
验收动态页面可见内容,优先看可复现的文本证据,而不是页面截图或“我这边能打开”。截图能证明某一时刻的视觉状态,但不能证明文本存在于DOM、接口返回正常或换一个环境仍可见。若使用站点地图、robots.txt或HTTPS作为辅助判断,要记住:站点地图不保证收录,robots.txt的抓取限制不等于可靠的索引移除,HTTPS也不保证页面内容一定被抓取。不同搜索引擎对JavaScript渲染的支持情况不同,需要分别核查,不能用一个引擎的结果推断另一个。
下一步,选一个实际动态结果页,按“源代码—DOM—innerText—接口”四项各记录一次,再把记录交给同事复现。复现结果一致,才算这次可见内容确认完成。