单页应用（SPA）里，页面切换时地址栏会变化，但服务器可能从头到尾只返回同一份 HTML。这类站点做收录时，常见的卡点不是内容不够，而是"能被蜘蛛当成独立页面处理的地址"其实没几个。下面按地址形态拆开看。
井号是给浏览器看的，不是给服务器看的
URL 中 # 之后的部分叫片段（fragment），它只在浏览器内部生效，不会随请求发送到服务器。也就是说，/list#page-2 和 /list 对服务器来说是同一个请求，返回的 HTML 完全一样。搜索引擎抓取时通常也会把带 # 的地址归一成不带 # 的地址来处理，片段本身不构成一个可被抓取的独立 URL。
所以像 /#/detail/123 这种哈希路由，蜘蛛拿到的始终是首页那份 HTML。地址栏里看着"不同"的那些页面，在抓取层面只是同一个地址。
History 路由：地址变了，内容有没有跟着变
用 pushState 把地址改成 /detail/123 之后，URL 本身是真实地址了，关键是服务器收到这个请求时能不能返回对应内容。
- 如果服务器对所有路径都回退到同一个空壳 HTML，内容全靠前端 JS 渲染，蜘蛛要先执行 JS 才可能看到正文，链路长、成本高，也更容易在渲染环节被跳过。
- 如果服务器能针对这些地址返回带标题、正文、内链的 HTML，抓取和后续的规范化判断都会简单很多。
- 更麻烦的情况是：地址路径各不相同，返回的 HTML 却完全一样。这样就变成了一批内容相同的 URL，谁被留下由规范化和去重决定，不由站点决定。
三种常见做法的实际差别
纯哈希路由
所有页面共用一个物理地址，天然只有一份 HTML。在这种结构上做收录，通常需要另外为每个内容生成可返回内容的地址，再把哈希地址映射过去，或者干脆改造成真实路径。
History 路由 + 客户端渲染
地址是规范的，但 HTML 是空壳，需要确认渲染后的内容能被拿到。同时页面之间要有正常的 <a href> 链接——是 a 标签里的 href，不是 onclick 跳转，蜘蛛不会去点按钮。
服务端渲染或预渲染
每个地址返回的内容不同、互相可链接、有独立的标题与正文。这种结构对抓取最友好，后续排查也最省事。
链接形式：可点的按钮不等于可爬的内链
单页应用常把导航写成 div 加点击事件，或者用统一的跳转函数处理。蜘蛛顺着链接爬行时看的是 a 标签里的 href，JS 触发的跳转不一定能被跟着走。把主要导航、列表项、面包屑改成标准链接，改动不大，但往往是这一类站点最直接的改善点。
判断哪些地址值得独立收录
- 内容确实不同，不是同一个列表的筛选结果或排序变化。
- 该地址被单独搜索时有被找到的价值，比如商品、文章、分类首页。
- 存在稳定的内链入口，能从首页或其他页面点进来，而不是只靠站内搜索才能到达。
- 服务器能对这个地址返回内容，而不是统一回退到首页 HTML。
筛选、排序、无限滚动加载出来的中间状态，一般不需要每个都进索引。用参数处理，或者干脆不把中间状态做成独立地址，比事后清理省力。
一份可执行的检查清单
- 随机抽几个地址，关掉 JS，看服务器返回的 HTML 里有没有正文与链接。
- 看服务器日志或抓包，确认蜘蛛请求的是 /detail/123 这类真实路径，而不是只有根路径反复出现。
- 检查页面之间的跳转是否是 a href，而不是纯 JS 事件。
- 确认规范化标签指向的那个地址，是站点能返回内容的那个。
- 用站点地图或内链，把重要的深层地址暴露出来，别只留首页一个入口。
判断标准可以很简单：关掉 JS 之后，如果这个地址返回的 HTML 能让人看明白这是个什么页面，蜘蛛多半也能；如果不能，就要先解决渲染成本与返回内容的问题。
单页应用的收录问题，多数不是内容太少，而是地址和内容对不上。把这一点理顺，其他优化才有落点。