很多站长排查收录问题时，会把注意力放在内容和外链上，却忽略了一个更靠前的环节：搜索蜘蛛抓到的那个页面，和你用浏览器打开看到的页面，可能并不是同一份东西。以前端渲染为主、组件异步加载的站点，这种差异尤其明显。
为什么会出现两份不一样的页面
浏览器打开页面时，会先拿到一份原始 HTML，然后执行其中的脚本、请求接口、再把内容逐步填进 DOM。用户看到的是执行完成后的结果。搜索蜘蛛也会执行脚本，但这件事成本高、需要排队，很多情况下它先接触到的是那份还没被填满的原始 HTML。
于是同一个 URL 就有了两种形态：原始 HTML 里的内容，和渲染后页面里的内容。收录判断建立在哪一份上，取决于引擎的处理能力、页面重要程度和抓取配额。差异就是从这里开始的。
三种常见做法，收录表现差别很大
客户端渲染的单页应用
原始 HTML 里往往只有一个空容器和几段脚本，标题、正文、内链都要等脚本执行完才出现。这类页面的收录通常最不稳定：可能被抓到，但索引里留下的内容很薄；也可能因为脚本里的链接没有被解析，导致整批 URL 迟迟等不到下一次抓取。
服务端渲染
服务器直接返回带内容的 HTML，用户和蜘蛛拿到的是同一份，对收录最友好。代价是每次访问都要由服务端拼装页面，运维成本相对高一些。
预渲染与静态化
在构建或请求时生成静态 HTML，兼顾响应速度和内容可见性，适合变动不频繁的列表页、详情页。需要注意的是预渲染缓存要能跟着内容更新，否则索引里会长期停在一个旧版本上。
排查时按这个顺序看
- 先看原始 HTML。用查看源码，而不是开发者工具的元素面板，确认标题、核心正文、主要内链是否已经在里面。元素面板展示的是渲染后的结果，容易造成误判。
- 再看渲染后的结果。用搜索平台提供的抓取测试或渲染截图功能，看蜘蛛执行脚本后实际拿到什么。两边都看，才能判断差异有多大。
- 确认内链是否可见。如果列表页的链接由脚本渲染生成，蜘蛛在第一步就可能看不到通往详情的路径，URL 发现会因此变慢。
- 检查元信息。标题、描述、canonical 如果是脚本动态写入的，要确认渲染后能被正确读取，否则收录后呈现的标题可能和你的预期不一致。
几个容易忽略的细节
- 首屏内容异步加载，蜘蛛抓取时接口尚未返回，页面看起来就像被截断了。
- 依赖用户交互才展开的内容，比如点击查看更多，蜘蛛通常不会主动去点。
- 脚本报错会让整页渲染中断，线上偶发的接口故障就可能让一批页面被抓成空壳。
- 同一套模板下个别页面渲染失败，往往只体现在收录数据上，日常访问未必能发现。
处理原则：关键内容不依赖脚本
不必追求所有内容都静态输出，但要让决定收录的那部分信息在不执行脚本的情况下也能读到：页面主题、核心正文的首段、指向下一层的链接、基本的元信息。这些是蜘蛛判断页面价值、决定是否继续爬取的依据。
如果短期内无法改造架构，至少保证三点：主要导航和列表链接是可抓取的普通链接；页面有一个稳定的、与内容相符的标题；内容更新后预渲染或缓存能被触发刷新。做到这几点，收录的波动通常会收敛不少。
抓取与收录是两件事，但它们共用同一份输入。你交到蜘蛛手里的那份 HTML，决定了它有没有东西可收。