一页图片的alt与属性怎么批量体检，从缺alt查到布局偏移风险

摘要：图片alt与属性批量检查把整页的img标签拉出来逐个体检，alt写法、宽高属性、懒加载、响应式一次看完，比在浏览器里逐个右键查看源码快得多。我们构造了一组探针HTML喂给它的后端，再用它自己的判定代码跑了一遍，四处解析口径需要你知道。

最需要警惕的一条是缺alt漏检：只写了data-alt而没写alt的图片，工具会把data-alt的值当成alt读出来，报告里显示有alt，顶部那个缺alt计数一点不涨。同理，懒加载站上data-src写在src前面时，它报告的地址不是浏览器真正加载的那一张。

另外两条是误报：alt文本里出现大于号会让标签提前截断，alt被腰斩的同时明明写了的宽高也被报成缺失；页面里出现两个一模一样的img标签时，后面那个哪怕在文档最末尾，也会跟着第一个一起被判成首屏图。这篇把每一条的复现方式、影响范围和绕法讲清楚。

图片这块有意思的地方在于，它同时踩在三条线上：alt是无障碍的刚需，也是图片搜索理解内容的主要依据；宽高属性直接影响布局偏移；懒加载和响应式影响加载速度和流量。这几件事单拎出来都不难，难在批量发布内容时它们特别容易被漏掉，而且漏了之后没有任何报错。

保哥笔记的图片alt与属性批量检查做的就是把这些散落在每个img标签里的属性一次性拉出来对照着看。这篇教程会先说清楚它查的每一项到底意味着什么，再把它的解析口径逐条拆开——因为工具给出的结论，准确度取决于它有没有正确读到那个属性。

alt到底影响什么，不影响什么？

先把预期校准了，后面的功夫才不会白花。

alt确实决定图片能不能进图片搜索。搜索引擎理解一张图讲的是什么，主要依据三样东西：alt文本、图片周围的正文、文件名。对图片流量占比高的类目——服装、家居、旅游、美食、设计素材——图片搜索是实打实的入口。

alt是无障碍的刚需。读屏软件遇到图片时念的就是alt。这一条不是锦上添花，是很多用户能不能用你的站的分界线。

但alt对网页本身的排名帮不上什么忙。把关键词塞进alt里期待网页排名上升，是个流传很久的误解，站内有一篇专门拆过这件事的图片alt与排名因素的关系可以对照着看。堆关键词既帮不上网页排名，又损害真实用户的体验，还可能被判成过度优化，属于纯亏。

把这三条摆清楚之后，正确的写法就自然浮出来了：把alt当成“图片加载失败时，读到这句话的人能不能想象出图里是什么”来写。能，就是合格的alt；不能，再多关键词也没用。

没有alt属性和空alt，差别有多大？

这是最容易搞混的一点，也是工具专门分开统计的一项。

alt=""是一个有明确含义的写法：告诉读屏软件这是纯装饰图，跳过就好，别念。分隔线、圆角装饰、背景纹理，都该这么写。

而完全没有alt属性，含义是“未知”。读屏软件不知道该怎么办，多数实现会退而念出文件名——用户听到的就是一串编号和后缀，体验相当糟糕。

所以规则是两句话：装饰性的图写空alt，内容性的图写描述，但绝不要没有alt属性。W3C的图片决策树把这套判断做成了流程图，遇到拿不准的图片类型，照着走一遍就有答案。

工具会把这两种情况分开标注，缺alt属性标红，空alt标为提示。如果空alt的图同时带了表示装饰用途的role或者aria属性，它还会给一个绿色的“已正确标记”，这个细节做得挺到位。

它是怎么把这些图解析出来的？

理解口径要从这一步开始。工具的后端拿到HTML之后做了三件事：先把脚本和样式块整段挖掉，避免抓到代码里的字符串；然后用正则把所有img标签匹配出来；最后逐个标签用正则提取属性。

属性提取的方式是按名字去匹配，先找双引号包裹的值，找不到再找单引号，还找不到就取到空白或者标签结束为止。这个策略覆盖了大部分写法，但它有一个副作用——匹配名字时用的是单词边界，而连字符在正则里算非单词字符。

这一句技术细节，就是后面两个坑的共同根源。

属性名带横杠，为什么会被读串？

工具提取属性用的是按名字匹配的正则，而正则里的单词边界会把连字符当成边界。这一句技术细节，直接造出了两处口径偏差，而且都发生在最关键的两个属性上。

为什么有data-alt的图会被当成“有alt”？

我们的探针里放了这么一张图：

<img src="/b/one.jpg" data-alt="装饰图">

它没有alt属性，只有一个自定义的data-alt。按HTML规范，这张图属于缺alt，读屏软件会念文件名，工具也应该把它标红。

实际返回是：alt的值等于装饰图。用工具自己的判定代码跑一遍，这张图的结论是没有缺alt的旗标，顶部那个“缺alt属性”的计数也不会加一。

原因就是上一节说的单词边界。匹配alt这个名字时，data-alt里的横杠被当成了边界，于是data-alt被认成了alt。

什么样的站会中招？比通常想象的多。用懒加载库的站经常把真实alt存在自定义属性里，等脚本执行时再写回去；一些图片管理插件会同时输出alt和data-alt做兼容；还有些多语言插件用data属性存翻译版本。这些站在工具里看起来alt齐全，实际上服务器返回的原始HTML里根本没有alt——而搜索引擎首轮抓取看到的正是那份原始HTML。

怎么绕：看报告里alt那一栏的同时，用浏览器查看页面源代码，直接搜alt这个词，确认它前面没有横杠。如果你的站用了懒加载库，这一步不能省。

懒加载站测出来的地址，是浏览器真正加载的那张吗？

同一个根源，另一种表现，而且这一次影响的是格式判定。

探针里的第二张图是这样的：

<img data-src="/c/real-photo.webp" src="/c/placeholder.gif" alt="客户现场照">

这是懒加载的经典写法：src先放一个极小的占位图，真实地址存在data-src里，滚动到视口时脚本再替换。

工具返回的src是/c/real-photo.webp——data-src的那个值。因为它匹配src时，data-src先出现在标签里就先被匹配上了。

连带的后果是格式判定跟着判反。这张图在浏览器首屏加载的其实是gif占位图，工具却按webp来看，于是“传统格式建议转WebP”这条提示没有触发。反过来，如果你的占位图是webp而真实图是jpg，它又会给出一条不必要的提示。

这里其实有个更有意思的取舍。工具的设计意图是好的——它在src找不到时会去读data-src，为的是照顾懒加载站。问题只出在两个属性同时存在时的优先级上。

怎么绕：懒加载站看这一栏时，把报告里的地址和页面源码里的src对一眼。要判断真实的图片格式和体积，用浏览器开发者工具的网络面板更直接，那里显示的是实际发出的请求。

标签被切断和位置被误判，会连累哪些结论？

上一处偏差出在读属性，这两处出在更早的一步——怎么把img标签从HTML里切出来，以及怎么判断它在页面的什么位置。切错了位置，后面每一项判定都跟着错。

alt里写了大于号，会发生什么？

这一条是纯粹的解析事故，而且是双重的。

探针里这张图，属性写得完全合规：

<img src="/d/chart.png" alt="销量 > 1000 件的国家" width="600" height="400">

按HTML规范，引号里的大于号是普通字符，浏览器解析毫无问题。但工具匹配img标签用的正则是“从img开始，一路吃到第一个大于号”，于是这个标签在alt值中间就被切断了。

返回结果有两处错：

• alt被腰斩，值变成了一个残缺的片段，还带着一个多余的引号。判定代码拿着这个残片去做长度和堆砌检查，结果自然也没意义。
• width和height落在截断点之后，工具读不到，于是这张明明写了600乘400的图，被报成“缺width/height”。

第二条尤其讨厌，因为它会把一个不存在的问题摆在你面前，你去源码里一看又明明写了，来回折腾。

什么内容容易踩？做数据类、评测类、教程类内容的最容易——alt里写“某某大于某某”、“步骤一到步骤三”、代码截图的说明文字，都可能带上尖括号。做外贸的写英文alt时，尺码对比、参数区间也常用大于号。

怎么绕：alt文本里避免直接写尖括号，改用文字表述或者写成HTML实体。这本来也是更稳妥的写法——alt会被各种解析器读取，少用特殊字符总没坏处。

同一张图出现两次，为什么都被判成首屏？

这一条影响的是懒加载相关的判定，也是最容易造成误报的一条。

工具判断一张图是不是在首屏，用的是它在HTML源码里的字节位置：位于前四分之一的算首屏候选。这个方法本身就粗，工具自己也说明了是粗略估算。但它的实现里还有一个更硬的问题：定位的方式是拿标签文本去整份HTML里查找第一次出现的位置。

后果是，只要页面里有两个完全一样的img标签，第二个、第三个都会继承第一个的位置。

我们的验证很直接：同一个带懒加载属性的img标签，一个放在文档开头，一个放在结尾，中间隔了几千字节。返回结果里两张图的首屏标记都是真，判定代码给出的结论也一模一样——两张都报了红色的“首屏图用了lazy，会拖慢LCP”。而实际上第二张在页面最底部，用懒加载完全正确。

什么页面会有重复的img标签？商品列表里统一的占位图、评分星星、图标、“新品”角标、作者头像出现在每条评论旁边——都是完全相同的标签重复几十次。这类页面跑一遍，红色警告会哗哗地冒，全是假的。

怎么绕：看到“首屏图用了lazy”这条红色提示时，先确认这张图在页面上是不是唯一的。重复出现的图标类元素，这条提示可以直接忽略。真正要认真对待的是那些独一份的主图、banner、封面图。

质量判定这两栏，口径有多宽？

解析口径说完，再看判定口径。alt写得像不像堆砌、文件名有没有描述性，这两项工具都给了结论，但它们背后的规则都比你以为的窄，中英文的表现也不一样。

关键词堆砌它认得出来吗？

认得出一部分，口径比你以为的窄。

判定规则是：alt里的逗号数量达到三个以上，同时整段长度小于60个字符，才算堆砌。两个条件是与的关系，缺一不可。我们做了一组对照：

第一行说明规则本身是工作的，后两行说明它的覆盖面有限。顿号漏掉是因为判定只认半角和全角的逗号；英文那条漏掉是因为词组一长就超过了60字符的上限，而英文本来就比中文占字符。

做外贸站的要特别注意第三行——英文alt堆砌几乎必然超过60字符，也就是说这条检查对英文站基本不起作用。

还有一个相关的口径：过长判定用的是125个字符。这个数字来源于部分读屏软件的朗读断句习惯，是个流传很广的经验值。但它按字符计数，中文一个字算一个字符，125个汉字是相当长的一段话了，实际上早就该拆成图注。所以中文站看这一栏时，可以自己把心理阈值降到六七十字。

文件名判定为什么一边漏一边误伤？

工具会标出那些明显是相机或者手机默认命名的文件，思路很好，正则写窄了。

规则是：文件名以某几个前缀开头，后面紧跟至少三位数字。我们测了一组：

• 相机默认命名带四位数字的，正确命中。
• 只带一位数字的照片文件名，漏掉了。而这种命名同样没有任何描述性。
• 直接叫未命名的图片文件，漏掉了。因为它后面根本没有数字，而这恰恰是最典型的无描述文件名。
• 一个正常的年度报告文件，因为文件名开头是字母p紧跟四位年份，被误判成无描述文件名。

最后一条值得注意：以字母p加数字开头的文件名不算罕见，产品编号、页码、年份、型号都可能撞上。

文件名这件事本身是值得做的——把相机默认命名改成描述性的英文短语，是几乎零成本的一次优化，而且改完对图片搜索有实际帮助。只是这一栏的提示要当参考，别当判决：没被标出来不代表文件名就合格，被标出来也可能是误伤。

性能相关的两栏该怎么读？

宽高与响应式这两项不影响图片能不能被理解，影响的是加载体验。工具都查了，但一项容易系统性误报，另一项只查到了最表层。

缺宽高的判定，为什么对有些站特别不友好？

宽高属性的价值是明确的：浏览器在图片下载完成之前就能按比例预留出位置，避免内容跳动。累积布局偏移是页面体验的核心指标之一，而图片没写尺寸是造成偏移的头号原因。

工具在这一项上做了个体贴的设计：如果图片的class里包含某些表示“尺寸由CSS完全控制”的类名，它就把缺宽高标记为提示而不是问题。全屏轮播、背景铺满图这类元素确实不会造成偏移，不该跟正文配图一样对待。

问题是那份类名白名单只覆盖了一种命名风格——原子化CSS框架那一套。如果你的站用的是自定义类名，比如按语义命名的横幅、封面、主视觉之类，工具认不出来，会把它们统统报成缺宽高。

反过来也有漏判：用原子化类名的站，某个类名恰好在白名单里但实际会造成偏移的图，会被放过。

实操建议：把这一栏当成待核对清单而不是问题清单。真正判断有没有布局偏移，看实测数据最准——页面体验报告里的偏移分数，以及开发者工具里的布局偏移记录，那才是用户真实遇到的情况。

响应式那一栏，只看有没有srcset够吗？

不够，但工具只查到这一层。

它对响应式的判定是二元的：有srcset就不提示，没有就给一条信息级的提醒。这个判定不会出错，但它遗漏了实际使用中最容易写错的部分。

srcset用宽度描述符列出多个候选图之后，还需要配合sizes属性告诉浏览器这张图在不同视口下实际会显示多大。缺了sizes，浏览器只能按默认值处理，很可能给手机也下发了大图，响应式等于白做。

另外还有几件工具查不到但值得自己过一遍的事：候选图的实际尺寸有没有拉开差距（三张宽度差不多的图列在srcset里没有意义）、有没有为高分屏准备更大的版本、picture元素里的source条件写得对不对。工具对picture只做计数，这一点它诚实地标明了。

格式这一层也值得顺手看看。现代格式在同等观感下能比传统格式小三成左右，批量转换的收益很直接，尤其是图片多的商品页。

粘贴HTML这个模式，什么时候比输网址好用？

工具提供了两种输入方式，多数人只用第一种。第二种其实解决了几类输网址解决不了的场景。

页面还没上线的时候。本地开发环境、测试站、内网预览页，工具的服务器访问不到——它只支持公网地址，内网和保留地址会被直接拒绝。这时候把渲染好的HTML复制粘贴进去，一样能跑完整套检查。上线前发现问题，比上线后再回头改省事得多。

要检查脚本渲染之后的结果。工具抓取时不执行JavaScript，前端框架渲染出来的图片它看不到。绕法是在浏览器里打开页面，等它完全加载好，从开发者工具里复制整个文档的HTML，再粘进来。这份HTML是脚本执行之后的最终状态，能反映用户实际看到的图片——虽然这和搜索引擎首轮抓取看到的不是一回事，但两边都值得各查一遍。

要检查片段而不是整页。只想看某个商品卡片模板输出的图片对不对，把那一段HTML粘进来就行，不用被整页几十张图淹没。做模板开发时这个用法很顺手。

页面需要登录才能访问。会员专区、后台预览、订单页，工具抓不到。粘贴模式绕过了这个限制。

要注意的是粘贴模式下没有页面地址，工具没法把相对路径的图片地址补成绝对地址，缩略图预览会显示不出来。属性判定不受影响，只是看不到图。

图片搜索的流量，到底是怎么进来的？

把alt写好只是其中一环。一张图能从图片搜索带来流量，需要好几个条件同时成立，缺一不可。

承载图片的页面得能被索引。图片搜索的结果点进去是落地页，页面进不了索引，图片自然也不会被展示。这是最容易被忽略的前置条件——很多人盯着图片本身优化了半天，问题其实在页面层。

图片文件本身得能被抓取。如果图片放在被robots规则挡住的目录里，或者放在需要鉴权的存储上，爬虫拿不到文件，也就无从理解。用CDN的站要特别留意，有些CDN的默认规则会拦掉非浏览器请求。

图片得是真正的img元素。用CSS背景图承载的内容图片，搜索引擎基本无从索引——背景图在HTML里没有任何语义，也没有alt可以读。装饰用背景图没问题，但产品主图、教程截图这类内容性图片，必须用img元素。

周边得有相关的文字。alt之外，图片附近的正文、图注、标题都参与理解。一张孤零零放在空白区域的图，能提供的上下文比嵌在相关段落中间的图少得多。

规模大的站可以考虑图片sitemap。商品图、图库这类图片量大的站，单独声明图片能帮助发现。不过要先确认页面本身的收录是健康的，页面都没进索引的时候，图片sitemap起不到什么作用。

这几条串起来看会发现，图片SEO的下限是页面SEO。页面这一层没打好，图片这一层做得再精细也是空中楼阁。

哪些问题应该在模板层一次解决？

逐张图去改是最笨的办法。这份清单里的大部分项目，其实应该在模板和上传流程里根治，改一次就不再复发。

上传时自动写入原始宽高。后台在保存图片时读出真实尺寸并写进标签，这是最省事的一项。存量图片可以写个脚本批量补，读文件头就能拿到尺寸。

首屏图排除懒加载。模板里把封面图、文章首图、商品主图单独处理，不加延迟加载属性，其余的统一加上。这个逻辑一次写好，之后发布的内容都不会踩坑。

alt留空时给出提示。编辑器里加一个校验，图片没填alt就不让保存，或者至少给个醒目的提醒。这比事后批量补有效得多，因为写文章的人当时最清楚那张图讲的是什么。

文件名在上传时规范化。把上传的文件按标题或者关键内容重命名，用短横线连接的小写英文。这一步自动化之后，相机默认命名就再也不会进到站里。

响应式与格式转换交给处理管线。上传后自动生成几个尺寸档位和现代格式版本，模板输出时带上srcset和sizes。这一项工程量最大，但对图片多的站收益也最大。

做完这五项，工具再跑一遍，剩下的问题基本只有一类——alt写得好不好。而那一类恰恰是机器代替不了的，只能靠人写。工具的价值就在于帮你把机器能解决的部分全部筛出来，剩下的时间留给真正需要判断的地方。

这些问题该按什么顺序修？

一次体检下来可能列出几十条，全修一遍不现实，得排优先级。这个顺序是按“修复成本除以收益”排的：

前三项都是“改一次模板就一劳永逸”的类型，应该优先做。第四项最耗人力，建议只针对有图片搜索价值的页面做——商品页、教程页、案例页，其余的先放着。

保哥给一家做手工皮具的独立站排过这个顺序：模板层三件事花了半天，存量图片的alt重写分了三个月慢慢补，先补的是那两百个卖得最好的商品页。半年后图片搜索来的流量涨了一截，而那批一直没顾上的老文章配图，一点变化也没有——这个对比反过来说明了优先级排对的价值。

哪一类站跑出来的报告最不可信？

把前面那几处口径拼起来，能得出一个挺实用的判断：报告的可信度取决于你的站属于哪一类。

最可信的是内容型站点。文章页、教程页、案例页，图片各不相同、地址直接写在src里、模板简单。这类页面工具几乎不会误判，报告可以直接拿去改。

次可信的是用了懒加载库的站。alt和地址两栏都要人工复核一遍，其余各项正常。多花两分钟，结论依然可用。

要打折扣的是商品列表和图库页。大量重复的占位图、图标、角标，会让首屏判定大面积失真，红色警告里多半是假的。这类页面建议改用粘贴模式，把单个商品卡片的HTML片段拿出来单独测。

最不可信的是前端框架渲染的站。抓回来的原始HTML里可能一张图都没有，工具会直接提示没找到img标签。这时候唯一可行的是从浏览器复制渲染后的HTML粘进来——但要记住那份HTML和搜索引擎首轮看到的不是一回事，如果搜索引擎抓的那份里没有图片，那才是真正要解决的问题。

还有一类特殊情况：用CSS类名控制尺寸的站，缺宽高那一栏会有系统性偏差。前面说过白名单只认一种命名风格，自定义类名的站会被大面积误报。这一栏建议整栏当参考，用实测的布局偏移数据来定夺。

规律总结一句：图片越同质、模板越复杂、脚本参与越深，报告的噪声就越大。知道自己在哪一档，就知道该信几分，也知道该把人工核对的力气花在哪一栏。

整页体检的完整清单长什么样？

把上面这些收拢成一份可以照着走的清单，每次发布重要页面之前过一遍。

• 每张图都有alt属性。装饰图写空值，内容图写描述。确认源码里是alt而不是data-alt。
• 描述能替代图片。标准是图加载失败时读到这句话能想象出画面，不是把关键词列一遍。
• 长度克制。中文控制在六七十字以内，说不完的信息放图注，别全塞进alt。
• 首屏主图不带懒加载。首屏以下的图带上。注意分辨工具因重复标签造成的误报。
• 所有图写死原始宽高。即使显示尺寸由CSS控制，属性也该写，浏览器靠它算宽高比。
• 文件名有描述性。用短横线连接的英文短语，别留相机默认命名。
• 响应式配齐。srcset和sizes成对出现，候选尺寸拉开差距。
• 格式跟上。能转现代格式的转，尤其是商品图和封面图。

这份清单里的前三条决定内容能不能被理解，中间三条决定加载体验，最后两条决定流量成本。三类都做完的页面不多，但只要做完前三条，就已经比大多数站强了。

顺带一提，如果你在排查的是“图片不进图片搜索”这类问题，光看alt不够，还得确认页面本身能被抓取和索引——图片再规范，承载它的页面进不了索引也是白搭。这一层可以用可索引性一键体检的六项信号先过一遍。另一种常见情况是图片所在的页面本身没有内链，属于站内孤岛，那就要用孤岛页面检测的抽样口径去看一眼它的入链情况。

常见问题解答

工具说这张图有alt，源码里却找不到，怎么回事？

大概率是标签上写了data-alt。工具匹配属性名时把横杠当成了单词边界，于是data-alt被认成了alt，值被原样读出来。用懒加载库或者多语言插件的站容易出现这种情况。确认方法是在源码里搜alt，看它前面有没有横杠。

为什么报告里的图片地址和浏览器实际加载的不一样？

同样是属性名匹配的问题。当标签上data-src写在src前面时，工具会先匹配到data-src的值。懒加载的经典写法正是src放占位图、data-src放真实地址，所以这类站测出来的地址是真实图而不是占位图，格式判定也会跟着偏。

明明写了width和height，为什么报缺尺寸？

检查一下这张图的alt里有没有大于号。工具匹配img标签时会在第一个大于号处截断，alt里的尖括号会让标签被切成两半，写在后面的宽高属性就读不到了。同一张图的alt通常也会显示成一个残缺片段。

页面底部的图为什么被报成首屏图误用懒加载？

如果页面里有多个完全相同的img标签，工具定位时只找第一次出现的位置，后面那些会继承第一个的位置判定。商品列表的统一占位图、图标、角标最容易触发。看到这条提示先确认这张图在页面上是不是唯一的。

顿号分隔的alt算不算关键词堆砌？

算，但工具认不出来。它的堆砌判定只统计半角和全角逗号，而且要求整段长度小于60个字符。顿号分隔的中文堆砌、以及超过60字符的英文堆砌，都会被判成没有问题。做外贸站的尤其要注意，英文alt堆砌几乎必然超过这个长度上限。

alt写多长合适？

工具的过长阈值是125个字符，这个数字来自部分读屏软件的朗读习惯。但它按字符计数，中文一个字算一个字符，125个汉字实际上已经很长了。中文站可以把心理阈值降到六七十字，说不完的信息用图注承载。

装饰图到底该怎么标？

写空的alt属性，也就是有alt但值为空。这告诉读屏软件跳过这张图。如果同时加上表示装饰用途的role或者aria属性，语义更明确，工具也会给出正确标记的绿色提示。最糟的做法是完全不写alt属性，那等于告诉读屏软件情况未知。

它能判断alt写得准不准吗？

不能。工具只看得到形式问题：空着、太长、像文件名、像关键词列表。alt描述得对不对、跟图片内容对不对得上，需要人来判断。这也是为什么它适合做批量筛查而不是最终验收，筛出来的候选还得自己过一遍。

权威参考资料