很多人把注意力放在“投了多少 URL”上，却忽略了另一个更关键的问题：搜索蜘蛛顺着入口页进来之后，能不能在页面上找到下一条链接。投放只是把门打开，页面输出方式才决定蜘蛛能在站内走多远。
入口页之后的路径由页面结构决定
蜘蛛池里的每一个入口页，通常承担两个任务：一是让蜘蛛确认这个 URL 可访问、有内容；二是提供足够明确的下一步。如果页面上只有一段文字和图片，没有任何可跟随的链接，这次抓取大概率就止步于此，后面的深层页面仍然要靠下一轮投放去碰运气。
这里说的“链接”，指的是搜索蜘蛛在解析 HTML 时能直接读到的链接，而不是用户点击后才由脚本生成的东西。
三种常见的页面输出方式
- 静态 HTML：链接直接写在 HTML 里，蜘蛛抓取源码即可获得，维护成本也最低。
- 服务端渲染：页面由后端拼装后输出完整 HTML，蜘蛛拿到的东西和浏览器首次加载看到的接近，链接同样可读。
- 纯前端 JS 渲染：HTML 里只有容器和脚本，链接在脚本执行后才出现。蜘蛛对 JS 的执行程度有限，且往往有等待时间限制，结果是页面看起来正常，链接却不一定被发现。
三种方式没有绝对的好坏，但对“URL 发现”这件事，可读链接越靠前，效率通常越稳定。
链接可见性自查清单
- 链接是否为标准 a 标签，href 指向完整的绝对 URL，而不是依赖点击事件。
- 链接是否被 onclick、data-href 之类的属性取代，真实地址藏在脚本里。
- 是否只在 noscript 段落里放链接——部分抓取并不会执行这一段。
- 是否放在需要点击展开的折叠面板、Tab 或弹窗中。
- 是否使用了相对路径且基准地址不明确，容易拼接出错误 URL。
- 是否所有链接都指向同一个中间跳转页，深层地址一个都没暴露。
懒加载与无限滚动要单独处理
图片懒加载对链接发现影响不大，但链接懒加载影响很大：列表项滚动到视口才插入的链接，蜘蛛通常不会主动滚动。同理，无限滚动的列表如果只加载首屏，后面的内容对蜘蛛等于不存在。
- 给列表加一个不依赖脚本也能访问的分页入口，例如“下一页”链接。
- 把关键的深层链接放一份在首屏 HTML 中，哪怕视觉上隐藏或折叠。
- 用 sitemap 补齐那些确实无法在页面暴露的 URL，作为兜底而不是唯一手段。
渲染方式的取舍
把链接做成“用户点得到”还不够，要让它“源码里读得到”。这两件事在静态页面上往往是同一件事，在前端渲染页面里经常是两回事。
如果站点本身是前端框架搭建，不必为了蜘蛛池把整站重写。更划算的做法通常是：对需要被发现的列表页、聚合页做服务端渲染或预渲染，把链接输出到首屏 HTML；强交互的部分继续保留 JS 渲染。资源有限时，优先保证入口页和列表页的可读性，比追求全站改造成本更低。
几个容易踩的误区
- 认为蜘蛛会像真实浏览器一样完整执行所有脚本、等待所有异步请求。
- 把链接全部写进 JS 数组里动态生成，HTML 源码中一个都看不到。
- 用 JS 跳转代替服务端跳转，蜘蛛可能停在跳转前那一页。
- 页面能正常打开就认为没问题，从未看过页面源码里到底有什么。
上线前的检查步骤
- 用浏览器查看页面源代码，而不是只看开发者工具里的元素面板。
- 在源码中搜索目标深层 URL 的片断，确认它以链接形式存在。
- 关闭 JavaScript 后再打开页面，看还剩多少可跟随的链接。
- 抽查几个链接是否返回正常状态码，避免链接指向死路。
- 记录这次改动，后续观察日志中深层 URL 的出现频率是否变化。
页面输出方式不会直接决定结果，但它决定了蜘蛛每一次到访能被利用到什么程度。把链接放在源码里能读到的地方，是投入产出比较高的一步，剩下的交给时间和持续观察。