不少站点在浏览器里看着一切正常，标题、正文、相关推荐、分页都在。但如果把 JavaScript 关掉再打开页面，或者直接查看初始 HTML 源码，可能会发现该有的内容几乎都不在。搜索引擎蜘蛛拿到的第一版 HTML，和你屏幕上看到的可能完全是两回事。这不是“蜘蛛笨”，而是渲染方式决定的。
先分清两种情况
搜索蜘蛛通常分两步走：先抓取初始 HTML，再排队做渲染。如果内容本来就写在 HTML 里，第一次抓取就能读到；如果内容由 JavaScript 生成，就要等渲染队列。渲染有延迟，也有失败的可能，而且不是所有内容都值得进入渲染队列。所以真正的问题不是“蜘蛛能不能渲染”，而是“你愿不愿意赌它一定渲染”。
做一次“源码视角”自查
不用复杂工具，按下面几步就能有初步判断：
- 在浏览器里打开目标页面，右键查看网页源代码，搜索正文里的几句话，看能不能找到。
- 在浏览器设置或开发者工具里禁用 JavaScript，刷新页面，看还剩多少可读内容。
- 查看主要内链（导航、栏目页、文章页链接）是否出现在初始 HTML 中，还是点击后才由脚本插入。
- 检查分页、加载更多、Tab 切换、折叠面板里的内容，是否需要交互才会出现。
- 用抓取工具的“以 Googlebot 身份抓取并渲染”功能，对比原始 HTML 和渲染后 HTML 的差异。
如果发现正文、内链、分页中有一项以上只存在于渲染后的版本里，就值得安排处理了。
常见的几种“藏内容”方式
- 纯前端路由。整站由 JavaScript 接管跳转，链接地址是前端拼出来的，蜘蛛顺着链接走时容易断。
- 点击后才加载。正文只显示两三行摘要，更多内容靠“展开”按钮触发请求。
- 懒加载过度使用。图片、列表、甚至段落都在滚动到可视区域后才插入页面结构。
- 骨架屏与占位符。首屏先渲染灰条，真实内容后到，抓取时可能只看到空框。
- 内链由脚本写死。相关文章、推荐位、面包屑都靠脚本生成，初始 HTML 里没有可抓的链接。
能落地的处理思路
1. 关键内容优先走服务端
正文、标题、主要导航、内链这些确定性内容，尽量在服务端渲染或静态生成时就输出到 HTML。框架本身支持服务端渲染或静态生成的，别为了省事全部退回客户端渲染。
2. 预渲染作为过渡
老站点一时改不动架构，可以对重要栏目做预渲染，把常见页面的渲染结果以静态 HTML 返回。注意维护预渲染的更新频率，否则用户和蜘蛛看到的是过期版本。
3. 保证初始 HTML 里有可抓的链接
导航、栏目页、分页、上下篇这些结构性链接，尽量用真实的 a 标签写在 HTML 里。用点击事件加脚本跳转的写法，对用户没差别，对蜘蛛差别很大。
4. 让懒加载留有余地
首屏和靠前的内容不要懒加载；图片懒加载时保留尺寸属性，避免布局抖动；正文文字不要用懒加载，它通常不是性能瓶颈。
用日志验证结果
改完之后别只看感觉。看服务器日志里蜘蛛对目标 URL 的请求次数、返回状态码和请求时间，对比修改前后页面 HTML 的体积变化。如果日志显示蜘蛛反复抓取同一个地址却拿不到正文，或者抓取深度明显变浅，说明问题还在。也可以定期在抓取工具里重新检查一次渲染差异。
需要提醒的是，渲染友好并不等于一定被收录。它只是把“内容能不能被读到”这件事做扎实，剩下的仍然取决于内容本身和整体站点质量。
JavaScript 渲染自查不用一次全站铺开，从流量最大、更新最勤的几个栏目开始，把正文、内链、分页三件事确认清楚，再逐步扩展到全站，通常比推倒重来更实际。