如果你刚开始做网站，移动端 SEO 是一个容易让人抓不住重点的领域。它不像写标题、填描述那样有明确的完成感——你打开自己的网页，手机上看着正常，Google 却不给排名。
这篇文章按一条完整的链路来讲：Google 怎么抓取你的移动页面、移动端有哪几种建站方案、页面速度和用户体验具体优化什么、关键词和结构化数据在移动端要注意什么、以及怎么用工具验证效果。每一部分都给出可以动手操作的具体做法。
先理解一件事：Google 看你的网站，用的是手机
以前的规则是：Google 用电脑去抓你的网页，用电脑看到的内容来建立索引。手机上显示成什么样，只影响排名的一部分。
现在的规则变了：Google 用手机去抓你的网页。它看到的，就是手机用户看到的。
这意味着什么？如果你在电脑上做了一版网页，内容齐全、排版漂亮；手机打开时因为屏幕窄，你隐藏了一部分内容，或者需要用户点击「展开」才能看到——Google 看到的，就是那个隐藏后的版本。
它不会去猜「电脑上还有更多内容」，它只认手机版里实际存在的东西。
怎么检查：打开 Google Search Console，用「网址检查」工具输入你的页面地址，看它显示的抓取方式是「Googlebot 智能手机」还是「Googlebot 桌面」。如果是桌面，说明这个页面还没被纳入移动优先索引；如果是智能手机，说明 Google 已经在用手机版评估你的页面了。
手机上「看不见」的内容，Google 也看不见
这里要区分两种情况，很多新手会踩坑。
第一种：内容在 HTML 里，只是被折叠了。
比如一个「常见问题」区块，默认是收起的，用户点击标题才会展开。这种没问题。Google 能读到 HTML 里的文字，折叠不影响索引。
第二种：内容需要点击按钮才会加载出来。
比如一个「加载更多」按钮，点击后通过 JavaScript 向服务器请求数据，把新内容插入页面。这种就有问题了。Google 的爬虫不会去点那个按钮，它不会执行这个交互，所以那些「加载更多」出来的内容，Google 根本不知道存在。
实操结论：关键内容一定要放在页面初始的 HTML 里。可以用折叠面板，但不要用「点击后才请求」的方式加载核心内容。
图片的懒加载是个例外。用 loading="lazy" 属性延迟加载首屏以下的图片是安全的，Google 仍然能发现并索引这些图片，只是浏览器会等用户快滚到那里时才真正下载。
移动端建站的三种方案
1. 自适应设计（Responsive Design）
同一套 HTML 和 URL，靠 CSS 媒体查询适配屏幕。Google 官方推荐这种方式，理由是维护成本最低、不存在设备判断逻辑、爬虫和用户看到的内容一致。
一个固定宽度列的非响应式写法长这样：
<div style="width: 320px;">内容</div>
它在 iPhone 上显示正常，在桌面或平板上就会很难看。改成响应式：
<div style="width: 100%; max-width: 320px;">内容</div>
2. 动态服务（Dynamic Serving）
同一个 URL，根据 User-Agent 返回不同的 HTML。这种方案允许你为移动端精简结构，代价是你必须确保服务器正确识别 Googlebot Smartphone，返回与用户看到一致的版本。识别出错时，Google 抓到的可能是默认版或桌面版，索引数据就会偏离预期。
3. 独立 URL
使用 m. 子域名或类似结构。如果选择这条路径，canonical 和 hreflang 必须配置严谨：
<!-- 移动页面 m.example.com/page -->
<link rel="canonical" href="https://example.com/page" />
<!-- 桌面页面 example.com/page -->
<link rel="canonical" href="https://example.com/page" />
<link
rel="alternate"
media="only screen and (max-width: 640px)"
href="https://m.example.com/page"
/>
hreflang 同理：移动 URL 的 hreflang 指向移动 URL，桌面 URL 的 hreflang 指向桌面 URL。配错会导致 Google 无法正确关联多语言版本。
需要说明的是，即使移动端优先索引成为常态，保留桌面版本仍有价值。有些功能或内容在移动端体验不佳，桌面版能提供更完整的操作路径。SEO 之外，用户体验本身也值得维护。
页面加载速度优化：Core Web Vitals 测的是什么
Google 用 Core Web Vitals 衡量页面体验，目前主要看三个指标：
LCP（最大内容绘制）：页面上最大的内容块多久显示出来，通常是主图或大标题，阈值 2.5 秒以内。
INP（交互到下次绘制）：用户点击、切换、提交后，界面多久给出反应。它测的是页面生命周期内所有交互，不是只测第一次。阈值 200 毫秒以内。INP 已经取代了 FID——FID 只测第一次交互的输入延迟，无法反映后续操作的卡顿。
CLS（累积布局偏移）：加载过程中内容有没有跳动。阈值 0.1 以内。
这些数据来自真实用户，不是你自己打开网页测出的数字。PageSpeed Insights 会同时给出实验室数据和真实用户数据，后者才是 Google 排名的依据。
怎么查：打开 PageSpeed Insights，输入网址。它会给你两份数据：一份是实验室模拟环境下的测试结果，用来诊断具体问题；另一份是真实用户的数据，这个才是 Google 用来排名的依据。
如果实验室数据很好，但真实用户数据很差，通常是因为：你的页面在某些地区加载慢、或者登录用户看到的页面没法被缓存、或者用户的手机性能比你测试的机器差很多。
具体的优化手段：
- 限制重定向：每一个重定向都增加一次请求往返，减少不必要的跳转
- 压缩图片：用 WebP 等现代格式，同等质量下比 JPEG 小 25%-35%
- 使用 CDN：把内容分发到离用户更近的节点，降低 TTFB
- 精简插件和脚本：删除不必要的插件、第三方脚本和页面元素
- 压缩代码：去掉 HTML、CSS、JavaScript 中多余的字符和空格
- 开启缓存：让重复访问的用户不必重新下载全部资源
- 选择合适的服务器：服务器本身的响应能力是速度的下限
图片 LCP 和 CLS 优化：移动端 SEO 新手最容易忽略的大坑
图片是拖慢移动端页面最常见的原因，也是造成布局偏移的常见原因。
给图片显式设置宽度和高度。
<img src="photo.webp" alt="描述" width="800" height="450" />
浏览器在图片下载完成前就能根据这两个属性预留空间，避免图片加载后把下方内容挤下去，这是 CLS 最常见的成因。
加上 width 和 height 之后，浏览器在图片还没下载完的时候，就知道该给它留多大的位置。这样图片加载出来的时候，不会把下面的内容挤下去，CLS 就不会超标。
根据屏幕选择合适的图片尺寸。
不要在手机上加载一张 2000 像素宽的大图，然后靠 CSS 把它缩小。用户下载的还是那张大图，白白浪费流量和时间。
用 srcset 让浏览器根据屏幕宽度选择合适的图片：
<img
src="photo-800.webp"
srcset="photo-400.webp 400w, photo-800.webp 800w, photo-1200.webp 1200w"
sizes="(max-width: 640px) 100vw,
(max-width: 1024px) 50vw,
33vw"
alt="描述"
width="800"
height="450"
/>
这段代码的意思是：浏览器你看着办，屏幕窄就用小图，屏幕宽就用大图。
首屏的大图不要懒加载。
首屏那张最大的图（通常是 LCP 元素），加上 loading="lazy" 反而会让它加载得更晚，LCP 变得更差。懒加载只用在首屏以下的图片上。
别忘了 alt 文本，它对图片搜索和可访问性都有作用。
网站在手机上「好不好用」也会影响 SEO
Google 不会直接测量「用户觉得好不好用」，但用户的行为会间接影响排名。如果用户打开你的页面，发现字太小看不清、按钮太挤点不到、弹窗挡住内容，他会返回搜索结果换一个页面。这个行为信号 Google 是能看到的。
几个基本的检查点：
字体大小：正文至少 16px，太小在手机上阅读吃力。
留白：元素之间留出足够间距，页面不拥挤。
减少杂乱：去掉不必要的元素，专注核心操作路径。
可点击元素的大小：重要按钮放在拇指容易触及的区域，一般偏屏幕下方。按钮和链接的点击区域至少 48×48 像素。太小的话，用户很容易点错旁边的元素。
弹窗：不要一进页面就弹出一个覆盖全屏的广告或订阅框。Google 明确会惩罚这种「 intrusive interstitial」（侵入式插页）。如果要做弹窗，等用户滚动到一定深度再弹，或者用底部横幅代替全屏遮罩。
段落长度：手机上屏幕窄，一大段文字挤在一起很难读。把长段落拆短，两到三句话一段就够了。
结构化数据在移动端的应用
Schema 标记是一种结构化数据，帮助搜索引擎理解页面内容。在移动端搜索结果中，它能让你的页面显示星级评分、产品信息、活动详情等富摘要，提升点击率。
检测工具：Google 的富媒体搜索结果测试。
生成工具：Merkle 的 Schema Markup Generator 等免费工具，无需写代码，填写信息后生成 JSON-LD 代码。
WordPress 用户：可以用 Schema App Structured Data 这类插件自动生成。
需要注意：独立 URL 方案下，结构化数据中的 URL 必须使用移动版本的地址，否则 Google 可能无法正确关联。
移动端的关键词与元标签
移动端的搜索行为和桌面端不同，关键词策略要相应调整。
语音搜索：越来越多的移动搜索通过语音发起，查询更接近自然语言。与其优化「北京 餐厅 推荐」，不如覆盖「附近有什么好吃的餐厅」这类长句。
标题标签：控制在 50-60 个字符。移动端搜索结果展示宽度有限，过长会被截断。
元描述：移动端约 100 个字符左右为宜，同样避免被截断。
验证与监控
Google Search Console：查看抓取方式、页面体验报告、Core Web Vitals 数据。在「体验」→「Core Web Vitals」中可以看到按 URL 分组的真实用户指标。
PageSpeed Insights：同时查看实验室诊断和真实用户数据，重点关注 75 百分位的 LCP 和 INP。
Lighthouse：开源自动化工具，审计性能、可访问性、PWA、SEO 等维度，适合开发阶段逐项排查。
Google Analytics：在「技术」→「技术详情」中查看访问你网站的移动设备型号分布，了解用户实际使用的设备类型。在所有常规报告中养成按设备类型分段的习惯，移动端表现才能被单独追踪。
Google 官方文档：Google 提供了按平台分类的移动端优化指南，覆盖不同 CMS 的具体操作。这些文档属于其站长支持体系的一部分，同时还有论坛和在线支持渠道。
新手对网站移动端SEO该从哪里开始
不要试图一次做完所有事情。按这个顺序来：
第一步：在 Search Console 里确认你的页面已经被 Googlebot 智能手机抓取。
第二步：用 PageSpeed Insights 看真实用户数据，找出 LCP 和 INP 最差的页面。
第三步：给所有图片加上 width 和 height，首屏以下的图片加 loading="lazy"。
第四步：检查页面上有没有需要点击才能加载出来的关键内容，如果有，改成初始 HTML 里就存在。
第五步：用手机实际打开你的页面，手指操作一遍，感受有没有明显的卡顿、误触、或者内容跳动的现象。
这五步做完，你的移动端 SEO 基础就打好了。剩下的内容优化、关键词策略、外链建设，都是在稳固的基础上叠加的事情。
