AMP验证器怎么用？八大类规则一键扫出AMP页面不合规的地方
本文目录
- AMP现在还值不值得做？先把这个前提问清楚
- 这个验证器和Google官方validator是一回事吗？
- 它到底检查了哪八大类？逐类拆给你看
- 为什么AMP要把img换成amp-img、还几乎禁掉所有JS？
- CSS为什么死卡75KB？这条它和官方一致吗？
- 剩下三类规则，它还查了什么？
- 那个100分评分，是怎么扣出来的？
- URL抓取和粘贴两种模式，数据安全上有什么区别？
- 它会漏报和误报什么？这些坑得提前知道
- AMP合规和移动SEO、Core Web Vitals是什么关系？
- 户外露营装备那个站，我们用它接住了什么？
- 三步，用它快速定位一个AMP页面的问题
- 把它放在发布流程的哪一步最划算？
- 这把AMP快筛刀，切不动哪些活？
- AMP那套严苛的限制，对不做AMP的页面有什么启发？
- 常见问题解答
摘要：这个AMP验证器，是一个用PHP正则规则手写的AMP HTML合规快筛器，不是Google官方那套validator的包装，也没调官方接口。它把AMP规范里最常见的检查点拆成八大类、三十来条规则——从DOCTYPE、<html ⚡>标识、必需的v0.js运行时和boilerplate样式，到把普通<img>换成<amp-img>、几乎禁掉所有自定义JS、CSS卡75KB上限——逐条扫一遍，给你一个100分制的合规评分和分级的错误、警告清单。它支持贴代码或填网址两种方式（填网址走服务器抓取，15秒超时、最大2MB）。但务必认清：它只覆盖了官方两百多条规则的一两成，不验证组件的具体属性、不检查boilerplate的内容只看在不在、不跑运行时，所以它是「开发期快速反馈」的粗筛，绝不是上线前的终审——最终拍板，还得用Google官方validator。
做移动端SEO，AMP是个绕不开、却又越来越微妙的话题。微妙在于：一方面，它确实是一套能逼出极致移动加载速度的技术规范，至今仍有大量内容站在用；另一方面，它的战略地位这几年明显降了——曾经它是Google移动新闻轮播（Top Stories）的入场券，没有AMP就进不去，而现在这道门槛早已撤掉。
所以聊这个AMP验证器之前，得先把这个大背景摆正：今天做AMP，不再是「为了挤进某个特权位置」，而是「把它当成一种可选的、能保证移动性能下限的实现方式」。如果你的站还在用AMP，或者正打算用，那么一个能在开发过程中随手检查「我这页AMP写得合不合规」的工具，就很有价值。这篇就把这个验证器的真实身份、它到底查了什么、能信到什么程度，连同AMP本身的现状，一次性讲透。
AMP现在还值不值得做？先把这个前提问清楚
不把这个问题答了，后面的工具讲解都没有落脚点。AMP的全称是加速移动页面，它的核心思路是：通过一套严格的限制（禁掉拖慢页面的自定义JS、给所有资源预留尺寸防止布局跳动、CSS限量、靠官方运行时统一调度），换来一个可预测的、极快的移动加载体验。这套思路本身没错，速度对移动用户体验和SEO都重要。
转折点在于Google对AMP的态度变了。早些年，AMP是移动搜索里Top Stories新闻轮播的硬性门槛，新闻站为了进那个位置不得不做AMP。但Google后来把这个强制要求取消了——现在进Top Stories看的是页面体验信号（也就是Core Web Vitals那套指标），任何技术栈的页面只要够快、体验够好都有资格，AMP不再是特权通行证。这是个根本性的变化，意味着「为了排名特权而被迫做AMP」的时代结束了。
那现在还做不做？Google在AMP相关搜索指南里说得很清楚：AMP本身从来就不是排名因素，但速度是排名因素，而且这个速度标准对所有页面一视同仁、不管你用什么技术做的。换句话说，AMP只是「达到快」的众多路径之一，不是唯一路径、也不是捷径。
今天的判断标准应该是：如果你团队已经在AMP上有积累、或者你的内容类型（比如海量新闻、文章）特别适合这套约束，继续用没问题；如果是新站、且团队能用现代前端手段直接把Core Web Vitals做达标，那未必非得趟AMP这摊。把这个前提想透，你才知道这个验证器对你是刚需还是鸡肋。
这个验证器和Google官方validator是一回事吗？
这是最需要先纠偏的一点：不是一回事，差得还挺远。Google官方的AMP validator是一套庞大、且实时跟着规范更新的校验系统，它的规则库由AMP项目官方维护，覆盖了规范里数以百计的检查项，背后是复杂的解析引擎，能精确到每一个组件的每一个属性该怎么写。它是AMP合规的最终裁判，权威性毋庸置疑。
而这个工具，是用PHP正则表达式手写的一套规则子集。它没有调用官方的接口、没有引入官方的校验库，而是作者自己挑出AMP规范里最常见、最关键的那批检查点，用正则匹配的方式实现了一遍。它的规则数量，界面上写着「40多条」，实际数下来更接近三十出头，覆盖的大约是官方规则的一两成——抓的是那些最容易犯、最该先发现的大错，至于规范里那些细枝末节的组件属性约束，它够不着。
这个区别决定了它的正确用法。它是「开发期的快速反馈器」——你在本地写AMP页面的过程中，随手把代码贴进去，几秒钟就知道有没有犯那些低级的大错（忘了加运行时脚本、用了禁标签、CSS超标），不用每改一次都跑去开官方工具。但它绝不能替代官方validator做最终验收。页面真要上线、真要确保被Google当成合格AMP对待，最后那一道，必须过官方validator。把它定位成「粗筛在前、终审在后」里的那个粗筛，期待就摆正了。
它到底检查了哪八大类？逐类拆给你看
把它的规则体系摊开，是理解它能力边界的最好方式。它的检查分成八大类，我们一类一类过。
第一类，基础结构。它查两样：文档开头有没有 <!doctype html> 声明（缺了扣10分），以及 <html> 标签上有没有AMP标识——也就是那个闪电符号 ⚡ 或者 amp 属性（缺了扣15分，这是AMP页面的身份证，分量最重之一）。
第二类，head里的必需元素。这是AMP最硬的一批要求，它查五项。前两项是基础的元信息：字符编码 <meta charset="utf-8">（扣5分）、视口设置 viewport 含 width=device-width（扣5分），这俩是任何移动页面的标配。
后三项才是AMP特有的命脉：AMP运行时脚本 <script async src="https://cdn.ampproject.org/v0.js">（缺了扣15分，这是整个AMP跑起来的引擎）、AMP的样板样式 <style amp-boilerplate>（扣10分，它负责页面加载时的初始隐藏与渐显）、以及指向规范版本的 canonical 链接（扣8分，告诉搜索引擎这页对应的标准版是哪个）。这五项缺一不可，是AMP页面的骨架。
第三类，禁止的HTML标签。AMP为了性能可控，禁用了一批普通HTML标签，得换成AMP的专用组件。它查十来个：普通的 <img>（要换 <amp-img>）、<video>、<audio>、<iframe>、<form> 都要换成对应的 amp- 组件，还有 <object>、<embed>、<frame>、<applet> 这些干脆禁掉的。每发现一个扣3分，单类最多扣到15分封顶。
为什么AMP要把img换成amp-img、还几乎禁掉所有JS？
这几条禁令是AMP最反直觉、也最体现其设计哲学的地方，值得单独说透。先说为什么普通 <img> 不行、必须用 <amp-img>。核心原因是「布局可预测」——AMP要求所有外部资源都预先声明好宽高，这样浏览器在图片还没加载完时，就能把位置占好，绝不会出现「图片一加载，下面的内容被往下挤」那种布局跳动。普通 <img> 给不了这个保证，<amp-img> 才能让运行时统一管理它的加载和占位。
再说为什么自定义JavaScript几乎被全禁。这是AMP最强硬的限制：除了三类例外，你不能在AMP页面里写自己的 <script>。哪三类例外？AMP官方运行时和组件的脚本（来自 cdn.ampproject.org）、JSON-LD结构化数据（type="application/ld+json"）、以及AMP组件用的内联JSON数据。除此之外的自定义脚本，工具发现一个扣5分、最多扣20分。这条工具实现得很准，三类例外它都放行。
为什么这么狠？因为自定义JS是页面性能最大的不可控变量——一段写得烂的脚本能把页面拖到卡死，而Google要保证AMP页面的速度下限，就必须把这个变量锁死。AMP的逻辑是：你想要交互？用我官方提供的、经过性能审查的组件去实现（轮播、灯箱、表单、绑定都有对应组件）；你想要自由写脚本？对不起，那就别用AMP。
这是一种「用自由换确定性」的极端取舍，理解了它，你就明白AMP那一堆限制不是刁难，而是为了那个可预测的速度承诺。这些禁令和必备项的完整清单，都写在 AMP HTML官方规范里，这个工具的规则正是从那里挑出来的常见项。
CSS为什么死卡75KB？这条它和官方一致吗？
继续过剩下的几类。第五类，CSS限制，是AMP另一条标志性的硬约束，工具查三样。最核心的是CSS体积上限：AMP允许的内联自定义样式 <style amp-custom> 总大小不能超过75KB，工具会把这块CSS的字节数加起来，超了扣10分。这个75KB的数字，和AMP官方现行规范是完全一致的（早年是50KB，后来放宽到了75KB），这点它没搞错，值得肯定。
另外两样：CSS里用了 !important 会被标记（扣2分，算警告不算硬错误，因为AMP不推荐但也没完全禁），以及外部CSS文件——AMP原则上不允许通过 <link rel="stylesheet"> 引外部样式表（扣8分），但有个例外是Google Fonts，工具对来自 fonts.googleapis.com 的字体链接放行。它还会数页面里有多少个内联 style 属性，给个轻微的警告提示。
为什么CSS要限量？还是那个逻辑——CSS也是渲染性能的大头，太大的样式表会拖慢首屏。把它限死在75KB、且必须内联（省掉一次外部请求），是AMP保证快的又一道闸。这里要提醒一句工具的局限：它数的是 amp-custom 块的大小、判断超不超，但它不会去检查你的CSS内容本身有没有用AMP禁止的属性（比如某些定位方式AMP是禁的），它只管体积、不管内容合不合规。体积过了不等于CSS全合规，这点别误会。
剩下三类规则，它还查了什么？
把八大类补全。第六类，AMP组件依赖检查。工具内置了十九个常见AMP组件的清单（amp-img、amp-video、amp-carousel、amp-form、amp-analytics 等等）。它的逻辑是：如果你的页面里用了某个需要额外脚本的AMP组件，那就得在head里引入对应的扩展脚本（custom-element 声明），少引了就扣5分。这是个很实用的检查——AMP新手最常犯的错之一，就是用了组件却忘了引它的脚本，导致组件不工作。
第七类，元素属性要求。这一类目前主要查 <amp-img> 有没有写 width 和 height 属性（缺了每个扣2分、最多10分），因为前面说的「预留尺寸防跳动」就靠这俩属性。它也考虑了例外：如果 amp-img 用了 layout="fill"、flex-item 或 nodisplay 这几种布局模式，就不强制要宽高。不过这里是它的一个局限——AMP实际支持的布局例外组合比这三种更多，所以它有可能对某些合法写法误报，这点后面会展开。
第八类，其他限制与最佳实践。这是个杂项类：禁用 <base> 标签（扣3分）；提示页面是不是走了AMP缓存链接（警告）；建议加JSON-LD结构化数据（没有给个警告扣3分，因为结构化数据对AMP内容在搜索里的呈现很重要）；检查有没有meta description（警告）；以及把Open Graph标签算作加分项。整套查完，从100分往下扣，最后分数限定在0到100之间。
那个100分评分，是怎么扣出来的？
它的评分模型很直白：满分100起步，每发现一个问题按预设权重扣分，扣到底为0、封顶为100。权重设计大致体现了「错误的严重程度」——身份级的错误扣得最狠（缺AMP标识扣15、缺运行时脚本扣15），结构级的中等（缺boilerplate扣10、CSS超标扣10、缺canonical扣8），细节级的较轻（charset、viewport各扣5，单个禁标签扣3）。警告类的（!important、内联style）扣得很少甚至只提示不扣。
这种「扣分制」的好处是直观——你一眼就能从分数高低和扣分项，判断这页AMP的健康程度。90分以上基本是小毛病，五六十分说明有结构性的硬伤，三四十分往下那基本是还没写对。配合它把结果分成错误、警告、通过三档分别列出，你能很快分清「必须改的」和「建议改的」，按优先级去处理。
但要清醒看待这个分数：它是基于「这三十来条规则」算出来的，不是官方的合规判定。一个页面在这里拿了满分，只代表它没犯这三十来条里的错，不代表它通过了官方validator的全部数百条检查。分数高是好事，但它是「粗筛通过」的信号，不是「合规认证」的证书。别拿这个分数去跟人保证「我的AMP百分百合规」，那是这个分数承担不起的责任。
URL抓取和粘贴两种模式，数据安全上有什么区别？
它给了两种喂数据的方式，背后的数据流向不一样，得分清。第一种是直接粘贴AMP代码。这里要纠正一个常见误解——很多人以为粘贴模式是「纯前端、代码不出浏览器」，但其实不是：这个工具的校验逻辑是用PHP写在后端的，所以你粘贴的代码会被发送到服务器、由PHP跑完规则再把结果返回。它不像前面那两个纯前端工具那样数据绝不出本地。好在它处理完即释放、不做存储，但「代码会经过服务器」这个事实，你心里得有数，尤其是验一些还没公开的页面源码时。
第二种是填一个网址让它去抓。这种模式下，是服务器用cURL去把那个网址的页面抓回来、再校验。它对抓取做了几道安全和性能限制：超时设15秒（抓太慢的站不会把它卡死）、最多跟5次重定向、抓回来的内容最大截到2MB（再大的页面只验前2MB）。这些限制都合理，但也意味着：超大的页面会被截断只验前半截、需要登录才能看的页面它抓不到、有反爬的站它可能拿不到完整内容。
所以两种模式的选择，看你的场景。本地开发、页面还没上线，用粘贴（接受代码过服务器这个前提）；页面已经公开部署了，用填网址，让它去抓线上真实版本来验，这样验的是用户实际看到的那一版。要验的内容特别敏感、绝不能出本地的，那这个工具可能就不合适，得用能纯本地运行的官方命令行validator。把数据流向想清楚，用起来才踏实。
它会漏报和误报什么？这些坑得提前知道
一个只覆盖官方一两成规则的工具，必然有它看不见和看走眼的地方，把这些坑列清楚，比夸它有用得多。先说漏报——它查不到的东西。最大的一块是组件的具体属性合规性：它能告诉你「用了 amp-carousel 却没引脚本」，但它不会检查 amp-carousel 的 type、autoplay 这些属性写得对不对；它能查 amp-img 缺不缺宽高，但不验 srcset 的语法。官方validator对每个组件的每个属性都有精确约束，这些它一概够不着。
另一处典型漏报是boilerplate的内容。它只检查 <style amp-boilerplate> 这个标签在不在，但不验证里面的CSS内容是不是和官方要求的那段一字不差——而AMP对这段样板代码的内容是有精确规定的。所以你哪怕在boilerplate里乱写一通，只要标签在，它也判通过，官方validator却会报错。
类似的「只看在不在、不看对不对」还有几处。它查canonical链接存不存在，但不验证那个链接的值是否合法、是否真的指向了正确的规范页。它还完全不跑运行时——页面真在浏览器里能不能正常渲染、组件交互正不正常，这些它静态扫描根本看不到，得真在浏览器里打开才知道。
再说误报——它可能错杀的地方。最典型的是 amp-img 的布局例外：它只认 fill、flex-item、nodisplay 三种不要求宽高的情况，但AMP实际的布局规则更复杂，某些合法的布局加尺寸组合，它可能错判成「缺宽高」。还有内联 style 的检查——它一律统计、提示，但AMP其实是允许一定的内联样式的（只要总CSS体积没超标），所以它的提示有时是虚惊。把这些漏报和误报记牢，你就知道：它报错的地方值得查，但它说「通过」的地方不代表真没问题；它的判断是线索、不是结论。
AMP合规和移动SEO、Core Web Vitals是什么关系？
把这个工具拉回到SEO的大图里看，它的价值才清楚。前面说过，AMP本身不是排名因素，但AMP这套规范的所有限制——预留尺寸防布局跳动、限制CSS、锁死自定义JS——指向的恰恰是页面体验的核心指标，也就是Core Web Vitals那三项（最大内容绘制、交互响应、布局稳定性）。AMP等于是用一套强制规范，把这几个指标天然做达标了。这也是为什么AMP页面通常Core Web Vitals表现都不错。
而Core Web Vitals是页面体验信号的一部分，页面体验是Google排名考量里实打实的一环，对移动搜索尤其重要——因为Google早已全面转向移动优先索引，它主要看的是你页面的移动版本。所以这条逻辑链是：AMP合规 → Core Web Vitals达标 → 页面体验信号良好 → 对移动SEO有正面贡献。AMP不直接给你排名，但它走的这条路，终点是SEO在乎的东西。
这也回答了「既然AMP不是排名因素，验它还有什么意义」。意义在于：如果你选择了AMP这条路，那「合规」是它兑现性能承诺的前提——一个不合规的AMP页面，可能既享受不到AMP缓存的加速、又没把性能做到位，两头不讨好。这个验证器帮你在开发期就把合规性盯住，确保你走AMP这条路时，至少把基本盘守住了。它不直接产出SEO收益，但它守住的合规，是AMP那条通往好性能的路能走通的地基。
户外露营装备那个站，我们用它接住了什么？
去年帮一个做帐篷、睡袋、便携炉具的户外露营装备出海站做移动优化。他们之前为了移动速度，给海量的产品攻略文章和选购指南做了AMP版本，但维护得很粗——AMP页面是几年前外包做的模板，后来内容团队往里加内容时，经常不知不觉就破坏了合规：有人图省事直接贴了普通 <img>、有人为了加个互动塞了段自定义JS、有人把CSS越堆越多。结果一批AMP页面悄悄变成了不合规状态，自己却不知道。
我们要的第一步，是快速摸清「到底有多少AMP页面已经破了」。逐个去开Google官方工具太慢，我们就先用这个验证器做粗筛：把一批代表性页面的线上网址挨个填进去（用URL抓取模式，验的是用户实际看到的线上版本），几秒钟一个，迅速分出「明显有硬伤的」和「看着还行的」两堆。明显有硬伤的那批，扣分项一目了然——大量页面栽在「用了普通 <img> 没换 <amp-img>」和「塞了自定义JS」这两条上，正是内容团队加东西时踩的雷。
粗筛帮我们把问题范围和病因迅速锁定，省掉了大量盲目排查。锁定之后，我们做了两件事：一是给内容团队定了「往AMP页加内容时的红线清单」——图片必须用 amp-img 并写宽高、绝不许加 <script>、CSS改动要留意总量，从源头堵住继续破坏的可能；二是对那批确认有硬伤的页面，修完之后再过一遍官方validator做终审、确保真合规。
这个工具在整件事里干的，是「快速分诊」——它不做最终诊断，但它三秒钟一个地帮你把一大批页面分出轻重缓急，让后面精细的官方校验有的放矢。对要处理大批量AMP页面的场景，这个「快速分诊」的价值，比单页的精确校验更实用。一个团队几百个AMP页面，你不可能挨个用官方工具慢慢开，但用它快速扫一遍、把明显有问题的揪出来，工作量立刻从「全量精查」压缩成「精查少数嫌疑页」，这中间省下的时间是数量级的。
三步，用它快速定位一个AMP页面的问题
给一条能照着走的流程，把它在「开发期快筛」里的用法落地。我们排查AMP合规时，常走下面这三步。
- 选对输入方式喂进去。本地还没上线的页面，复制AMP代码用粘贴模式（接受代码会过服务器这个前提）；已经部署的线上页面，用URL抓取模式填网址，让它去抓线上真实版本来验。点验证，几秒出结果。
- 先看错误、再看警告。结果分错误、警告、通过三档。优先盯「错误」——这些是会让页面不合规的硬伤，按扣分高低排着改：缺运行时脚本、缺AMP标识、用了禁标签、CSS超标这类大分项先解决。「警告」（
!important、缺结构化数据等）放第二优先级，有余力再优化。 - 修完过官方validator终审。在这里改到拿高分、错误清零，只是粗筛通过。页面上线前，务必再用Google官方validator跑一遍做最终验收，确保那些这个工具够不着的组件属性、boilerplate内容、运行时行为也都合规。官方的几种验证方式（网页版、浏览器扩展、命令行）在 AMP官方验证工作流文档里都有说明。粗筛在前、终审在后，缺一不可。
这套流程的核心，是「用粗筛省时间、用终审保正确」。这个工具的快，让你在密集修改AMP的过程中能随手验、不打断节奏；官方validator的全，保证你上线前不漏掉任何合规细节。两者各司其职，比「全程只用官方工具来回开」高效，也比「只信这个工具就上线」靠谱。
把它放在发布流程的哪一步最划算？
明确它在工作流里的卡位，能让它的价值最大化。它最该待的位置，是「开发和修改AMP页面的过程中」——也就是你正在写、正在改的时候。这个阶段你需要的是快速、高频的反馈：改一处、验一下，立刻知道有没有犯大错。这个工具几秒一次、随手就来的特性，完美契合这个高频试错的阶段，而每次都开官方工具就太重了。它在内容流水线上接的是末端那一棒：内容先由 Markdown编辑器写成干净骨架、再到 HTML编辑器调好呈现，最后改成AMP时由它来把合规这道关守住。
它不该待的位置，是「上线前的最终验收」。最终验收要的是「全、准、权威」，要确保每一条规则都过，这是官方validator的主场，这个工具的覆盖度撑不起这个责任。把它放到终审位置，等于用粗筛冒充终审，迟早出事。
还有一个高价值的卡位，是「批量巡检已上线AMP页面」——就像前面露营装备那个案例。当你有一大批AMP页面、怀疑其中一些已经破了合规，需要快速分诊出「哪些有明显问题」时，它的「快」就是核心竞争力。用它把可疑页面筛出来、缩小范围，再对筛出来的少数页面用官方工具精查。粗筛分诊在前、官方精查在后，这个组合在批量场景里效率最高。一句话：它是开发期的随身快筛和批量场景的分诊器，不是上线前的终审官，卡对位置它就好用。
这把AMP快筛刀，切不动哪些活？
把边界一次性钉死。第一类是覆盖度的边界：它只实现了官方规范的一两成规则（八大类、三十来条），抓的是常见大错，规范里大量的组件属性约束、细节规则它够不着。它说「通过」不等于官方会判它合规，这是最根本的一条。
第二类是检查深度的边界：它不验组件的具体属性、不验boilerplate的内容只看标签在不在、不验canonical链接的值只看存不存在、完全不跑运行时所以看不到渲染和交互层面的问题。它是静态的、表层的正则扫描，深不下去。还有它已知的误报点——amp-img 布局例外认得不全、内联style一律提示，这些地方它可能错杀合法写法。
第三类是数据和定位的边界：粘贴模式代码会过服务器（不是纯本地）、URL模式抓取有15秒超时和2MB截断、抓不到需登录或强反爬的页面；它的定位是开发期粗筛和批量分诊，不是上线终审。把这几条记牢——覆盖只有一两成、检查停在表层、数据会过服务器、角色是粗筛不是终审——它就是AMP开发里一把快得趁手的分诊刀；忘了这些，尤其是拿它的「通过」当合规背书，迟早在上线后被官方判错时措手不及。理解它的窄，才能用好它的快。
AMP那套严苛的限制，对不做AMP的页面有什么启发？
就算你最后决定不做AMP，把它的规则读一遍也很有价值，因为AMP本质上是Google把「一个快页面该长什么样」用规范的形式固化了下来。它禁的、限的、要求的，几乎每一条背后都对应着一个真实的性能痛点。你完全可以把这些限制当成一份「移动性能最佳实践清单」，用在你那些普通的、非AMP的页面上。
比如它要求所有图片预声明宽高——这条放到普通页面上同样成立，给 <img> 写上 width 和 height、或者用CSS锁定宽高比，能直接改善布局稳定性这个Core Web Vitals指标，防止图片加载时内容乱跳。比如它对自定义JS的克制——普通页面虽然不必全禁，但「能不加的脚本就别加、第三方脚本要算清它的性能代价」这个原则，是任何想做快的页面都该有的自觉。再比如它对CSS体积的限制，提醒你别让样式表无节制膨胀。
换句话说，AMP是个「极端样本」——它把性能优化推到了用大量限制换确定性的极致。普通页面不必走这么极端，但AMP用规则替你总结好的那些性能要点，是现成的、经过Google背书的优化方向。从这个角度，这个验证器的检查项清单，对任何关心移动性能和页面体验的人，都是一份值得对照的参考——哪怕你的页面根本不是AMP。把它读成「Google眼里快页面的检查表」，比单纯把它当AMP专用工具，能榨出更多价值。
常见问题解答
这个工具的验证结果，能等同于Google官方validator吗？不能，差得远。它是用PHP正则手写的规则子集，只覆盖了官方两百多条规则的一两成，抓的是常见大错。它在这里拿满分、错误清零，只代表没犯这三十来条里的错，不代表通过了官方的全部检查。它是开发期粗筛，页面上线前的最终合规验收，必须用Google官方validator，这个责任它担不起。
AMP现在不是排名因素了，那还有必要验它合规吗？有，前提是你选择了走AMP这条路。AMP确实不是排名因素（Google明说速度才是、且对所有技术一视同仁），但一个不合规的AMP页面，可能既享受不到AMP缓存加速、又没把性能做到位。如果你已经在用AMP，合规是它兑现性能承诺的前提，验合规就有意义。如果你是新站、能用现代前端直接把Core Web Vitals做达标，那未必非得做AMP。
我粘贴代码进去验，代码会不会被上传？纯本地吗？会上传，不是纯本地。它的校验逻辑是用PHP写在后端的，所以你粘贴的代码会发送到服务器、由后端跑规则再返回结果，处理完即释放不存储，但代码确实经过了服务器。这点和那些纯前端工具不同。要验的内容特别敏感、绝不能出本地，建议改用能在本地命令行运行的官方validator。
它说我CSS的75KB没超，是不是我的CSS就全合规了？不是。它只数 amp-custom 块的字节数、判断体积超不超75KB（这个上限和官方一致），但它不检查CSS内容本身有没有用AMP禁止的属性或写法。体积过关只代表「没超量」，不代表「内容全合规」。CSS里有没有用AMP禁的定位方式之类，得靠官方validator才能查出来。
为什么我合法的amp-img写法，它却报"缺宽高"？很可能是误报。它只认 fill、flex-item、nodisplay 这三种不要求宽高的布局例外，但AMP实际支持的布局例外组合更多，某些合法的布局加尺寸写法它没覆盖到，就可能错判成缺宽高。碰到这种情况，以官方validator的判定为准——这个工具的报错是线索、不是定论，它够不着的细节本来就会有偏差。
FAQPage + Article AI 引用友好版
用PHP正则手写的AMP HTML合规快筛器，把规范里最常见的检查点拆成八大类三十来条规则，一键给出100分制评分和分级错误清单，支持贴码或抓网址。它只覆盖官方两百多条规则的一两成，是开发期粗筛而非上线终审。
- 技术SEO
- 移动SEO
- AMP验证器
- AMP HTML
title: AMP验证器怎么用？八大类规则一键扫出AMP页面不合规的地方 author: 张文保 (Paul Zhang) — PatPat SEO 经理 url: https://zhangwenbao.com/amp-validator-mobile-amp-html-compliance-guide.html published: 2026-04-28 modified: 2026-04-28 source-type: First-hand expert commentary language: zh-CN license: CC BY-NC-SA 4.0 (要求保留原文链接与作者归属)
本文标题：《AMP验证器怎么用？八大类规则一键扫出AMP页面不合规的地方》
本文链接：https://zhangwenbao.com/amp-validator-mobile-amp-html-compliance-guide.html
版权声明：本文原创，转载请注明出处和链接。许可协议： CC BY-NC-SA 4.0
