很多站点在桌面端看没有问题，换到手机上就露出破绽：正文少了几段，导航折进汉堡菜单后找不到二级栏目，表格横向溢出，弹窗挡住正文还关不掉。移动端适配常被当成设计环节的事，但它同时影响访客能不能读完内容，也影响蜘蛛拿到的是不是一个完整页面。
下面按几个可以实际动手检查的角度整理一遍，适合在改版、上线、换模板之后拿出来对照。
一、先确认移动端和桌面端是不是同一个页面
响应式布局、独立 m 站、同一地址按 UA 返回不同模板，这几种做法都常见。形式本身不是问题，关键在于内容是否对得上。
- 桌面端出现的正文段落，移动端是否完整保留，有没有被折叠成“展开阅读全文”才能看到；
- 桌面端展示的导航、面包屑、相关链接入口，移动端是否还能走到；
- 移动端是不是额外塞了一堆桌面端没有的推广模块，把主要内容挤到很靠下的位置；
- 如果用了独立 m 站，canonical 是否指向正确的首选地址，而不是互相指着对方。
当两边内容差异很大时，蜘蛛按哪个版本理解页面主题就变成一件说不清的事。与其事后解释，不如尽量让两个版本承载同样的信息。
二、视口与基础布局
- viewport 声明是否写对，宽度是否跟随设备宽度；
- 是否为了“看起来整齐”直接禁用缩放，让需要放大的访客没法放大；
- 长表格、代码块、预格式化文本是否横向溢出，导致整页左右晃动；
- 正文字号在手机上是否需要反复双指放大才能读顺。
这些属于基础项，改动成本不高，但直接影响访客的第一印象。移动端留不住人，后面的内容运营也很难展开。
三、交互元素能不能点得到
手机和鼠标最大的区别是手指的落点没那么精确。
- 按钮、链接的可点区域是否过小、过密，容易误触相邻项；
- 依赖 hover 展开的下拉菜单、二级导航，在触屏上是否根本打不开；
- 弹窗、浮层、Cookie 提示是否遮挡正文，关闭按钮是否小到点不中；
- 电话、地址、邮箱这些信息是否做成了可点击链接，减少访客手动复制。
四、资源加载与流量成本
- 图片是否按显示尺寸输出，而不是把桌面端大图直接丢给手机；
- 是否使用响应式图片属性或现代图片格式，减少不必要的体积；
- 是否有体积偏大的脚本、字体、第三方组件挡住首屏内容；
- 懒加载是否把首屏内的关键图片也一起懒掉了，反而拖慢可见速度。
移动端网络环境参差，资源控制比桌面端更敏感。可以先用弱网模式看一遍首屏，通常能发现问题集中的位置。
五、移动端与蜘蛛访问
移动 UA 抓取已经是常态。如果站点按 UA 做跳转或返回不同模板，需要确认几件事：
- 跳转目标是否稳定，避免出现移动 UA 跳 A、桌面 UA 跳 B 的循环；
- 移动版本是否可正常抓取，没有在 robots 里被顺带屏蔽，也没有被登录墙挡住；
- 移动 UA 是否被访问频率限制误伤，和正常访客一起拦在门外；
- 两个版本是否都能返回正常状态码，而不是一方跳向另一方又跳回来。
这些属于技术层面的地基问题。处理好未必带来什么额外收益，处理不好却会持续消耗排查精力。
六、可以定期过一遍的清单
- 用手机打开首页、栏目页、内容页，各看一遍正文和入口是否完整；
- 检查页面是否有横向滚动条，表格和图片是否溢出；
- 点击主导航、分页、表单提交按钮，确认都能正常响应；
- 用移动 UA 模拟抓取一个内容页，对比返回内容与状态码；
- 把移动端和桌面端的信息差异记下来，分批拉齐，不要一次全改。
移动端适配不是一次做完就结束的项目，而应该成为每次改版、每次上线前的固定检查项。
如果人力有限，优先处理内容缺失、入口走不通、状态码异常这三类问题，收益最直接，也最容易验证。