很多蜘蛛池入口頁在桌面浏览器里看着正常，但搜尋引擎爬虫現在大多以移動端 UA 為主發起抓取。同一個 URL，用移動 UA 請求和用桌面 UA 請求，返回的 HTML 可能完全不同——被拦截的资源、被隐藏的連結、被折叠的内容，都會影响 URL 發現。下面整理移動端适配里几個容易被忽略的环节。
移動優先索引下，蜘蛛優先看哪個版本
主流搜尋引擎的索引判断已经從桌面優先轉向移動優先，含义是爬虫更多以移動 UA 抓取頁面，並用移動端渲染结果来判断頁面内容與連結。如果入口頁對移動 UA 做了差別對待，比如给手机訪客返回精简版、给桌面返回完整版，那蜘蛛看到的往往是那個精简版。
這里有個常见誤解：以為移動端精简版更快，對抓取更友好。速度快本身不是坏事，但如果精简版里少了指向下一步的連結，蜘蛛就断在入口頁了。加载速度替代不了連結的完整性。
响應式和獨立 M 站，各自容易出問题的地方
响應式：連結没少，但可能被样式藏起来
响應式站点通常用 CSS 媒体查询控制顯示。問题在于：桌面端用 display:none 隐藏、移動端才展示的模块，用桌面 UA 抓时就是隐藏連結；反過来也一样。更麻烦的是，有些模板靠 JS 监听窗口宽度變化才把内容寫進 DOM，蜘蛛渲染时的預設视口不一定触發那段逻辑。
獨立 M 站：跳轉鏈和 UA 判断容易出岔子
桌面站跳 M 站、M 站又跳回桌面站，這種双向跳轉如果判断寫得粗，容易出現循环，或者把蜘蛛反复彈来彈去。另外 M 站域名常常不在同一份 robots.txt 的覆盖范围内，容易出現一邊放開一邊限制，蜘蛛進得来却走不深。
移動端渲染时容易被挡住的連結
- 汉堡菜單里的導航：菜單内容要点击後由 JS 插入的话，蜘蛛渲染时不一定會去点，導航連結可能压根没進入 DOM。
- 整块懒加载的列表：图片懒加载本身没關系，但不少站点把整個列表項连同里面的連結一起做成滚動到才加载。
- 移動端专属的遮罩层：全屏遮罩如果盖住内容区，用戶看不到，蜘蛛渲染出的可见文本也可能被判定為數量很少。
- 唤起 App 的脚本：部分頁面會尝试跳 App 或走自定义 scheme，這類脚本對爬虫没有意义，极端情况下還會干扰渲染過程。
怎么自己驗證一次
- 用命令行以移動 UA 請求入口頁，確認返回的 HTML 里含你期望的連結，而不是只返回一個空壳。
- 對比移動 UA 與桌面 UA 两次返回的連結數量與锚文本，差异大的位置就是排查重点。
- 在浏览器里模拟移動设备並限制部分脚本，观察導航連結是否真的存在于最终 DOM。
- 翻訪問日誌，按 UA 分组看移動爬虫的請求占比與狀態碼分布，留意大量 4xx、5xx 或重定向。
- 如果站点對移動端單獨配過 robots 規則或 WAF 策略，检查它們是否只在移動 UA 上生效。
一些使用建议
- 不要把给移動端砍内容当成提速手段，入口頁的职责就是让蜘蛛拿到連結，連結没了這一步就失去意义。
- 導航、面包屑、分類列表這類结构性連結，尽量服務端渲染輸出，不依赖交互才出現。
- 响應式與獨立 M 站二選一时，挑团队能長期维護、且 UA 判断逻辑简單可驗證的那一種。
- 任何對移動 UA 的特殊處理，缓存、限速、跳轉還是屏蔽，都要能在日誌里看出效果，否則出問题只能靠猜。
- 适配不是一次性工作，模板改版後把上面的驗證步骤重新跑一遍。
蜘蛛不會主動告诉你它看到的是哪個版本。入口頁如果能让移動和桌面两種 UA 都拿到同一批連結，很多抓取量上不去的問题會自然减少，但這仍然取决于站点整体质量與抓取策略，不是單点改動就能决定的事。