AMP 退场这几年：目录站从这件事里该带走的三条经验

先说结论：现在新建的目录站，没必要上 AMP。这句话本身没什么信息量，真正有意思的是 AMP 为什么会走到今天这一步，以及它留下的那几条可以直接用在目录站上的结论。

图片来源：网络，版权归原作者所有，侵权请联系删除

大致的时间线

AMP 是 2015 年提出、2016 年前后大规模推开的一套移动加速页面框架，谷歌给了它很实在的好处：Top Stories 轮播的入场资格，以及搜索结果里那个闪电图标。有段时间它几乎是新闻站的标配。转折发生在 2020 到 2021 年，闪电标先被移除，随后 Top Stories 不再要求页面必须是 AMP 格式，取而代之的是页面体验信号，也就是后来的 Core Web Vitals。到 2021 年 11 月前后，任何达标的页面都可以进 Top Stories，不再看格式。

需要说明的是，网上关于具体时间点的说法有点乱，有的写 2020 年 5 月，有的写 2021 年页面体验更新。这不是什么关键点，记住「2020 到 2021 这段时间里特权被逐步取消」就够了。项目本身还在维护，文档和验证器都还在跑，只是它不再是排名因素，也不再是任何搜索功能的入场券。

第一条：依附于某个格式的红利，寿命都不长

AMP 的红利是谷歌主动给的，也能被谷歌主动收回去。对一个站点来说，把流量押在某个格式、某个入口、某个平台的临时规则上，本质上是在替别人承担风险。目录站也一样，这几年见过太多「某个渠道突然给量，半年后又突然没了」的故事。

这条经验的实际用法是：做任何优化之前先问一句，这个东西是建立在稳定机制上，还是建立在某家的临时政策上。稳定的机制是页面速度、内容质量、结构清晰、能被稳定抓取；临时的政策是某个特定标签、某个特定格式、某个特定入口的专属展现。前者的投入可以累积，后者的投入随时归零。

第二条：AMP 之所以快，是因为它禁掉了自定义 JS

这一点常被忽略。AMP 快不是因为框架本身有什么魔法，而是它的规则不允许你自己写 JavaScript，只能用官方批准的那几个组件。真正拖慢页面的从来不是 HTML 结构，是页面上挂的那几十个第三方脚本：统计、广告、热力图、客服挂件、A/B 测试。

这条可以直接搬到目录站上：与其研究怎么把页面塞进某个框架，不如先列一张第三方脚本清单，逐个问「这个能去掉吗，能延后吗，能换成轻量的吗」。AMP 用强制手段做到的事，你得靠自律和流程做到。而且你还有个 AMP 没有的优势：可以按需决定，不必一刀切。

第三条：双版本维护的代价被严重低估

做了 AMP 的站普遍反馈同一个问题：两套模板，两套统计口径，两套出问题的地方。AMP 页要用 canonical 指回主版本，主版本又要用 amphtml 指向 AMP 版，中间任何一环断掉就出怪事。AMP 页被谷歌缓存后，用户看到的是谷歌缓存域名下的地址，品牌感被削弱，统计来源也乱，后来 Cloudflare 推出的 AMP Real URL 这类方案，本质上就是在补这个洞。

目录站同样要警惕「多一套版本」的诱惑：PC 版和移动版分开、静态版和动态版分开、给某个渠道单独做一套落地页。每多一套，就多一份需要单独维护、单独验证、单独排查的东西。能用响应式解决的就用响应式，能用一套模板生成的就不要手搓第二套。

现在该把力气放在哪

把 AMP 那套心思拿去做三件事：把 Core Web Vitals 的三项指标盯住（LCP 2.5 秒、INP 200 毫秒、CLS 0.1，看的是 28 天滚动的 p75 真实用户数据，不是你自己跑一次的实验室分数）；给页面定一个体积和请求数的红线，让每次上线有东西可对照；第三方脚本逐个过审。

如果站里还留着 /amp/ 目录，也不用急着删。确认 canonical 都指向主版本，观察一段时间流量，确认没有损失之后再逐步下线，把 AMP 地址 301 到对应的主版本地址。别一次性全删，万一有入口还在引用，容易留一堆 404。