用前端框架搭站点的人越来越多，用户端体验确实顺滑，但蜘蛛来访时看到的页面，可能和你屏幕上那一版完全不是同一个东西。这个差异不会报错，也不会有任何提示，只会悄悄体现在抓取和索引的结果里。
同一页面，为什么会有两个版本
浏览器打开页面后，会执行 JavaScript，再把接口返回的数据拼进 DOM，于是你看到了完整的正文、列表和推荐位。而抓取程序第一步拿到的是服务器返回的原始 HTML。是否继续执行 JS、执行到什么程度、给多少超时时间，各家搜索引擎的策略不同，也受自身资源限制。
结果就是同一个 URL 存在两份内容：源码版本和渲染版本。如果正文、内链只存在于渲染版本里，蜘蛛能不能发现它们，就变成了一个概率问题，而不是一个确定的事。
三个自查动作，十分钟能做完
一、直接看网页源代码
在页面上右键选择「查看网页源代码」，注意不是「检查」或「审查元素」。在源码里搜索正文中的几个关键词，比如某个小标题、某段独有的话。如果搜不到，说明这段内容不在初始 HTML 里。
二、关掉 JavaScript 再看一次
浏览器设置里禁用 JavaScript，或者换一个纯文本浏览器请求同一个地址。屏幕上剩下的东西，大致就是最保守情况下蜘蛛能拿到的那部分。如果此时页面只剩导航和页脚，正文区一片空白，问题就已经很明确了。
三、用官方工具看渲染结果
搜索资源平台一般都会提供网址检查类的功能，能看到抓取到的 HTML 以及渲染后的对比。命令行里用 curl 请求一次也可以，注意带上常见的 UA，观察返回的 HTML 体积和内容。这些结果比猜测可靠得多。
常见的「内容藏起来」写法
- 正文靠接口异步加载，HTML 里只有一个空的挂载节点
- 列表页用无限滚动，新内容由滚动事件触发，没有可点击的分页链接
- Tab 切换类栏目的内容写在前端数组里，初始 HTML 中一条都没有
- 主导航、面包屑、相关推荐由 JS 动态生成，源码里看不到链接
- 图片用 data-src 存放真实地址，src 留空或是占位小图
- 正文默认折叠，需要点击「展开全文」才发起请求
这些写法各有各的合理性，问题不在技术本身，而在于没有区分「给用户看」和「给蜘蛛看」这两条路径。
按优先级处理，别一次全改
- 先保正文。正文是页面的核心，用服务端渲染、静态生成或预渲染把主体内容放进初始 HTML，收益最直接。
- 再保链接。导航、分页、内链至少有一部分要写成真实的 a 标签，让蜘蛛顺着链接能走到下一层。
- 然后是元信息。标题、描述、canonical 这类标签尽量在服务端输出，别依赖前端插入。
- 最后是图片和媒体。原生 loading 属性可以在保留 src 的前提下延迟加载，比清空 src 更稳妥。
如果整站改造周期长，可以先从栏目页和内容页这两类关键页面动手，其余页面保持观察。
服务端渲染和预渲染都不是一次性的工程。改版、换接口、调整打包配置之后，源码版本都可能回退，建议在发布前的检查清单里保留「查看源代码」这一条。
把这件事变成习惯
内容发布流程里加一步：打开新页面的源代码，确认正文、标题、主要内链都在里面。同时留意服务器日志中蜘蛛的访问情况，看它抓到的地址和抓取频次有没有异常变化。发现问题时，改动往往只是几行渲染配置，但对抓取效率的影响是长期的。