用前端框架搭站点已经不稀奇，但从抓取角度看，它带来一个容易被忽略的变化：蜘蛛第一次请求某个 URL 时，拿到的 HTML 往往只有骨架，标题、正文、列表和内链都还没出现。
抓取和渲染是两步，不是一步
搜索引擎处理一个 URL 时，通常会先取回服务器直接返回的 HTML，这一步决定了它能不能立刻看到链接和内容。对于依赖 JavaScript 生成的页面，可能还要进入渲染队列，等浏览器环境把页面执行一遍，才能看到完整结果。
渲染不是免费的。它占用更长的处理时间，也有排队和次数上的限制。原始 HTML 里就有内容的页面，通常能更快完成解析，链接也能更早进入待抓队列。
内链藏在脚本里，URL 发现会慢一拍
问题不在于 JavaScript 本身，而在于关键路径是否只存在于 JavaScript 里。常见的几种写法值得检查：
- 导航和页脚链接由脚本注入，服务器返回的 HTML 里没有任何 a 标签。
- 列表项用 div 加点击事件跳转，没有可跟随的链接地址。
- 分页做成按钮形式，只有状态变化，没有指向下一页的地址。
- 正文和目录链接通过接口异步加载，要等请求返回才出现。
这些做法在浏览器里体验正常，但对第一次抓取来说，页面在 HTML 层面是偏薄的。蜘蛛如果只看这份 HTML，能走的路就只剩下少数几条。
把关键路径留在原始 HTML 里
不需要把所有内容都做成服务端渲染，但入口和路径类链接最好留在 HTML 中：
- 主导航、面包屑、页脚分类，直接在 HTML 里输出链接。
- 列表页的分页，第一页就带上下一页的真实地址。
- 正文里的相关阅读、上一篇下一篇，用链接而不是脚本跳转。
- 栏目页至少输出一批静态可见的条目，不要全靠滚动加载。
如果站点已经用了前端框架，可以考虑服务端渲染、静态生成或预渲染，让首屏 HTML 自带内容与链接。渲染层再复杂，第一份 HTML 最好也能独立说明这是什么页面、接下来能去哪。
渲染本身也要花时间，别让路径串行太深
即便走渲染，页面的加载顺序也会影响抓取体验。一次渲染里若需要连续请求多个接口，每一层都可能超时或失败，最终渲染出的页面链接不全。把关键数据合并、减少串行请求、控制首屏脚本体积，都是在给抓取让路。
另外，渲染出来的链接地址要与 HTML 中的地址保持一致。如果脚本生成的 URL 带一堆参数，或与站内实际路径不一致，容易出现同一内容被拆成多个地址的情况，反而增加后续收敛的成本。
一份可以照着走的检查清单
- 关掉 JavaScript，打开页面，看还剩哪些内容和链接。
- 用抓取工具模拟蜘蛛，对比原始 HTML 与渲染后的差异。
- 确认分页、面包屑、栏目列表在第一份 HTML 里可见。
- 检查是否有只靠点击事件跳转的入口。
- 把重要的 URL 同时写进 Sitemap，给发现留一条备用通道。
前端渲染影响的不只是内容展示，更是链接能不能被看到。链接看不到，URL 发现和后续抓取都会跟着变慢。
抓取和渲染的分工不会因为技术栈改变，但站点可以决定把什么放进第一份 HTML。导航、分页、列表、正文入口这些路径信息越早出现，蜘蛛在站内走起来就越顺，也越不容易在空壳页面上停下。