搜索引擎的抓取早就不只来自桌面 UA。百度、Google、Bing 的蜘蛛都会用移动 UA 请求页面，部分站点在移动 UA 下的抓取频次甚至更高。对蜘蛛池的入口页来说，如果移动端返回的是一个缺链接、缺正文或被浮层遮住的版本，蜘蛛走到这里就等于走进死角。下面把移动端适配的做法、检查项和验证方法过一遍。
为什么入口页的移动端不能将就
入口页在整条链路里承担的是“被发现”和“继续往下走”的角色。桌面端正常不代表移动端正常，很多问题只在切换 UA 之后才暴露：
- 模板判断出错，移动 UA 落到一个空列表页或错误页；
- 导航和列表被折叠进需要点击的菜单，HTML 里看不到链接；
- 正文被“打开 App 查看全文”或全屏浮层挡住；
- 图片资源没有按屏幕压缩，首屏加载慢，蜘蛛在超时前拿不到完整 HTML。
这些情况不一定立刻表现为抓取失败，但会让蜘蛛拿到一个信息量很低的页面，URL 发现的效率自然下降。
常见的三种适配做法
响应式：同一套 URL、同一份 HTML
同一个 URL 返回同一份 HTML，靠 CSS 媒体查询适配屏幕。对蜘蛛最友好：无论什么 UA，看到的链接和正文都一样，不存在内容不一致的争议。入口页如果是自己可控的模板，这种方式维护成本最低。
独立移动域或独立移动路径
例如 m.example.com 或 /m/ 目录，通过跳转或适配声明指向移动版。这种做法要额外注意两点：移动版必须能被直接抓取，不要只靠 JS 跳转；PC 与移动的链接数量、层级尽量接近，否则会出现“PC 有 50 个入口、移动只有 5 个”的落差。
按 UA 动态返回
根据 UA 判断返回不同模板。风险在于判断规则容易写错：不认识的 UA 落到哪一套？规则改动后有没有回归测试？如果要用，建议让默认分支返回信息更全的那一版，而不是最简版。
判断标准很简单：拿移动 UA 请求一次，看返回的 HTML 里能不能找到你想让蜘蛛看到的链接和文字。找不到，就是适配没做好。
移动页面要重点检查的几项
- viewport：缺少 viewport 声明时，部分渲染会按桌面宽度处理，造成排版异常甚至链接被挤出可视区。
- 链接是否在 HTML 里：靠 JS 点击后才生成的链接，渲染抓取不一定等得到，能在源码里出现更稳妥。
- 遮挡物：全屏浮层、Cookie 提示、下载引导可能覆盖首屏内容和链接。
- 资源体积：移动网络下首屏越大越容易超时，入口页尽量控制图片和第三方脚本。
- 跳转链：移动端常见的自动跳转如果配置成链式跳转，蜘蛛可能只跟到第一跳就停了。
- 状态码：移动版不存在的路径要返回明确的 404，不要返回 200 加一个空页面。
PC 与移动的内容一致性
不必追求两版完全一样，但核心信息要对得上：标题、主要正文、指向下一层的链接，以及对蜘蛛可见的 URL 集合。如果移动端少了一批入口链接，实际效果等于把这条路径砍掉一半。对于聚合类入口页，至少保证链接数量级接近。
怎么验证移动端抓取没问题
- 用常见移动 UA 对入口页发起请求，保存返回的 HTML，检查状态码、正文和链接是否齐全。
- 把移动 UA 和桌面 UA 返回的链接集合做一次对比，看差集有多大，差在哪一类链接上。
- 在抓取日志中筛出移动 UA 的记录，看返回码分布和抓取频次，是否有集中出现的 5xx 或超时。
- 如果日志里能看到渲染抓取，注意页面渲染完成的时间是否偏长。
- 改动模板后重新跑一遍上述步骤，避免修好桌面端、弄坏移动端。
几个容易忽略的小坑
- 移动端返回 302 跳到移动域，但移动域本身又需要 JS 才能渲染出链接。
- 缓存策略不一致：CDN 缓存了桌面版，移动 UA 拿到的是同一份缓存。
- 同一个入口页在不同移动 UA 下返回不同版本，导致行为难以复现。
- 页面在移动端加了“仅 App 内打开”的提示，蜘蛛看到的是提示而不是内容。
把移动端当成一个独立场景来对待就够了：用移动 UA 实际请求一次，看看蜘蛛能拿到什么。能拿到完整链接和正文，这条路径才算通；拿不到，就先别急着加量。