移动端优先索引实行之后，搜索引擎在多数情况下会以移动端代理的视角来判断一个页面的内容与质量。很多站长在电脑上把页面检查一遍觉得没问题，却在移动端表现上始终差一截，问题往往就出在“桌面能看、移动端看不到”的那些细节上。
下面是一套可以直接照着做的移动端适配自查流程，重点不是把页面做得多花哨，而是保证蜘蛛和用户在移动端拿到的是同一份内容。
为什么移动端要单独查一遍
桌面浏览器的窗口足够宽，很多布局问题会被掩盖。比如一个被 CSS 隐藏的侧边栏，在桌面上只是少了一块装饰，在移动端却可能是正文的入口；一张靠宽度撑开的表格，在桌面上读得通顺，在手机上会把整页顶出横向滚动条。这些问题在桌面自查时几乎不会暴露，只有切换到移动视角才会浮现。
另外，移动端页面常常是另一套模板，甚至是另一套地址（例如 m 开头的子域）。模板不同，输出就可能不同，所以移动端需要按独立页面来核对，而不是默认它和桌面一致。
自查时可以准备的三种视角
- 桌面浏览器：作为基准，确认内容和链接本身是完整的。
- 真机或设备模拟：用真实手机或浏览器开发者工具的设备模式，把宽度切到 360 至 414 像素区间，看首屏、正文、按钮是否可用。
- 爬虫 UA 视角：用工具或命令行以搜索引擎的移动端 UA 请求一次，直接看返回的 HTML 里有没有正文，而不是只看渲染后的画面。
移动端最容易出问题的地方
- viewport 缺失或写死宽度：没有 viewport 标签时，手机浏览器会按桌面宽度缩放，字小到看不清；写死成固定像素宽度会让页面在小屏上溢出。
- 移动端隐藏正文：为了排版把部分段落、表格、说明放进移动端 display:none 的容器里。用户看不到，蜘蛛也可能拿不到。
- 首屏图片或懒加载异常：图片依赖滚动后才加载，正文配图位置长期留白，或加载脚本出错导致整块内容为空。
- 移动端与桌面端地址不一致：使用 m 子域或独立移动域名时，两端没有互相标注，canonical 指向混乱，容易被当成重复内容。
- 弹窗和浮层遮挡内容：打开就弹出的 App 下载引导、优惠券浮层盖住正文，关闭按钮小到点不到。
- 字号与点击区域过小：正文明显偏小，导航链接密集排列，误触率高。
- 横向滚动：宽表格、长代码块、固定宽度的图片把页面撑宽，用户需要左右拖动才能读完。
- 图片体积过大：移动网络下大图加载缓慢，首屏长时间空白，影响体验也影响抓取效率。
一份可以照做的自查清单
- 在设备模拟里打开首页、栏目页、详情页各一个，先看首屏三秒内能出现什么。
- 查看页面源码，确认正文段落出现在 HTML 里，而不是只在脚本里拼出来。
- 检查 viewport 标签是否存在且取值合理，页面在 360 像素宽度下是否出现横向滚动条。
- 点击导航、分页、面包屑，确认链接可点、目标地址正确、没有多余跳转。
- 关闭 JavaScript 再打开一次页面，看看还剩多少可读内容，作为兜底参考。
- 记录移动端的加载表现，重点看首屏图片和第三方脚本的耗时。
- 如使用独立移动域名，核对两端页面是否互相指向同一主版本地址。
修的时候按什么顺序
先修影响内容可见性的
正文被隐藏、图片不加载、脚本报错导致空白，这些会让蜘蛛和用户都拿不到内容，优先级最高。修完再用爬虫 UA 请求一次，确认正文确实出现在返回的 HTML 中。
再修影响使用和速度的
字号、点击区域、横向滚动、浮层遮挡属于体验问题，不一定立刻反映在抓取上，但会影响用户在页面上的停留和后续点击，值得排进日常迭代。
移动端自查的底线只有一条：蜘蛛用手机视角打开页面时，拿到的正文和你用手机看到的内容应当是一致的。做到这一点，剩下的都是优化。
移动端适配不是一次性任务。模板改版、活动页上线、第三方脚本更新，都可能让移动端页面出现新的问题，建议把它写进上线前的检查项，每隔一段时间用真机再走一遍关键页面。