现在很多站点为了交互，正文、列表、图片都靠脚本在浏览器里渲染。用户看着没问题，但从抓取角度看，服务器返回的原始 HTML 里可能只有一个空壳。蜘蛛进来看到的和用户看到的不是同一份内容，URL 发现和内容理解都会受影响。这篇聊聊怎么自查。
为什么要专门查这件事
抓取程序通常分两步：先拿到服务器返回的 HTML，再决定要不要执行脚本。执行脚本是有成本的，很多抓取方只执行一部分，或者干脆不执行。如果正文、内链、列表都在脚本里，等于把内容发现权交给了别人愿不愿意多跑一步。
先确认页面属于哪种类型
- 服务端渲染：HTML 里就有完整正文和链接，最稳。
- 同构或预渲染：首次返回的 HTML 里有内容，脚本负责后续交互，一般没问题。
- 纯客户端渲染：HTML 是空壳，内容全靠接口拼出来，风险最大。
先把自己站点的页面按这三类分一遍，重点盯第三类。
几个常见的坑
正文等接口返回才出现
页面源码里只有一个挂载节点，正文靠接口拉。这种情况要确认接口返回的内容能不能被单独访问，以及有没有对应的静态或预渲染版本。
“加载更多”和无限滚动
列表第二页之后的内容如果只在点击时用脚本插入，且没有独立 URL，那这些内容基本等于只对用户可见。能给出分页地址的方案，通常比纯滚动更利于发现。
图片用 data-src 占位
懒加载的常见做法是把真实地址写在 data-src 里，src 先放占位图。如果抓取方不执行脚本，就只能看到占位图。要检查首屏图片是否至少有正常的 src。
交互控件替代了链接
有些入口写成了 div 加点击事件，没有 href。用户能点，抓取方找不到地址。能改成带 href 的链接就改，交互用脚本增强即可，但地址本身别藏起来。
自查怎么做
- 浏览器里禁用 JS，重新打开几个典型页面，看有没有正文、有没有可点链接。
- 用命令行工具直接请求页面，只看原始 HTML，对照渲染后的内容差多少。
- 挑首页、栏目页、详情页各两三个逐步查看差异，别只看首页。
- 检查列表页的下一页、加载更多有没有可访问的 URL。
- 检查详情页正文所在容器在原始 HTML 里是否为空。
- 把差异记录下来，标注是“必要渲染”还是“可以预置”。
改造思路
- 核心内容优先服务端输出，交互部分再用脚本增强。
- 列表分页给出可访问地址，滚动加载只作为补充。
- 首屏图片用真实 src，后续图片再做懒加载。
- 关键入口保持可点击的链接，不要只依赖事件。
- 如果架构短期改不了，至少做好预渲染或静态快照。
判断标准很简单：把脚本关掉，页面还剩多少能被读到的内容和入口。剩得越多，站点越稳。
多久查一次
改版、换框架、上线新模板之后必查一遍。平时可以按季度抽查，重点看模板有没有被前端改动带偏。