现在用前端框架搭站很常见。页面在浏览器里看着完整，正文、图片、评论区都在，但打开“查看网页源代码”，可能只剩一个空的挂载节点和几个脚本文件。对用户来说没差别，对搜索蜘蛛来说，这是一次几乎没有内容的访问。渲染方式不是纯技术细节，它决定了蜘蛛能不能读到你的正文，也决定了它能不能顺着页面里的链接继续发现更多 URL。
先分清：蜘蛛拿到的是哪一版 HTML
判断方法不复杂，把同一篇文章用两种方式各看一次：
- 查看网页源代码：拿到的是服务器最初返回的 HTML，接近蜘蛛第一次抓到时看到的东西。
- 检查元素（开发者工具）：看到的是脚本执行之后的 DOM，是你和用户最终看到的样子。
如果源代码里能读到标题、正文主体和主要链接，说明页面偏服务端渲染或静态直出，后续解析一般不会有太大障碍。如果源代码里只有脚本、样式和一片空白容器，正文要等浏览器跑完脚本才出现，那就属于客户端渲染，需要重点确认。
还要留意一点：不同搜索引擎对脚本的处理能力并不相同，执行时机、等待时长、脚本请求是否被放行，都会影响结果。把关键内容完全交给脚本，等于把不确定性留给了自己。
三类最容易出问题的场景
正文全部由接口返回后注入
文章详情、商品描述这类主体内容如果靠接口拉取再渲染，蜘蛛在没有执行脚本时拿到的就是一个空壳。标题可能还写在静态部分，正文却是空的，页面很难被判断为有实质内容。更麻烦的是，摘要、描述、结构化数据往往一并缺失。
链接是点击事件，不是常规 a 标签
用事件绑定或前端路由代替常规的 a 标签，用户点击没问题，但页面源码里没有可识别的新地址。蜘蛛顺着链接爬行的路径就断了，很多本该被发现的页面只能等 Sitemap 或外链来救。URL 发现效率一下降，新内容的收录节奏自然变慢。
懒加载没有兜底
图片和长列表用懒加载本身没问题，问题在于把标题、价格、关键段落也放进“滚动才加载”的逻辑里。蜘蛛不滚动页面，这部分内容就等于不存在。图片可以延迟加载来优化速度，正文和链接不行。
一份可以照着走的自查清单
- 随机挑 5 到 10 个不同类型的页面（首页、栏目页、详情页、列表分页），逐一对比源代码与 DOM 的差异。
- 在浏览器禁用脚本后重新打开页面，看还剩多少内容，剩下的部分就是最稳妥的底线。
- 检查详情页正文是否出现在源码中，标题、描述、结构化数据是否同样可见。
- 检查导航和列表页的链接是否为真实可点击的地址，而不是事件绑定。
- 用抓取工具或站长平台的抓取测试，看返回内容与浏览器看到的是否一致。
- 核对 robots.txt 是否误拦了脚本、样式等渲染必需的资源文件。
其中第 2 条和第 6 条最容易被忽略。禁用脚本后的页面虽然难看，但它能直接告诉你：哪些内容是“必须有脚本才能存在”的。
处理思路：让核心内容先出现在源码里
不一定要把整站推倒重做，可以按投入从低到高排一下：
- 服务端渲染或静态直出：详情页、栏目页这类内容型页面优先改造，正文随 HTML 一起返回，后续的交互再交给前端。
- 预渲染：对更新频率不高的页面，构建时生成一份 HTML 快照，成本相对可控。
- 关键内容降级：暂时无法改造的页面，至少保证标题、正文首段、主要链接写在静态部分。
- 补齐常规链接：导航、面包屑、相关推荐改用真实地址，保证爬行路径不断。
改造之后别只看首页。挑几个深层页面重新做一次源代码对比，确认正文和链接确实出现在最初的 HTML 里，再观察日志中蜘蛛的抓取情况有没有变化。
渲染方式的调整往往不会立刻带来可见变化，它更像是把一条原本时通时断的路修平。路修好了，蜘蛛愿不愿意多走，还取决于内容本身。
最后提醒一句：渲染只是内容能不能被读到的前提，不是全部。正文是否有价值、页面之间是否形成了合理的结构，仍然决定了这些被看到的 URL 能走多远。把渲染问题解决掉，相当于把门槛降下来了，剩下的还是要回到内容和栏目本身。