不少站点把导航、列表、分页的链接写在 JavaScript 里，用浏览器打开一切正常，蜘蛛第一轮抓取却看不到。这不一定是蜘蛛“不处理 JS”，而是它需要走一遍渲染流程，要排队、要消耗资源。理解这个差别，能帮我们把关键路径留在初始 HTML 里。
蜘蛛处理一个页面的两轮
第一次请求拿到的是服务器直接返回的 HTML，也就是初始响应。链接、锚文本、canonical、hreflang 这一层信息，通常在初始 HTML 里就能读到。如果链接是脚本插入的，第一轮就没有线索，只能等渲染队列。
渲染队列是有限资源。页面结构越复杂、依赖的脚本越多，等待越久，而且并不是每个被发现的页面都会进入渲染。对新 URL 的发现来说，把希望全部押在渲染上，等于把发现时间交给运气。
哪些写法会让链接“隐身”
- 链接在点击后才生成，初始 HTML 里只有 button 或 div，没有真实 href。
- 列表内容靠接口异步填充，HTML 源码里一个 a 标签都没有。
- 前端路由用事件绑定跳转，地址写在 data 属性里而不是 href 上。
- 分页被“加载更多”替代，翻页地址在初始 HTML 中不可见。
- 脚本报错或接口超时，整段链接一起消失，且不易在日常检查中发现。
给关键路径留一条不渲染也能走的路
- 首页、栏目页、详情页之间的主路径，用标准 a href 输出，锚文本写清楚。
- 分页保留一版可访问的 URL，即使前端另有一套“加载更多”的交互。
- 无限滚动配一个静态的分页入口，让后续内容有可进入的地址。
- 脚本生成链接后，服务端也输出一份同样的链接列表，两者保持一致。
- 用 Sitemap 兜底，但不要拿它替代内链。
Sitemap 与内链的分工
Sitemap 更像一份名单，内链才决定抓取的走向和频次。名单能让蜘蛛知道某个 URL 存在，但如果站内没有任何路径指向它，被反复回访的概率通常有限。两者配合使用：Sitemap 保证覆盖，内链保证可达，缺一环都会让路径变弱。
蜘蛛池推送和渲染的关系
用蜘蛛池推一批 URL，解决的只是“让蜘蛛知道有这些地址”。如果这些地址所在页面的内部链接全部依赖 JS 生成，蜘蛛进来之后还是难以顺着走到下一层。推送入口和站内路径是两件事，前者负责开局，后者决定能走多远。
怎么验证蜘蛛到底看到了什么
- 关闭 JS 抓取页面，查看初始 HTML 里是否包含目标链接，直接看源码比看渲染结果更接近第一轮。
- 对比服务器日志中的请求路径和页面渲染后的链接列表，找出只在渲染后存在的 URL。
- 记录新页面从上线到首次被抓取的时间差，时间明显偏长的栏目值得排查路径。
日志里出现的是蜘蛛实际请求过的 URL。如果某一批 URL 长期不出现，先确认它在初始 HTML 中是否可见，再看服务器是否稳定返回。
不必把所有内容都服务端渲染
低频的、非核心的交互功能可以留给 JS。判断标准其实很简单：这个 URL 是否需要被搜索发现？需要，就让它在不渲染的情况下也能被走到；不需要，就不必为抓取做额外改动。
最后提醒一句，脚本报错、接口超时、资源阻塞这类问题，会让链接在某一刻集体消失。上线前顺手看一眼控制台错误和接口成功率，也是保证抓取路径通畅的一部分。