图片一直是一个内容站点流量最大、却最少被认真治理的一块：文章正文里的配图、封面缩略图、主题自带的图标与背景图，加起来动辄几千张。这些图片多半是在编辑时随手从别处存下来、改个名丢进上传目录，既没有描述（alt）、也没有尺寸约束、更没有统一的命名。它们在页面上「看起来没问题」，但在搜索引擎眼里几乎是透明的。这篇把图片 SEO 拆成可执行的四件事：文件名与 alt 怎么写、尺寸与格式怎么定、懒加载与索引怎么兼顾、以及上线之后怎么做检查。

一、为什么图片 SEO 值得单独做

很多人把图片 SEO 理解成「给 img 加个 alt」，这远远不够。图片至少从三个入口带来流量：

• 图片搜索：Google 图片、Bing 图片、百度图片各有独立的索引与排序逻辑。技术类文章里「某命令的输出截图」「后台界面截图」这类图片，在图片搜索里被点开的概率并不低。
• 网页搜索的富结果：移动端搜索结果里会带缩略图，有合格图片的页面点击率明显更高。
• 页面体验信号：图片是 LCP（最大内容绘制）最常见的元素，也是 CLS（布局偏移）最常见的来源。图片没优化，性能分会直接被拖下去。

反过来说，图片处理不当的代价也很具体：一张 3MB 的 PNG 截图能让首屏从 1 秒变成 4 秒；没有宽高属性的图片会让正文在加载过程中跳一下；文字直接烧进图片里的教程截图，搜索引擎一个字也读不到。

二、文件名：先修命名，再谈 alt

最容易被忽略也最容易修的是文件名。IMG_2034.JPG、微信截图_20260101.png、Snipaste_2026-01-01_10-00-00.png 这类文件名，等于放弃了一次免费的语义信号。

命名规则建议只保留三条：全小写、用连字符分词、包含核心关键词但不堆砌。例如一篇讲 Nginx 日志切割的文章，配图可以叫 nginx-logrotate-config.png；讲数据库慢查询的截图叫 mysql-slow-query-explain.png。中文站要不要用拼音？如果站点已经有稳定的英文 slug 体系（本站就是这么做的），图片名跟着用英文更一致；如果整站都是中文 URL，用中文文件名也能被识别，但要注意 URL 编码之后的可读性和部分旧系统对非 ASCII 文件名的处理问题。

改名的时候有个硬约束：图片一上线就不要再改名。改了名等于换了一个 URL，旧 URL 会 404，历史外链和已收录的图片索引全部失效。如果确实需要改，务必给旧地址加 301。

三、alt：写给人看，也是写给爬虫看的

alt 属性的第一用途是无障碍——图片加载失败或读屏软件朗读时，用户需要知道这张图是什么。第二用途才是 SEO。这两件事并不冲突，因为「准确描述图片内容」本身就是最好的 SEO 写法。

几个常见错误：

• 留空或缺失：alt="" 会被理解为「这是一张装饰性图片，与内容无关」。纯装饰的背景、分隔线确实应该留空，但正文配图留空就是浪费。
• 关键词堆砌：alt="Nginx,Nginx配置,Nginx教程,Nginx优化,服务器" 这种写法不但没有加分，还可能被判定为作弊。alt 是一句话，不是标签列表。
• 写成「图片」「截图」：alt="截图" 提供的信息量接近于零。
• 与正文完全重复：如果图片旁边一段话已经把内容说清楚了，alt 可以简短些，不必把整段粘进去。

合格的写法是一个短语到一句话，比如 alt="Nginx logrotate 配置示例：daily 轮转保留 14 天"。可以这样自检：把图片遮住，只读 alt，读者能不能大致知道这张图在讲什么？能，就合格。

四、尺寸与格式：把「原图直传」这个习惯改掉

绝大多数慢站的图片问题只有一个原因：把相机原图或高清截图直接上传。一张 2560 像素宽的截图放进只能显示 760 像素宽的正文栏，多出来的像素全是浪费的带宽和内存。

推荐的尺寸策略是按用途分档，而不是「一张图全站用」：

• 正文内图：宽 1200 像素足够（高 DPI 屏两倍图也就是 1600），格式优先 WebP；
• 列表缩略图：宽 400 像素，正方形或 16:9 裁剪；
• 封面图：宽 1200 像素、16:9，单独存一份，不要拿正文图临时缩放；
• 图标与 logo：SVG，注意 SVG 里要带 viewBox 和明确的宽高。

格式方面，照片类用 WebP，截图类（尤其是带文字的界面截图）WebP 通常也比 PNG 小很多，但如果你需要绝对无损，PNG 优化工具（pngquant 的有损量化、oxipng 的无损重压）能把体积压掉 60% 以上而肉眼无差。截图里的文字最怕过度压缩产生毛边，所以截图压缩建议只用无损或高质量有损，并放大到 200% 检查一遍文字边缘。

五、宽高属性与布局偏移

浏览器在拿到图片之前不知道它要占多大位置。没有宽高属性的图片，加载完成后会把下方内容整体推下去，这就是 CLS 的主要来源，也是很多站长在性能报告里看到「布局不稳定」却找不到原因的地方。

正确写法是同时写 width 和 height 两个属性，值写图片的原始像素尺寸，再用 CSS 控制显示尺寸：

<img src="/uploads/nginx-logrotate-config.webp"
     alt="Nginx logrotate 配置示例：daily 轮转保留 14 天"
     width="1200" height="640" loading="lazy" decoding="async">

这里的 1200×640 是原图尺寸，浏览器据此算出宽高比并为图片预留空间。配合 style="max-width:100%;height:auto"，图片会自适应容器宽度，比例保持不变，加载过程中也不会跳动。

六、懒加载：首屏图片千万别懒加载

loading="lazy" 让浏览器跳过视口外的图片，能显著减少首屏请求数。但有一个极易犯的错：给首屏第一张大图（通常是封面或文章头图）也加上 lazy。这张图恰恰是 LCP 元素，加上懒加载会让浏览器推迟发起请求，LCP 时间直接变差。

实用的分档规则：

• 首屏唯一的大图：loading="eager"，并加 fetchpriority="high"；
• 首屏以下的所有图片：loading="lazy"；
• 图片较多时再加 decoding="async"，避免图片解码阻塞主线程。

还有一个例外：如果你用 CSS 的 background-image 放图片（本站主题的列表缩略图就是这么做的），loading="lazy" 完全不起作用，因为浏览器只对 <img> 和 <iframe> 支持懒加载。这类图片要么改成 <img>，要么接受它们会被提前加载，要么用 IntersectionObserver 自己实现。

七、让图片真正被索引

图片能被收录的前提是：爬虫能抓取到这张图的 URL、能读懂页面与图片的关系、并且没有在 robots 里把图片目录屏蔽掉。

第一件事是检查 robots.txt。很多人为了「减少抓取压力」写了 Disallow: /uploads/，结果是正文一切正常，但图片全部无法收录。图片目录应当允许抓取。

第二件事是图片不要被样式隐藏。用 display:none 藏起来的图片不会被索引，前端为了响应式做的「桌面版一张、移动版一张、用 CSS 切换」的结构，会让其中一张永远没有机会被看到。正确的做法是用 <picture> 配合 srcset，让浏览器自己挑，而不是藏起来。

第三件事是给页面配好结构化数据里的图片字段。文章类页面的 Article schema 中 image 字段指向封面图，这是进入富结果和 Discover 类信息流的基础。注意：这个字段不要填一张带文字的营销图，填真实的内容相关图片更好。

第四件事是给图片单独做站点地图。Typecho、WordPress 这类系统默认的 sitemap 一般只包含文章页，图片 URL 不会单独出现。如果你的站点图片量大，可以额外生成一个图片 sitemap，用 image:image 命名空间列出图片 URL 与标题。这不是必须的，但成本很低。

八、上线后的检查：三条命令

图片 SEO 的检查不需要任何付费工具，三条命令就够用。

第一条，列出全站正文里所有图片，看有多少缺 alt：

grep -ohE '<img[^>]*>' /var/www/site/*.html | grep -v 'alt=' | wc -l

第二条，找出体积过大的图片，按大小排序取前 20 个：

find /var/www/site/uploads -type f \( -iname '*.png' -o -iname '*.jpg' -o -iname '*.webp' \) -size +300k -printf '%s %p\n' | sort -rn | head -20

第三条，用 curl 看页面里图片的实际响应头，确认有没有走缓存、有没有正确的 Content-Type：

curl -sI https://example.com/uploads/nginx-logrotate-config.webp | grep -iE 'content-type|content-length|cache-control|etag'

三条命令跑完，问题清单基本就出来了：缺 alt 的批量补、超大的批量压、缓存头不正确的在 Nginx 里补一段 expires 与 add_header Cache-Control。

九、批量化：写好脚本再动手

几百张图不要手工改。批量任务分两类：改 HTML 里的 <img> 标签，和改图片文件本身。

改标签要非常小心，因为正则很容易把不该动的地方改坏。稳妥的顺序是：先把数据库或模板文件备份成一个独立文件，用脚本只处理 <img ...> 这一种模式，跑完之后 diff 抽查十处，再决定是否上线。改完不要立刻删除备份，留一个星期。

改文件本身则建议分两步：先跑一遍干跑（dry-run），把「原大小 → 预计大小」打印出来人工扫一眼，再真正执行。所有压缩操作都要保留原图目录，压缩只是生成新文件覆盖副本，而不是直接 rm 原件。

最后一点经验：图片优化是一次性工程，但图片规范是长期工程。真正省事的是把规则写进发文流程——编辑上传前必须压缩到 300KB 以下、必须重命名为英文短名、必须在编辑器里填 alt。流程不改，三个月后上传目录又会变成一锅粥。

十、小结

图片 SEO 没有黑科技，全部是可执行的小事叠在一起：有意义的小写文件名、一句话说清内容的 alt、按用途分档的尺寸、WebP 与无损压缩、宽高属性防跳动、首屏不懒加载、robots 不误伤 uploads、能批处理就别手工。这七件事做完，图片从「页面的负担」变成「流量的入口」，顺带性能分也会涨一截。下一步可以做的事是建立一个月度检查：把上面三条命令写进 cron，每周把结果发到自己邮箱，问题就不会累积。