列表页、商品列表、文章列表里，很多内容并不是一次性写进 HTML 的，而是用户点一下“加载更多”或滚到页面底部之后，才由脚本请求数据并插入 DOM。对用户来说体验顺滑，但对蜘蛛来说，如果这些插入内容里带着链接，而它们从未出现在初始 HTML 里，那么这批 URL 的发现路径就是断的。
蜘蛛看到的和你看到的不是同一份页面
蜘蛛抓取时，通常先拿到服务器的第一份响应，再根据自身能力决定是否执行页面里的 JS。执行 JS 的排期往往比抓静态 HTML 更慢、更不确定。所以判断一个入口能不能被走通，最简单的办法是：把页面的脚本屏蔽掉，看看剩下的 <a href> 还有多少。剩下那部分，才是蜘蛛走得最稳的那部分。
三种加载方式，蜘蛛各自能看到什么
加载更多按钮
点击按钮后由接口拉取数据、拼成列表，这是最常见的一种。如果按钮本身不改变 URL，也不产生新的链接节点，蜘蛛就没有可点击的对象。补救方式是让每一批数据都有一个可访问的地址，例如 /list?page=2 或 /list/page/2，并且这个地址返回的 HTML 里直接包含该批条目的真实链接。
无限滚动
无限滚动的地址通常始终是同一个，滚动位置不会写进 URL。除非脚本用 History API 把页码或游标写进地址栏，否则蜘蛛只能看到第一屏。即使写了 URL，也要确认这个地址单独打开时是否能直接渲染对应内容，而不是从第一屏重新开始加载。
懒加载与延迟插入
图片懒加载一般不影响链接发现，但如果链接节点是滚动到视口之后才创建的，蜘蛛不滚动就永远拿不到。给关键列表加服务端渲染的第一屏，或者把“查看更多”做成指向独立列表页的普通链接，都能绕开这个问题。
给蜘蛛留一条能走的路
- 首屏服务端渲染：列表前若干条、导航、相关推荐都直接出现在 HTML 里。
- 保留静态分页：即便前端是“加载更多”，也要有 /page/2 这类地址作为备份入口。
- 用 pushState 而不是 hash：把状态写进路径或查询串，便于被抓取，也便于日志统计。
- 分页地址写进 Sitemap：层级较深的列表页，多一条独立的发现通道。
- 在枢纽页给出入口：栏目页、标签页、专题页里放可见链接，别只依赖脚本触发。
- 检查分页地址的可索引性：避免 noindex，或 canonical 一律指回第一页，把分页入口提前掐掉。
一个简单的自检顺序
- 用“查看网页源码”（不是审查元素）看页面里到底包含哪些链接。
- 屏蔽 JS 再访问一次，看列表和分页还在不在。
- 挑一个深层列表页，数一数从首页到它需要几次点击。
- 翻日志，看这个地址有没有被访问过，抓的是 HTML 还是接口。
- 对没有入链的新地址，补一条内链或写进 Sitemap，再观察后续是否出现访问记录。
蜘蛛是否来访、何时来访由搜索引擎自己决定。以上做法只是减少路径上的断点，并不保证页面一定被抓取或收录。
把地址挪回 HTML 是最省事的一步
抓取路径的本质是：有没有一条从一个已知地址出发、连续可达的链接。动态加载改变了内容的呈现方式，但没有改变这条规则。把最需要被发现的地址从脚本里挪回 HTML，通常比事后补各种提交手段更划算。