很多站点的移動端問题不是一夜之間冒出来的，而是随着頁面改版、插件升級、活動頁上线一点点累积起来的。等到被發現时，通常是訪客留言说“手机上根本点不到按钮”，或者統計里移動端的跳出率明顯高于桌面端。移動端自查的價值，就是把這些毛病在變成投诉之前先找出来。
先確認移動端到底占多少流量
打開統計工具，把最近 30 天的訪問按设备類型拆開看。如果移動端占比已经過半，那么任何一次桌面端改版都應该同步驗證手机的顯示效果；如果占比很低，也要判断是“确實没人用手机訪問”，還是“手机打開体驗太差，来過一次就不再来”。前者可以放缓，後者属于要優先處理的問题。
顺带看一眼移動端的落地頁分布。常见的現象是自然搜尋带来的移動訪客集中在少數几個長尾頁面，而這些頁面往往不是重点维護的對象，問题也最容易藏在那里。
一份可以逐條打勾的检查清單
- viewport 声明：頁面头部是否有正确的 viewport meta，是否存在寫死宽度（如 width=1200）導致整頁缩小。
- 横向滚動：手指左右滑動时頁面是否會跟着晃，通常来自超宽表格、固定宽度图片或绝對定位元素。
- 字号與行高：正文在手机上是否小于 14px，行高是否過密，長段落有没有被挤成细長條。
- 点击区域：按钮、翻頁、關閉图标是否小于 40px 见方，相邻連結是否挨得太近容易誤触。
- 彈窗與浮层：客服彈窗、订阅提示、Cookie 提示是否會遮住正文，是否有明确的關閉入口。
- 表格與代碼块：宽表格有没有包一层横向滚動容器，否則會把整個頁面撑宽。
- 图片與视频：是否做了自适應，有没有因為缺少宽高比而在加载时把内容顶来顶去。
- 表單輸入：輸入框類型是否匹配（手机号、信箱、數字），标簽和错誤提示在键盘彈出後是否還看得见。
自查的具体做法
- 用真實手机看，不要只看浏览器里的模拟器。模拟器不會暴露触控誤点、键盘遮挡、字体渲染差异這些問题。
- 挑 5 到 10 個有代表性的頁面：首頁、一個栏目頁、一篇長文詳情頁、一個表單頁、一個搜尋结果頁。
- 在竖屏和横屏各過一遍，重点看有没有横向滚動條。
- 把發現的問题按“影响轉化路径”和“只是不美观”分成两档，先修第一档。
- 修完之後，用同一批頁面再走一遍，確認没有引入新問题。
移動端不等于另一套内容
有些站点為了让手机看起来清爽，用 CSS 把大段正文隐藏起来，只留标题和摘要，或者干脆指向一個内容更少的獨立域名。站在訪客角度，這等于给了两份不同的答案；站在抓取角度，被隐藏的内容能不能被看到，取决于隐藏方式。用 display:none 藏掉的内容，很多情况下權重會被削弱；如果确實要简化展示，更稳妥的做法是折叠面板，内容仍在 HTML 里，用戶点開就能讀到。
小屏上的蜘蛛行為也值得留意
現在的搜尋引擎抓取大多以移動端 UA 為主，也就是说，手机端看到的结构，很大程度上决定了机器讀到的结构。如果移動端頁面里插入了大量内联脚本、把首屏内容推迟到交互之後才渲染，蜘蛛看到的主体内容可能比你想的少得多。自查时可以對比一下：手机打開頁面时，首屏出現的内容，和查看源代碼时 HTML 里直接带的内容，是否大体一致。
改完之後的驗證方式
- 找两三種不同尺寸的机型，至少覆盖一個小屏和一台大屏手机。
- 看移動端的 JavaScript 报错日誌，排版問题常常伴随脚本異常。
- 观察一到两周内移動端的跳出率、頁面停留和表單提交量是否朝好的方向變化。
- 如果站点有移動端专用的资源，確認這些资源的缓存和压缩策略與桌面端保持一致。
移動端自查不必追求一次改完。優先處理挡住訪客完成關键動作的地方，比如註冊、下單、留言、翻頁，其余细节可以排進後續的迭代計划。
把它固定成日常動作
最省力的方式，是把這份清單並進現有的上线流程：每上一個新頁面、每做一次改版，就用同一套标准在真机上走一遍。寫進發布检查項里，比靠记忆靠谱得多。時間久了，移動端的問题不會再集中爆發，而是被分散地、低成本地處理掉。