把桌面站和移动站分开部署，是不少站点早期就定下的架构：PC 用 www 域名，移动端用 m 子域或独立域名。两套 URL 指向同一份内容，收录上就出现一个必须先回答的问题——搜索引擎该以哪一套为准。
三种常见形态
- 响应式或自适应：同一套 URL，靠 CSS 适配屏幕。收录最简单，不存在两套地址的问题。
- 独立移动站：m.example.com 与 www.example.com 各有一套 URL，页面内容需要两边同步维护。
- 动态服务：同一 URL 按 User-Agent 返回不同 HTML。表面上只有一套地址，实际输出不同，出问题时最难定位。
移动优先索引下，以移动端为准
搜索引擎现在主要参考移动端的抓取结果来评估页面。也就是说，移动版的内容、链接、结构化数据、图片 alt 等，会直接决定这个页面能不能进索引、表现如何。桌面版内容更全、移动版被砍掉一半，这种差异会体现在收录质量上，而不是只在移动端搜索里体现。
互指关系怎么设置
移动版页面的 canonical 指向自己，桌面版页面的 canonical 也指向自己，两边各自独立。早期流传的做法是让移动页 canonical 一律指向桌面页，这在移动优先索引下已经不合时宜，会让抓取和评估都绕路。同时用 rel="alternate" 声明另一个版本，帮助搜索引擎确认二者是同一页面的两个形态，而不是重复内容。
自查顺序
- 两套 URL 的标题、正文、主要链接是否一致，差异是否可控。
- 移动版是否被 robots.txt 拦住或加了 noindex。移动优先下，这等于把整页的收录一起关掉。
- 移动版是否依赖大量 JS 才出内容，渲染失败时移动端几乎是空页。
- 两套地址是否在站内被混用，比如 PC 页面里的内链指向 m 站，移动版内链又指回 PC。
- sitemap 里是否只保留主版本，并且与实际声明一致。
要不要干脆合并
如果维护成本允许，用响应式把两套 URL 收敛成一套，是最省事的做法：不用维护互指关系，不用同步内容，内链也不会打架。短期无法改造的站点，至少保证移动版内容与桌面版对齐，并明确对外声明两个版本的关系。
两套 URL 并存时，如果把内链、sitemap、canonical 指向混着写，蜘蛛会在同一页面的两个地址之间反复往返，抓取预算被摊薄，收录判断也会变慢。
无论最终选哪一套，要做的其实是同一件事：让每个页面的主版本清晰、内容一致、内链一致，剩下的交给抓取和索引按自己的节奏跑。