不少站点在电脑上看着挺正常，換到手机上就變了样：正文被彈窗盖住、宽表格要左右拖、按钮小到点不准。移動端体驗不只是给訪客看的，搜尋引擎的抓取和渲染也越来越多地以移動端為准，手机上看不清、拿不到的頁面，在索引里往往也好不到哪去。
移動端自查要解决什么問题
自查的目的不是把頁面做得花哨，而是確認三件事：正文能不能被正常讀到、主要内容是不是一開始就在 HTML 里、小屏上有沒有明顯的操作障碍。這三件事分別對應抓取、渲染和用戶留存，任何一項出問题，後面的優化都要打折。
视口與基础排版
先把浏览器窗口缩到 375px 左右宽，模拟一台普通手机，然後逐條看。
- 视口标簽：確認頁面存在 meta viewport，且包含 width=device-width、initial-scale=1。缺了它，手机浏览器會按桌面宽度渲染再整体缩小，字會變得很小。
- 字号與行高：正文字号建议不低于 14px，行高留足；長段落老老實實單栏，不要在小屏上搞两栏或窄侧栏。
- 横向滚動：只要有一個元素超出屏幕宽度，整頁就能左右拖。常见元凶是寫死宽度的图片、宽表格和绝對定位的浮层。
- 宽表格：要么改成卡片式排版，要么只让表格自身的容器可以横向滚動，別让整個頁面跟着滚。
遮挡正文的元素
這一項在移動端最常见，也最容易被忽略。
- 首次進入就彈出的全屏广告、下载引導、優惠券浮层，到底盖住了多少正文。
- 底部固定條占掉了多少可视区域，滚動到底时能不能關掉。
- 關閉按钮的尺寸和位置，手指能不能一次点中，會不會点了反而跳走。
- 彈层出現时背景是否還能滚動，頁面有没有被鎖死。
检查方法很简單：用手机打開頁面，什么都不点，看首屏能看到多少正文。如果首屏只有一張大图和一句“打開 App 阅讀全文”，那么移動端抓取拿到的有效内容大概也就這么多。
图片與静態资源
- 图片是否設定了自适應宽度，比如 max-width:100%，有没有硬寫死的宽高。
- 首屏大图的体积，在移動網絡下會不會拖很久才出来。
- 懒加载有没有把首屏内容也一起懒掉，導致一開始是空白。
- 自定义字体在移動端的加载與回退，避免長時間白屏。
交互後才出現的内容
有些站点把正文放在“展開全文”“点击查看”之後，或者完全依赖前端渲染，初始 HTML 里只有一段空壳。搜尋引擎虽然能执行一部分脚本，但执行预算和等待時間都有限，能不能稳定拿到内容並不可控。
- 折叠内容是否本来就寫在 HTML 里，只是被 CSS 隐藏。
- 關键正文是否要等接口返回才插入，接口超时頁面就空了。
- “加载更多”的後續内容，是否有可被抓取的獨立地址，而不是只能靠点击才出現。
移動端地址與跳轉
- 如果做過 m. 獨立站，检查移動端與桌面端的互跳，是否形成循环或無限重定向。
- 是否采用不区分 UA 的自适應方案，避免同一個地址對不同设备返回差异過大的内容。
- 移動端地址是否也能被站内連結正常指向，而不是只靠自動跳轉才能到達。
一份可以照着做的检查清單
- 把窗口缩到 375px，逐頁看首屏正文占多少。
- 临时關掉脚本，看正文是否還在。
- 检查视口标簽，並確認頁面不存在横向滚動。
- 用手机資料網絡打開，记下首屏加载需要多久。
- 检查彈窗、底栏、返回顶部按钮是否遮挡内容。
- 抽查五個移動端地址，看互跳和重定向是否正常。
- 在服務端日誌里筛移動端 UA，確認返回的狀態碼是 200。
移動端自查不必一次做完整站，先挑流量最大、更新最勤的几個栏目跑一遍，把“正文讀得到、抓得到”這两件事解决掉，通常比繼續往上加功能更划算。