搜尋引擎的抓取早就不只来自桌面 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 實际請求一次，看看蜘蛛能拿到什么。能拿到完整連結和正文，這條路径才算通；拿不到，就先別急着加量。