不少站点把导航、列表和分页交给前端 JavaScript 生成，浏览器里看起来一切正常，但在抓取侧，这些入口可能根本没出现在初始 HTML 里。抓取器最先拿到的是未执行脚本的那份文档，其中包含的链接集合，才是 URL 发现的主要来源。所以核对抓取路径时，第一步不是看收录数量，而是看首屏 HTML 里究竟有哪些可跟随的链接。
三种渲染方式下，链接的可见性并不相同
- 静态或服务端渲染：链接随 HTML 一起返回，抓取器不执行脚本也能发现，最稳定。
- 同构渲染：首屏通常带链接，后续交互由脚本接管，重点要确认首屏输出的是完整列表，而不是一个空容器。
- 纯客户端渲染：HTML 里往往只有一个根节点和一段脚本，链接要等脚本执行完才出现。抓取器可能执行，也可能不执行或中途超时，入口就在这里丢掉。
四类容易被忽略的入口
- 按钮式跳转：用 onclick 或前端路由替代 a 标签，人点得到，抓取器跟不了。
- 加载更多：只有点击才请求下一页数据，第一页之后的 URL 没有可跟随的链接。
- 懒加载列表：滚动到可视区域才插入 DOM，不滚动就不存在链接。
- hash 路由：类似 /list#/detail/123 的地址，hash 部分通常不作为独立 URL 参与发现。
核对顺序：先看拿到的，再看发出的
第一步，用抓取测试工具或本地请求拉取页面，只看原始响应体，把其中的链接导出成一份列表；第二步，拿这份列表和服务器日志里抓取器实际访问的 URL 做对照，看哪些入口只存在于脚本执行之后；第三步，把站内搜索、筛选、分页等高频路径单独列出来，确认它们是否有静态链接可到达。次序不要颠倒，否则很容易把“日志里没抓到”误判成服务器问题。
不同抓取器对脚本的处理并不一致
各搜索引擎的渲染能力、渲染队列长度和超时阈值都不一样，同一个页面在 A 处能看到链接，在 B 处可能只拿到空壳。把希望寄托在“对方一定会执行脚本”上并不可靠，能静态输出的部分尽量静态输出。
修正思路
优先把关键入口放回 HTML：分页使用可点击的链接，每一页都有真实 URL；列表页即使由脚本渲染，也应在首屏保留一份静态的入口列表，例如分类索引页或全量条目索引。Sitemap 可以作为 URL 的补充来源，但它提供不了页面之间的路径上下文，不能替代内链。渲染服务能解决一部分问题，同时带来额外成本与失败率，不适合作为唯一依赖。
分页与“加载更多”的处理
如果必须保留“加载更多”的交互，可以在其下方同时输出指向后续页面的普通链接，让交互与入口各司其职。这样既不影响体验，也让深层条目有一条稳定的发现路径。
记录与复核
- 改版或更换前端框架后，重新导出一次首屏链接列表，与历史版本对比。
- 把“首屏链接数”作为发布前的一项检查，而不是上线后再补救。
- 定期抽查抓取日志中深层条目的访问量，观察是否随前端调整出现明显波动。
链接可见性决定发现，发现决定后续的一切。首屏 HTML 里没有的入口，抓取器通常也不会替你补上。