很多站点的移动端问题不是一夜之间冒出来的，而是随着页面改版、插件升级、活动页上线一点点累积起来的。等到被发现时，通常是访客留言说“手机上根本点不到按钮”，或者统计里移动端的跳出率明显高于桌面端。移动端自查的价值，就是把这些毛病在变成投诉之前先找出来。
先确认移动端到底占多少流量
打开统计工具，把最近 30 天的访问按设备类型拆开看。如果移动端占比已经过半，那么任何一次桌面端改版都应该同步验证手机的显示效果；如果占比很低，也要判断是“确实没人用手机访问”，还是“手机打开体验太差，来过一次就不再来”。前者可以放缓，后者属于要优先处理的问题。
顺带看一眼移动端的落地页分布。常见的现象是自然搜索带来的移动访客集中在少数几个长尾页面，而这些页面往往不是重点维护的对象，问题也最容易藏在那里。
一份可以逐条打勾的检查清单
- viewport 声明：页面头部是否有正确的 viewport meta，是否存在写死宽度（如 width=1200）导致整页缩小。
- 横向滚动：手指左右滑动时页面是否会跟着晃，通常来自超宽表格、固定宽度图片或绝对定位元素。
- 字号与行高：正文在手机上是否小于 14px，行高是否过密，长段落有没有被挤成细长条。
- 点击区域：按钮、翻页、关闭图标是否小于 40px 见方，相邻链接是否挨得太近容易误触。
- 弹窗与浮层：客服弹窗、订阅提示、Cookie 提示是否会遮住正文，是否有明确的关闭入口。
- 表格与代码块：宽表格有没有包一层横向滚动容器，否则会把整个页面撑宽。
- 图片与视频：是否做了自适应，有没有因为缺少宽高比而在加载时把内容顶来顶去。
- 表单输入：输入框类型是否匹配（手机号、邮箱、数字），标签和错误提示在键盘弹出后是否还看得见。
自查的具体做法
- 用真实手机看，不要只看浏览器里的模拟器。模拟器不会暴露触控误点、键盘遮挡、字体渲染差异这些问题。
- 挑 5 到 10 个有代表性的页面：首页、一个栏目页、一篇长文详情页、一个表单页、一个搜索结果页。
- 在竖屏和横屏各过一遍，重点看有没有横向滚动条。
- 把发现的问题按“影响转化路径”和“只是不美观”分成两档，先修第一档。
- 修完之后，用同一批页面再走一遍，确认没有引入新问题。
移动端不等于另一套内容
有些站点为了让手机看起来清爽，用 CSS 把大段正文隐藏起来，只留标题和摘要，或者干脆指向一个内容更少的独立域名。站在访客角度，这等于给了两份不同的答案；站在抓取角度，被隐藏的内容能不能被看到，取决于隐藏方式。用 display:none 藏掉的内容，很多情况下权重会被削弱；如果确实要简化展示，更稳妥的做法是折叠面板，内容仍在 HTML 里，用户点开就能读到。
小屏上的蜘蛛行为也值得留意
现在的搜索引擎抓取大多以移动端 UA 为主，也就是说，手机端看到的结构，很大程度上决定了机器读到的结构。如果移动端页面里插入了大量内联脚本、把首屏内容推迟到交互之后才渲染，蜘蛛看到的主体内容可能比你想的少得多。自查时可以对比一下：手机打开页面时，首屏出现的内容，和查看源代码时 HTML 里直接带的内容，是否大体一致。
改完之后的验证方式
- 找两三种不同尺寸的机型，至少覆盖一个小屏和一台大屏手机。
- 看移动端的 JavaScript 报错日志，排版问题常常伴随脚本异常。
- 观察一到两周内移动端的跳出率、页面停留和表单提交量是否朝好的方向变化。
- 如果站点有移动端专用的资源，确认这些资源的缓存和压缩策略与桌面端保持一致。
移动端自查不必追求一次改完。优先处理挡住访客完成关键动作的地方，比如注册、下单、留言、翻页，其余细节可以排进后续的迭代计划。
把它固定成日常动作
最省力的方式，是把这份清单并进现有的上线流程：每上一个新页面、每做一次改版，就用同一套标准在真机上走一遍。写进发布检查项里，比靠记忆靠谱得多。时间久了，移动端的问题不会再集中爆发，而是被分散地、低成本地处理掉。