双套URL是怎么来的
早些年做移动适配，常见做法是给移动端单独准备一套域名或目录，例如 m.example.com、/mobile/、/wap/。桌面端页面负责承载内容，移动端页面负责使用体验，两边各有各的URL。这种做法本身没有对错，问题往往出在运营过程中：桌面端加了新栏目，移动端还没同步；移动端换了模板，桌面端的老链接忘了处理。搜索蜘蛛可能只爬到其中一套，另一套要么找不到入口，要么找到了却是一堆内容相近的页面。
先把对应关系理清楚
双套URL的核心是“一对一”。每个桌面端页面都应该能找到一个功能相同的移动端页面，反之亦然。建议在栏目规划阶段就把规则定下来，并用程序保证执行：
- 桌面端页面输出指向移动端对应页的链接，移动端页面反向指回桌面端，让蜘蛛在两套页面之间来回走，不要留下只有一边能到达的孤页。
- 页面头部同时声明两个版本，配合 canonical 指明主版本，避免两套内容互相竞争同一个位置。
- URL 结构尽量保持一致，只替换域名或目录前缀，例如 /news/2024/05/abc.html 对应 m.example.com/news/2024/05/abc.html，方便比对和排查。
- 建立一份映射清单，栏目调整、批量改版时按清单同步，不要靠记忆。
自动跳转要留个后门
很多站点用 User-Agent 判断设备，桌面 UA 访问就跳到移动站，移动 UA 访问桌面地址又跳回来。这种跳转如果写得过于绝对，蜘蛛抓桌面页面时会被直接送去移动页面，结果两套URL里只剩一套能被稳定抓取。更麻烦的是跳转目标如果带上了会话参数，同一个页面会裂变成无数个URL。
跳转的目的是把用户送到更合适的页面，不是把蜘蛛挡在门外。判断设备时尽量保留“不跳转”的出口，让蜘蛛可以按原URL抓取到完整内容。
robots.txt 与 Sitemap 的分工
两套URL经常共用一份 robots.txt，也经常被分别处理。这里容易出现的两个问题：一是移动端目录被整段 Disallow，桌面端页面里指向移动端的链接全成了死胡同；二是 Sitemap 只提交桌面端地址，移动端页面长期没有站外入口，只能靠内链慢慢被发现。
实际做法可以简单一些：
- 确认两套URL都不会因为误封而断链，尤其是静态资源目录和分页目录。
- Sitemap 里以主版本URL为主，同时用 alternate 之类的标注把对应关系写清楚，让蜘蛛明白这不是两个互不相关的站点。
- 如果移动端确实存在大量低质页面，例如自动生成的筛选列表，单独限制这部分，而不是一刀切关掉整个目录。
日常检查清单
- 随机抽 20 个桌面端页面，检查移动端对应页是否存在、是否可访问、状态码是否正常。
- 看服务器日志里移动端目录的抓取记录占比，如果长期接近零，说明入口太少或跳转太激进。
- 检查是否有“桌面能打开、移动端 404”或者反过来的情况。
- 排查跳转链，尽量控制在一次跳转内完成，避免 A→B→C 的连环跳。
- 栏目新增或下线时，同步更新两套URL和映射清单。
小结
移动端与桌面端的双套URL，本质上是同一份内容的两套门牌号。运营要做的不是让蜘蛛二选一，而是把两套门牌号对应清楚、互相可达、主次分明。对应关系理顺之后，内容本身没有变，能被发现的入口却多了一条。