你的AMP页面，是不是已经成了网站的“负资产”？

你还在为每个新页面配一个AMP版本吗？
上周我帮一个做母婴内容的客户看技术架构，发现他们维护着两套几乎一模一样的文章页——一套是正常页面，一套是AMP，连评论区都得同步改两次。

结果呢？AMP页面在百度里搜不到，微信里点开还是跳转到主站，谷歌流量不到总流量的3%。开发同事说：“现在改个按钮颜色，得改三处。”

这玩意儿，真还值得留着？

AMP的核心承诺，在国内还成立吗？

AMP当初就靠两件事打天下：

  • 页面快得像按了加速键
  • 在谷歌搜索里带个闪亮的“⚡”图标，还能优先展示

但国内不是谷歌主场。
我们刷百度、用微信搜、点小红书链接——这些入口压根不认AMP那一套。

百度确实推过MIP，但早就没声儿了。你搜任何词，结果页里根本看不到AMP专属标识，更别说排名加成。它不像谷歌那样把AMP当亲儿子捧着。

一个真实场景：某知识付费平台早年全站上了AMP，想通吃海内外。后来发现，百度对AMP页面收录慢、索引浅，用户从微信公众号点进来，经常404。最后他们悄悄把AMP页面全做了301跳转，现在连技术文档里都不提这个词了。

速度优势，真的无法被替代吗？

AMP快，是因为它砍掉了太多东西：

  • 不让用自定义JS
  • CSS不能超过50KB
  • 连<img>都得换成<amp-img>

可现在随便一个主流建站工具，都能做到：

  • 图片自动转WebP + 懒加载
  • 关键CSS内联，非关键JS延后执行
  • 静态资源走CDN，首屏渲染压到1秒内

而代价呢？
你没法在AMP里加微信登录按钮，没法嵌入小程序卡片，轮播图要重写逻辑，表单验证还得自己手撸。

用户点进来不是为了看“谁更快”，而是想“能不能马上下单/报名/看完整视频”。一个能完成任务的页面，比一个快但啥也干不了的页面，转化率高得多。

维护成本与SEO风险，你计算过吗？

AMP不是“做一次就完事”。它是持续烧钱的活儿：

  • 内容更新要双线操作：CMS发一遍，AMP模板再发一遍
  • 结构化数据（比如Article标记）两边得对齐，漏一处，Google Search Console就报错
  • 一旦AMP页面失效，搜索引擎可能直接降权整站

更麻烦的是数据断层：
用户在谷歌缓存的AMP页面上点了“立即咨询”，这个行为你很难追踪到是谁、从哪来、点了什么——因为那不是你的服务器，是谷歌的镜像。

SEO同学的时间很贵。与其天天盯着AMP校验失败告警，不如多写两条优质外链，或者把商品详情页的加载流程再顺一遍。

哪些特殊情况，可能还需要考虑AMP？

别一刀切，但得拎清前提：

  1. 你90%以上的自然流量来自谷歌：比如出海SaaS官网、海外独立站博客，用户搜英文关键词进来的。这种场景下，AMP仍是基础配置。
  2. 纯文字资讯站，且极度依赖首屏打开速度：比如突发新闻推送，用户等不及加载广告和推荐位，就要看到标题和第一段。但注意——现在用<link rel="preload">+服务端渲染也能做到类似效果。
  3. 你已经有全自动AMP发布流水线：比如用Jekyll+插件生成AMP页，CI/CD自动校验上线，人力成本趋近于零。否则，别硬撑。

重点来了：所有这些情况，都需要你打开百度统计或GA，查清楚“AMP页面带来的有效转化有多少”。如果数字模糊、归因不清、老板问不出所以然——那就先停。

放弃AMP，你的网站速度该怎么办？

别慌。把原来花在AMP上的时间，挪到这几件实在事上：

  1. 盯死三个核心指标：LCP（最大内容绘制）、FID（首次输入延迟）、CLS（累积布局偏移）。它们在Chrome DevTools里点一下就能测，也是百度搜索资源平台直接抓取的数据。
  2. 图片动真格：
    • 把所有<img>标签加上srcset和sizes
    • 上传时自动转AVIF/WebP（WordPress插件、Vercel部署都能开）
    • 首屏图片加loading="eager"，其他一律loading="lazy"
  3. 代码减负：
    • 删除未使用的CSS（Chrome DevTools → Coverage tab）
    • JS用type="module"自动分包，老浏览器回退到传统加载
    • title、meta description这些基础标签，确保每页唯一且手写，别靠模板硬塞
  4. 服务器不拖后腿：
    • 如果用WordPress，换LiteSpeed或WP Rocket这类带OPcache+对象缓存的方案
    • 如果是静态站，国内选腾讯云CDN或又拍云，开Brotli压缩+HTTP/2

一个优化到位的响应式页面，加载不比AMP慢，功能却完整得多——这才是用户愿意停留、分享、复访的基础。

如何给你的AMP页面做个“体检”，决定去留？

今天下午就能动手，不用等排期：

  1. 打开百度统计后台 → 流量来源 → 筛选“AMP页面” → 看“搜索引擎”占比。如果低于5%，基本可以判缓刑。
  2. 打开Chrome，访问你最常更新的3个AMP页面URL → 右键“检查” → Network tab → 刷新 → 记下“Finish”时间；再用同样方式测对应的标准页面。差距不到300ms？那AMP的“快”已经没意义了。
  3. 打开百度搜索资源平台 → “索引量” → 查AMP页面的收录数。如果长期卡在个位数，说明百度根本没当它是正经页面。
  4. 约开发同学喝杯咖啡，问一句：“如果下周起不再维护AMP，省下的工时，够我们把首页首屏LCP压到0.8秒以内吗？”

答案如果是“够”，那就别犹豫了。

今天就能执行的操作：启动你的AMP退出计划

别删，先转。按顺序来，今天就能走完第一步：

  1. 打开你的CMS后台（比如WordPress / Docusaurus / VuePress） → 找到AMP插件或配置项 → 把“自动为新文章生成AMP”开关关掉。
  2. 打开百度搜索资源平台 → “资源提交” → 把所有AMP页面URL批量删除（别怕，只是告诉百度“别再抓这些了”）。
  3. 打开你的Nginx/Apache配置，或CDN后台（如腾讯云CDN控制台） → 新增一条规则：把 /amp/ 开头的所有URL，301重定向到对应的标准页面URL（例如 /post/abc/amp/ → /post/abc/）。
  4. 最后，打开站点地图sitemap.xml → 删除所有含/amp/的URL条目，保存并重新提交给百度。

做完这四步，你已经卸下了大半负担。剩下的，是让标准页面跑得比AMP更稳、更聪明。