搜索抓取通常以移动端页面为准，蜘蛛用移动端 UA 请求、解析并渲染 HTML。这意味着桌面版页面上那些结构清晰的内链，未必都能算作 URL 发现的入口。如果移动版为了节省流量或简化视觉，把导航、分页、相关推荐砍掉了一部分，对应地址的发现路径也就跟着变窄了。
蜘蛛实际看的是哪一份 HTML
站点实现移动端的方式不同，检查重点也不同：
- 响应式布局：同一份 HTML，链接天然一致，风险主要来自窄屏下的脚本行为。
- 独立移动域名：桌面站和移动站的链接需要分别维护，容易一边更新、一边漏改。
- 同一 URL 动态服务：按 UA 返回不同 HTML，如果模板分支写得粗糙，移动分支可能少渲染几块内容。
后两种情况下，桌面版看到链接齐全，并不代表抓取时也能看到。
链接缺失的几个常见场景
- 导航被折叠进需要点击才展开的菜单，链接由前端脚本临时生成，脚本没跑完就等于没有链接。
- 移动版精简掉了侧栏、标签聚合、上下篇跳转这些模块，地址只能靠 Sitemap 补。
- 用可点击的容器元素代替链接标签，配合脚本跳转。这种写法不会在 HTML 里留下可跟随的地址，只会留下一个死按钮。
- 用脚本在渲染时删除节点，而不是用样式隐藏。隐藏的链接通常还能被抓到，被删除的链接就彻底消失。
链接还在，但路径走不通
另一种情况更隐蔽：地址确实存在于页面，但只藏在交互里。列表的“加载更多”、轮播图的横向切换、按需展开的折叠面板，移动端常把它们做成按钮事件，后续页面的 URL 不会出现在初始 HTML 中。蜘蛛不会去点按钮，第二页之后的地址就少了带路的人。
分页同理。桌面端常见的上一页、下一页文字链接，在移动端经常被换成一个图标或一个脚本函数。如果同时没有给分页地址留出静态入口，翻页链接的发现效率会明显下降。
一套可执行的自查顺序
- 用移动端 UA 抓一份原始 HTML，与桌面版对比链接数量、层级深度和栏目覆盖面。
- 对比渲染前后的 DOM，看有多少链接是脚本注入的，这些链接在渲染失败时会一起消失。
- 逐个检查关键入口：顶部导航、栏目标题、面包屑、列表分页、正文内链、页脚。
- 核对 Sitemap，把移动版确实无法展示的地址补进去，并确认它们都能正常访问、返回 200。
- 用服务器日志对照移动端蜘蛛实际抓到的 URL 与预期清单，找出长期没人访问的地址。
内链为主，Sitemap 兜底
内链仍然是 URL 发现的第一入口，它同时传递层级关系和相对权重；Sitemap 更像一份补漏清单，适合安置那些没有合适内链位置的地址，比如筛选结果页、历史归档页、深度较深的详情页。两者都到位时，移动端少几个模块不会立刻造成大范围漏抓；只依赖 Sitemap 而内链残缺，抓取节奏往往会被拖慢。
不要指望移动版省掉的内容会被桌面版补上。抓取以移动版为准，移动版没有的入口，基本就等于不存在。
修复时把握一个原则
移动版可以简化视觉呈现，但尽量不要简化链接结构。导航、分页、面包屑这类结构性入口，保持可解析的 HTML 形态；需要收起的内容优先用样式隐藏，而不是用脚本从 DOM 中移除。改动之后，隔一段时间再回看日志，确认新增地址确实开始被访问。