移动端适配是站点运营里很容易被忽略的一个抓取变量。为了让手机用户打开更快，不少站点会单独搭一套移动域名（例如 m.example.com），或者单独划一套移动路径（例如 /m/），桌面端和移动端各维护一套链接体系。对访问者来说这可能没有差别，但对搜索蜘蛛来说，URL 发现入口被拆成了两条线：来自桌面端的爬取顺着桌面站的内链走，来自移动端的爬取顺着移动站的内链走，两边能采到的 URL 集合往往并不重合。
URL 分流通常是怎么形成的
分流很少是一次性设计出来的，多数是历史迭代留下的：
- 独立移动域名：早期用 m. 或 wap. 子域做移动站，模板与桌面站分开维护，链接结构也各自演化。
- 路径型移动站：把移动页面放在 /m/、/mobile/ 目录下，页面内容与桌面版高度相似，但 URL 不同。
- 动态自适应跳转：同一个 URL 根据 UA 或屏幕宽度返回不同版本的 HTML，链接集合也随之变化。
- 客户端渲染差异：桌面端走服务端渲染，移动端走前端路由，链接只在其中一端的 HTML 里出现。
分流给抓取带来的实际问题
抓取预算被摊薄到两套 URL 上
同一篇内容存在两个可访问 URL，蜘蛛需要在两份页面、两套内链上分别花费抓取请求。站点规模越大，重复消耗越明显，真正需要更新的新页面反而排在后面。
内链断层，新内容只被一边发现
如果移动站的内链只指向移动站，桌面站的内链只指向桌面站，那么入口越少的页面，越可能只被其中一侧发现。另一侧要么靠 Sitemap 补充，要么长期处于孤立状态。
信号分散
外链、内链、用户访问数据分别落到不同 URL 上，等于把同一份内容的信号拆成两半。这通常不是惩罚，而是分散，结果就是两边都不够明确。
把入口收敛起来的几种做法
做法没有绝对优劣，关键是选定一种并保持长期一致：
- 迁移到响应式：桌面与移动共用一套 URL，用 CSS 与视口适配。分流问题从根上消失，代价是前端改造量与移动端性能需要重新调。
- 保留移动站但统一内链图：移动页面内链指向规范版本，或在移动页上放置指向桌面版的等价链接，让两套 URL 的发现路径互相接得上。
- 明确规范版本：移动页通过 canonical 指向桌面版（或反向），配合 alternate 标注移动版，避免两边都被当成互不相关的内容处理。
- 动态服务保持链接一致：如果确实要按 UA 返回不同 HTML，至少让两种版本输出同一套可抓取的 a 标签链接，否则蜘蛛看到的是两份不同的站点地图。
Sitemap 与标注的协同
Sitemap 是分流场景下最重要的补位工具。建议只提交规范 URL，并保持 lastmod 与实际内容更新时间一致；如果移动版有独立 URL 且需要被发现，用 alternate 关系标注清楚，而不是把两套 URL 都当主入口提交。Sitemap 里混杂大量近似 URL，反而会稀释每条记录的可信度。
服务器稳定性是这一切的前提
分流场景下，同一份内容要响应更多次请求，服务器压力随之上升。如果移动站响应时间明显长于桌面站，或者跳转链路里出现 302 连环、超时、连接重置，抓取节奏就会被打断，蜘蛛更倾向于减少访问频次。先保证两侧响应速度接近、状态码干净，再谈入口收敛才有意义。
自查清单
- 桌面版与移动版的 URL 集合差异是否清晰可控，有没有维护成清单？
- 移动页与桌面页的 canonical、alternate 是否成对且互相指向？
- Sitemap 中是否存在同一内容的多套 URL？
- 两种版本的 HTML 里，主要导航与列表页链接是否都能到达？
- 移动站与桌面站的响应时间是否在同一量级？
- 用抓取工具分别以桌面 UA 和移动 UA 抓取，URL 数量差距是否合理？
入口收敛的价值不在某一次抓取，而在于让蜘蛛每次来都沿着同一张地图走。地图越稳定，新 URL 被发现的时间就越可预期。