独立 m 站还是自适应：目录站移动端的三条路，和从 m 站迁回来的代价
独
目录站的页面结构其实很简单：首页、几十个分类页、成千上万个条目页，模板就那么几套。越是这种结构，移动端技术路线的选择越能放大成整站的差距——选对了只维护一份，选错了就是两份内容长期不同步。
图片来源：网络，版权归原作者所有，侵权请联系删除
三条路到底差在哪
先把概念掰清楚，业内经常把前两个混着说。
| 方案 | URL | 服务器返回 | 维护份数 |
|---|---|---|---|
| 响应式 | 同一套 | 同一份 HTML，靠 CSS 媒体查询变布局 | 1 |
| 动态适配 | 同一套 | 按 UA 返回不同 HTML | 1 套数据 + 2 套模板 |
| 独立 m 站 | m.xxx.com | 完全独立的一套 | 2 |
响应式和动态适配的共同点是 URL 只有一个，这是它们最大的优势——权重、外链、收藏、分享全部落在同一个地址上。独立 m 站则是把流量分成两个站点来运营，需要额外维护两端的对应关系。
独立 m 站的三个代价，第二个最容易被低估
第一个代价是维护。两套模板、两套发布流程，条目页改一次要同步两次。目录站的条目数量以千计，人工同步几乎必然出现偏差。
第二个代价是对应关系。两端都要标注，PC 页指向移动页，移动页指回 PC 页，标注写漏或者指错，搜索引擎看到的就是两个内容相近但不互相认领的站点。条目页动辄上万，模板一旦漏了某个参数场景，出问题的页面就是一批而不是一个。
第三个代价是跳转。用户从搜索结果点进 PC 页再被跳到 m 站，多一次往返，移动端弱网环境下这一跳的成本不算小。判断跳转有没有生效，别只看手机浏览器，用爬虫 UA 去请求一遍看返回什么。
什么情况下 m 站反而合理
不是所有站都该立刻拆掉 m 站。两种情况下留着是划算的：一是 PC 端和移动端的业务形态确实不同，移动端要的是扫码、定位、一键拨号这类能力，PC 端是一套完整的信息架构；二是 m 站已经跑了多年、积累了独立的权重和外链，迁移的收益短期内盖不住风险。
除了这两种，尤其是目录站这种模板少、页面多的形态，响应式基本是唯一理性的选择。
决定迁回主域，映射表这么写
迁移的核心不是切换上线，是一张 URL 映射表。按下面的顺序做，比直接把 m 站 301 到首页稳得多。
- 先导出全部 m 站 URL，按模板归类，不要用页面标题去猜对应关系
- 逐类确认主域上的对应页：分类页对分类页，条目页对条目页，对不上的才落到上层分类
- 映射关系是 1 对 1 的用 301；确实无对应的整类，宁可返回 410 也不要全部堆到首页
- 上线后保留两端的标注一段时间，等主域页面稳定收录再撤
- 观察期至少留一个月，重点看主域对应页的展现量有没有接住原来 m 站的量
迁移期间最容易犯的错，是同时改 URL 结构和换模板。两件事一起做，出了问题分不清是哪件导致的。
动态适配要补的那一个响应头
如果选的是动态适配（同一 URL 按 UA 返回不同 HTML），记得带 Vary: User-Agent。它告诉缓存和搜索引擎：同一个地址有不同的版本，别拿给 A 的版本去回应 B。少了这一行，CDN 缓存下来的 PC 版 HTML 会被发给移动端用户，反过来也一样。
上线前拿这三件事自查
视口配置是否按设备宽度动态适配、有没有写死宽度；可点击区域的尺寸和间距够不够手指点；移动端页面上的内容是不是完整的——移动优先索引下，搜索引擎看的是移动端版本，移动端删掉的内容等于没写。
三条路没有绝对的好坏，只有跟你的维护能力匹不匹配。目录站这类"模板少、页面多、改得勤"的站，把份数压到最小，通常就是最优解。