不少站点上线后发现一个现象：页面在浏览器里打开完全正常，站长工具里也显示被访问过，但索引里要么没有这个地址，要么索引到的版本几乎是空的。原因往往不在内容本身，而在于内容出现的方式——正文是脚本执行之后才被插入到页面里的。
要判断问题出在哪一步，需要先把抓取、渲染、索引这三件事分开看。抓取是拿到响应内容，索引是把页面内容理解和入库，而在这两者之间，还有一个常常被忽略的环节：渲染。
抓取到的 HTML，不一定是用户看到的页面
当爬虫请求一个地址时，服务器返回的是一段 HTML 源码。如果正文由前端请求接口后再插入，这段源码里就没有正文，只有框架、容器和脚本引用。爬虫需要额外执行页面上的脚本、构建出完整的 DOM，才能看到那些文字。
问题在于，渲染是要消耗资源的，不保证每个被抓取的地址都会被渲染。通常被优先渲染的是抓取频率较高、外链和内链较多、站点里相对重要的页面。边缘页面、参数页、很少被链接到的地址，可能在渲染队列里排得很靠后，甚至一直没有得到渲染机会。
哪些写法容易让正文在抓取阶段消失
- 正文全部由前端接口返回后动态插入，服务端只输出一个空容器。
- 内容依赖交互才出现，比如点击标签页、展开折叠区、滚动到某个位置才加载。
- 关键文字写在图片、canvas 或背景图里，源码中没有对应的可读文本。
- 站内链接使用脚本跳转而不是 a 标签加 href，爬虫无法顺着链接发现新地址。
- 页面在无脚本环境下直接报错中断，后续内容完全不再输出。
这些写法对用户体验可能没有明显影响，但对以源码为起点、以渲染为补充的抓取流程来说，就等于把内容藏在了第二层。
几个成本很低的自检动作
- 查看搜索引擎实际抓取到的源码。站长工具里的网址检查一般能看到抓取版本，把返回内容复制下来，搜索正文开头的几个字，看是否存在于源码中。
- 在浏览器里禁用 JavaScript 后打开页面，看看还剩下多少可读文字。如果只剩导航和一句提示，说明正文完全依赖脚本。
- 用命令行工具或在线抓取工具直接请求地址，确认服务器返回的 HTML 里的内容量，排除浏览器缓存带来的错觉。
- 对比渲染快照和原始源码，确认两者内容是否一致、正文是否都完整。
- 顺带检查内链部分：如果分页、下一篇、相关推荐都是脚本生成的，那么新页面被发现的速度也会受影响。
做完这几步，基本能判断出页面属于哪种情况：源码里已有主体内容、只有部分内容依赖脚本，还是几乎完全空壳。
如果确实要改造，优先保住哪部分
- 让标题、正文主体、主要栏目链接和关键列表由服务端直接输出，脚本负责的部分留给次要模块，比如评论、推荐、实时数据。
- 采用预渲染或动态渲染时，要保证返回给爬虫的版本和用户看到的版本内容一致，避免出现两套差异很大的页面。
- 无脚本降级内容不要只留一句提示，至少给出正文摘要、主要链接和必要说明。
- 不要为了省事把所有地址都强行返回同一份渲染结果，那会引入新的重复内容问题。
改造范围不必一次铺开，可以先从转化价值高、外链多的页面做起，观察一段时间后再决定是否扩展到全站。
链接和地图仍然决定页面的被发现速度
渲染解决的是内容看得见的问题，URL 能不能被发现是另一件事。脚本生成的链接、只在弹窗里出现的入口，都可能让页面迟迟进不了抓取队列。站点地图能帮助地址被发现，但被发现和被抓取、被收录依然是不同的阶段，不能互相替代。
判断页面为什么没有被收录时，先确认爬虫拿到的源码里有没有内容，再谈其他因素。很多所谓的内容质量问题，其实只是渲染问题。
观察节奏与常见误区
改造上线后不要每天反复调整同一批页面。先记录改动时间，再看抓取日志中爬虫访问的频率和返回状态，然后过几周再对照索引状态和索引版本内容。改动生效需要时间，频繁推翻前面的调整只会让信号变得混乱。
另一个常见误区是把渲染问题和内容质量问题混为一谈。如果源码里本来就有完整正文、只是展示方式不同，那么收录不理想的原因大概率不在这里，需要回到页面质量、重复程度、内链结构上继续排查。分清问题属于哪一层，才能少走弯路。