很多运营在检查链接时，会看到类似 example.com/page#section-2 这样的地址。有人把它当成一个独立页面提交给搜索引擎，也有人担心这些带 # 的链接会分散收录。实际情况是，URL 片段标识符在抓取和收录中的角色，和普通路径参数很不一样。
片段标识符不参与 HTTP 请求
URL 中 # 后面的部分叫片段标识符，它的设计目的不是给服务器看的，而是给浏览器用的。当浏览器请求 example.com/page#section-2 时，发往服务器的请求实际上只有 example.com/page，#section-2 不会出现在 HTTP 请求里。服务器返回的 HTML 也完全一样。
这意味着，从抓取端看，同一路径下不同 # 的 URL，服务器响应内容没有区别。搜索引擎没有必要为每个片段单独保存一份文档。
搜索引擎通常怎么处理带 # 的 URL
在大多数情况下，搜索引擎会把 example.com/page#a 与 example.com/page#b 视为同一个页面，收录时一般以不带 # 的规范 URL 为主。你在索引里偶尔看到带 # 的链接，通常是外链或站内链接原样显示，并不代表它被当成了独立文档。
不过，如果页面内容完全依赖 # 切换，比如前端路由用 hash 控制不同视图，而服务器始终返回同一份 HTML，那么搜索引擎抓到的往往只是默认视图。其他片段对应的内容可能不会被单独收录，也不容易获得自己的排名。
hashbang 与前端路由的遗留问题
早期为了支持 AJAX 内容，出现过 #! 这种 hashbang 写法，以及配套的 _escaped_fragment_ 转义方案。现在这套做法已经不再被推荐，主流搜索引擎对 JavaScript 的渲染能力提升后，更希望站点使用真实路径。
如果前端路由使用 History API 的 pushState 改变路径，比如从 /list?page=2 变为 /list/2，这些就是不同的 URL，可以被单独发现和抓取。反过来，如果路径不变、只用 # 切换，则很难让每个视图都成为可收录页面。
站点运营中容易踩的几个坑
- 把 # 链接当页面提交：sitemap 或主动提交里放带 # 的 URL，基本不会带来额外收录，反而让数据看起来混乱。
- 内链指向 # 锚点却指望它被发现：锚点适合页内导航，不适合当成新页面的入口。若希望某块内容被收录，应给它一个独立路径。
- canonical 写成带 # 的地址：canonical 应指向不带片段的标准 URL，否则可能让搜索引擎困惑。
- 依赖 # 做分页或筛选：筛选结果若只在客户端用 # 切换，搜索引擎通常只能看到默认列表，很多 URL 不会被发现。
更稳妥的处理方式
如果你希望不同内容分别被收录，优先使用真实路径，并保证服务器能针对每个路径返回对应的 HTML。列表页的筛选、排序参数，可以用可抓取的链接暴露，但要有收敛策略，避免产生大量低价值 URL。
对于纯页内定位的锚点，继续用 # 没问题，只要不把它当成页面地址即可。检查内链时，可以把带 # 的链接统一还原到路径部分，再看这个路径是否已经被 sitemap 或内链覆盖。
把 # 当作页内书签，而不是新页面。需要独立收录的内容，就给它独立的 URL。
最后，观察服务器日志时，如果发现大量带 # 的请求，其实服务器看到的仍然是不带 # 的路径。真正要关注的是：同一路径是否对应了多个实际内容，以及这些内容有没有各自可发现的入口。理顺这一点，比纠结片段本身更有用。