先分清站点用的是哪一種移動适配

同一篇内容在手机端和电脑端表現不一样时，收錄問题往往不是内容质量本身，而是頁面被拆成了两套入口。動手之前先確認站点属于哪一類：

• 响應式：同一套 URL，靠 CSS 适配屏幕。收錄入口只有一個，問题多出在渲染环节。
• 獨立移動域：例如 m.example.com 與 www 各自有 URL。入口變成两套，容易出現重复與分散。
• 動態服務：URL 相同，但按 User-Agent 返回不同 HTML。表面是一個入口，實际是两套内容。

三種方式的核對重点並不相同，先归類再检查，能避免在错誤的模板上反复改動。

同一 URL 的方案：先看抓取到的正文主体

响應式和動態服務共同的坑

這两種方式 URL 不變，但如果移動端把正文折叠成“展開全文”，或者内容要等 JavaScript 二次請求才填充，抓取到的初始 HTML 里可能只剩标题和一句摘要。核對方式很直接：用移動 UA 請求一次，看原始响應里的文字量，而不是只看浏览器里渲染完的效果。

如果两端 HTML 差异明顯，重点確認三處：正文主体是否在初始响應中；被隐藏的内容是否属于可解析的样式隐藏；是否有整块内容依赖异步接口返回。

動態服務還要額外看缓存

按 UA 分發内容的站点，務必確認缓存层没有把桌面版本發给了移動 UA，或者反過来。一個常见現象是：缓存命中後，爬虫拿到的 HTML 與目前頁面模板對不上，正文结构甚至标簽都對不齐。核對时清一次缓存再抓，看两次结果是否一致。

獨立移動域：URL 對應、指向和跳轉要能互相對上

移動域的問题通常集中在“對應關系断掉”。检查這几点：

• 移動頁能否被直接抓取，robots.txt 是否誤屏蔽了 m 目錄。
• 移動頁是否有自引用 canonical，而不是笼统地指向桌面頁。
• 桌面頁與移動頁之間是否有可解析的跳轉或标注關系，而不是只靠一段 JS 判断屏幕宽度。
• 移動頁是否出現在 sitemap 或站内連結中，還是只能靠跳轉才能被發現。

如果移動頁内容與桌面頁基本一致，通常把其中一個版本作為收錄主版本、另一個用 canonical 收敛即可；如果移動頁是精简版（正文大幅缩短、參數被裁掉），两套都保留反而會分散信号。

一套可执行的核對顺序

1. 列出移動 URL 與桌面 URL 的對應表，先看有没有頁面缺一半。
2. 分別用移動 UA 和桌面 UA 抓取，儲存原始 HTML，不依赖渲染结果。
3. 對比两端正文主体的文字量，明顯缩短的那一端要單獨排查原因。
4. 检查 canonical 與頁面間的互相指向是否自洽，有没有指向一個抓取受限的地址。
5. 检查移動端是否存在獨立的屏蔽設定：noindex、robots 規則、登入墙、App 跳轉遮罩。
6. 確認内鏈和 sitemap 使用的是哪一套 URL，避免两套入口混着提交。
7. 最後再看索引中實际保留的是哪個版本，以及是否長期停留在舊版本上。

几個反复出現的情况

• 移動頁打開後自動跳到 App 下载頁，抓取到的正文為空。
• 移動端預設只顯示摘要，完整内容要点击展開，初始 HTML 里没有正文。
• 图片和评论区懒加载，正文本身没問题，但頁面整体可解析内容偏少。
• UA 判断把未知爬虫当成桌面端，返回了带彈窗或跳轉的版本。
• 移動域被整体 noindex，同时又出現在 sitemap 中，信号互相矛盾。

移動适配的核對目标不是让两端内容完全一致，而是让“被收錄的版本”和“用戶實际看到的版本”對得上。先统一入口，再谈内容质量，顺序反了會白做很多無用功。

如果两端差异确實必要，就把差异控制在不影响正文主体的范围内，让标题、核心正文和主要連結保持一致，其余展示形式可以各按各的来。這样既保留了移動体驗，也不會让索引在两個版本之間反复選擇。