移動端流量占比高已经是常態，但不少站点的移動适配是顺手做的：模板套用、断点随手寫、彈窗和浮层後来再补上去。桌面端看着正常，手机上却是另一套体驗。這篇文章從站点运营的角度，给出一份可以定期跑的移動端自查清單。
第一步：確認视口與基础設定
很多移動端错位的根源不在样式表，而在最開头的一行 meta。先看這几項：
- 是否設定了 viewport，有没有寫成固定宽度（比如 width=1200）導致頁面被整体缩放。
- 是否誤用了 user-scalable=no 或 maximum-scale=1，把用戶的双指缩放鎖死，對可讀性不利。
- 桌面端與移動端是否指向同一套地址。如果用了獨立的移動子域，要確認跳轉稳定，两邊内容一致。
第二步：看布局和内容有没有被砍掉
布局层面
- 是否出現横向滚動條，通常来自固定宽度的图片、表格或代碼块。
- 按钮、導航項之間的間距是否過小，手指容易点错。
- 正文是否被侧栏、悬浮客服、底部吸底栏挤得只剩一條窄缝。
内容层面
- 移動端是否隐藏了大段正文，只留一句請到电脑端查看。這種做法两邊都不讨好。
- 图片是否按容器自适應，而不是撑破布局。
- 表格是否有横向滚動容器，或者改成卡片式展示。
第三步：检查那些後来加上去的東西
很多移動端体驗問题，来自後期接入的第三方组件：
- 全屏彈窗、開屏广告，是否一進頁面就挡住内容。
- 悬浮按钮是否覆盖正文，或遮挡了關键操作。
- 統計代碼、评论组件、客服脚本是否在移動網絡下加载缓慢，甚至阻塞渲染。
- 字体和图标库是否按需加载，避免首屏拉一堆用不到的资源。
一個简單的判断方法：用手机在弱網环境下打開几個典型頁面，如果首屏几秒内還看不到正文，就值得排查了。這里谈的是可用性，不涉及任何排名承诺。
第四步：確認移動蜘蛛看到的内容
現在搜尋引擎普遍以移動端為主要抓取對象，所以移動端能不能正常渲染，會直接影响内容被發現。自查时重点看：
- 移動端是否對正文做了大量懒加载，且没有可识別的降級内容。
- 主要内容是否藏在需要点击展開之後才出現。
- 移動端與桌面端的标题、正文、關键信息是否存在明顯差异。
- robots 規則或 UA 判断是否誤伤了移動蜘蛛，比如只放行桌面端的 UA。
一份可执行的检查流程
- 挑選首頁、栏目頁、列表頁、正文頁各两到三個代表頁面，不要只看首頁。
- 用真机检查，而不是只用開發者工具的模拟视图，至少覆盖一台安卓机和一台 iPhone。
- 记錄問题：截图、頁面地址、机型、出現條件，方便後續修复和复驗。
- 按影响面排序修复，先處理遮挡正文、横向滚動、按钮点不中這類硬問题。
- 修复後重新拉一次移動端渲染结果，確認内容确實出現了。
把它變成固定動作
移動适配不是一次性任務。模板改版、接入新组件、上新广告位，都可能把已经正常的頁面重新弄坏。比較實际的做法是：每次改版上线前跑一遍上面的清單，每季度再整体复检一次，把移動端体驗当成和服務器狀態、抓取日誌一样的日常巡检項。