为什么移动版成了抓取的“第一现场”
在移动优先的抓取与索引策略下，蜘蛛请求你的 URL 时，多数情况下是按移动端来理解和渲染页面的。这意味着，桌面版做得再完整，如果移动版少了正文、少了参数、少了链接，蜘蛛读到的就是那份残缺版本。很多站点“内容明明有，就是抓不到”的问题，源头都在这里。
所以移动端不该被当成桌面版的缩小副本，而应视为主要交付形态。
别让桌面版和移动版对不上
同一个 URL 在不同 UA 下返回不一致的 HTML，是抓取异常的常见起点。做法大致有三类，代价不同：
- 响应式：一套 HTML，靠 CSS 控制布局，内容天然一致，维护成本最低，也最不容易出错。
- 动态服务：同一 URL 按 UA 返回不同 HTML。这种模式下，正文、标题、结构化数据三处必须对齐，改模板时要两边同时改。
- 独立移动站：现在已较少见。若仍在使用，m 站与主站的对应关系要通过跳转或标记交代清楚，否则两套 URL 容易被当成彼此独立、内容重复的页面。
渲染资源不能拦在门外
移动端页面往往依赖 CSS 和 JS 才能把内容展开。如果 robots.txt 屏蔽了 /js/、/css/ 目录，或者这些资源需要登录、带特定请求头才放行，蜘蛛拿到的很可能是一份没有正文的空壳。
抓取是渲染的前提。渲染资源被拦，等于把内容锁在门后。
值得顺手检查的几处：核心样式与首屏脚本是否对蜘蛛放行；WAF 或安全策略有没有把非浏览器 UA 直接拦截；频控规则会不会把蜘蛛的并发请求误判成攻击。
移动端隐藏的内容去了哪里
折叠面板、Tab 切换、“展开更多”，这些交互在移动端非常普遍。判断标准不是“用户看不看得见”，而是“内容在不在渲染后的 DOM 里”。
- 用 CSS 隐藏、但内容仍在 HTML 中：一般能被读取到。
- 必须点击或滚动到特定位置，才由 JS 注入：风险较大，蜘蛛不一定触发这一步。
- 桌面端有、移动端直接不输出：以移动版为主要参考时，这部分内容可能被忽略。
首屏内容与加载顺序
渲染有时间预算，资源越重、阻塞越多，蜘蛛最终能拿到的内容越少。几个可以落地的调整：
- 标题、正文主体、关键导航链接尽量放进初始 HTML，或尽早注入，不要全压到最后一段脚本。
- 减少首屏阻塞的同步脚本，第三方统计、客服、营销插件能异步就异步。
- 图片使用合适尺寸并做懒加载，但不要把首屏主要内容也丢进懒加载。
- 控制 DOM 嵌套深度，过深的层级会增加解析成本。
移动可用性同样在传递信号
viewport 设置、字号、可点击区域间距、整屏弹窗遮挡，这些看起来是体验问题，但也侧面反映页面是否认真做了移动端。viewport meta 写错，页面会按桌面宽度渲染，抓取时的布局判断也会跟着偏。频繁弹出的全屏广告或登录浮层，还可能把正文压到视口之外。
上线前的自查清单
- 用移动端 UA 请求同一 URL，返回的正文与桌面版是否一致。
- robots.txt 是否放行了 CSS、JS、图片等渲染所需资源。
- 折叠、Tab 中的内容是否存在于渲染后的 DOM 里。
- viewport 是否正确，是否有整屏遮挡且不易关闭的弹窗。
- 移动端页面的响应时间与稳定性如何，有无 5xx 或超时。
- 移动版是否有需要交代的 canonical 或跳转关系。
移动优先抓取不是一次性改造，而是一种持续对照：每次模板改版、每次第三方脚本上新，都值得回头看一眼——移动端的蜘蛛到底读到了什么。