图片既是页面加载的大头，也是一条独立的搜索流量入口。但大多数站点的图片优化只做到「压缩一下」，剩下的三项——可发现、可理解、格式正确——全都空着。

先给一个常被忽略的结论：图片搜索的流量特点是「量大、转化低、但极便宜」。对教程站和资源站来说，一条「XX 报错怎么解决」的截图，可能在图片搜索里长期稳定带来访问。

第一条线：可发现

图片要被搜索到，前提是搜索引擎能爬到它。

1. 别在 robots.txt 里屏蔽图片目录

Allow: /wp-content/uploads/

这条要明确写在 robots.txt 里。虽然 User-agent: * 默认允许，但如果前面有更宽泛的 Disallow 规则，加上这条 Allow 能确保图片目录不被误伤（Allow 的优先级在同等长度下高于 Disallow）。

2. 图片要走 sitemap 吗

WordPress 原生 sitemap 不包含图片。但对内容站来说，图片通过文章页被发现已经足够，单独建图片 sitemap 的收益有限，除非你有大量以图片为主体的页面（图集、画廊）。

3. 不要把图片放在 JS 里动态插入

如果图片地址是运行时由脚本拼出来的，搜索引擎可能发现不了。<img> 标签写在 HTML 里是最稳妥的方式。

第二条线：可理解（alt 是核心）

alt 属性有两个用途，很多人只知道第一个：

1. 图片加载失败时显示的替代文字（无障碍用途）；
2. 告诉搜索引擎这张图是什么（图片搜索的依据）。

alt 的写法公式

alt = 主体 + 动作/状态 + 关键限定（可选）

对照示例：

场景	alt 写法	评价
报错截图	alt="curl 返回 403 的终端截图"	好，主体 + 状态
配置界面	alt="Nginx server 块中配置 301 跳转的示例"	好，含关键限定
同一张图	alt="截图1"	差，无信息
同一张图	alt="SEO 图片 SEO 优化 教程 步骤 最新"	差，关键词堆砌
纯装饰图		好，空 alt 是正确做法

三条规则：

• 纯装饰性图片（分隔线、背景纹理）用 ，不要随便写一句话。空 alt 是明确告诉搜索引擎「这张图没有语义，跳过」。
• alt 长度控制在 15–60 个字符之间，短了没信息，长了像堆砌。
• 不要每张图都塞同一个关键词。同一篇文章里三张图 alt 全是「SEO 优化」，等于什么都没说。

顺手要做的两件事

文件名也参与理解。把 IMG_20260927_143355.jpg 改成 nginx-301-redirect-config.jpg，是零成本的改进。中文文件名会导致 URL 编码成一长串百分号，建议用英文小写加连字符。

图片周围的文字有影响。搜索引擎会参考图片附近的段落文字、图注（<figcaption>）来理解图片。用 <figure> + <figcaption> 包裹重要截图，比裸放 <img> 更有利于理解：

<figure>
  <img src="nginx-301.jpg" width="800" height="420"
       alt="Nginx 配置 HTTP 到 HTTPS 301 跳转的代码片段">
  <figcaption>在 Nginx 中配置 301 永久重定向的最小示例</figcaption>
</figure>

第三条线：加载性能

尺寸：不要用 CSS 缩小大图

最常见的浪费：上传一张 2560px 宽的图，然后用 CSS 显示成 800px。用户要下载 3 倍于实际需要的像素。

正确做法：上传时就按显示尺寸准备，用 srcset 让浏览器自己选。

<img
  src="shot-800.webp"
  srcset="shot-400.webp 400w,
          shot-800.webp 800w,
          shot-1600.webp 1600w"
  sizes="(max-width: 768px) 100vw, 800px"
  width="1600" height="900"
  loading="lazy"
  decoding="async"
  alt="配置示例截图">

注意 width/height 写的是原始宽高比（这里 1600×900），不是显示尺寸。浏览器用这两个值计算宽高比并预留空间，避免布局偏移。

格式：按这个顺序选

格式	典型体积（相对 JPEG）	适用
AVIF	约 40%–60%	照片、复杂截图，首推
WebP	约 65%–75%	兼容性更好，安全选择
JPEG	100%	兼容兜底
PNG	可能更大	需要透明通道时；纯色 UI 截图可转 WebP 无损

用 <picture> 做渐进增强，现代浏览器拿 AVIF，老的拿 JPEG：

<picture>
  <source type="image/avif" srcset="shot.avif">
  <source type="image/webp" srcset="shot.webp">
  <img src="shot.jpg" width="1600" height="900"
       alt="配置示例截图" loading="lazy">
</picture>

懒加载：首屏千万别加

loading="lazy" 能减少首屏请求数，但它绝不能用在首屏图片上。

原因：懒加载的图片要等浏览器计算完布局、判断「即将进入视口」才开始下载。对首屏图片来说，这个判断过程白白推迟了请求，直接拖慢 LCP。

规则很简单：

• 首屏第一张图（通常是文章特色图）→ 不加 lazy，加 fetchpriority="high"
• 首屏之外的所有图片 → 加 loading="lazy"
• 所有图片 → 都加 decoding="async"

批量处理：WordPress 环境下的落地方案

手工改每一张历史图片不现实，用命令行批处理：

# 1. 批量转 WebP（需要 cwebp，来自 libwebp 工具包）
find wp-content/uploads -name "*.jpg" -o -name "*.png" | while read f; do
  cwebp -q 82 "$f" -o "${f%.*}.webp"
done

# 2. 批量转 AVIF（需要 avifenc）
find wp-content/uploads -name "*.jpg" | while read f; do
  avifenc -q 55 "$f" "${f%.*}.avif"
done

转换完成后，有两种接入方式：

• 服务器层自动处理：Nginx 依赖 Accept 请求头做内容协商，或在 CDN 层开启「自动格式转换」。这是最省事的做法，历史图片也能立刻受益。
• 模板层输出 <picture>：在主题的图片输出钩子里替换标签结构，控制更细，但要改代码。

# Nginx 内容协商示例
map $http_accept $webp_suffix {
    default   "";
    "~*webp"  ".webp";
}
location ~* \.(png|jpe?g)$ {
    add_header Vary Accept;
    try_files $uri$webp_suffix $uri =404;
}

图片优化的验收清单

1. robots.txt 里有 Allow: /wp-content/uploads/；
2. 每张有语义的图片都有描述性 alt，装饰图用 ；
3. 文件名是英文语义化，不是相机默认名；
4. 重要截图用 <figure> + <figcaption>；
5. 所有 <img> 都有 width / height；
6. 首屏图无 lazy，且带 fetchpriority="high"；
7. 有 WebP 或 AVIF 版本并正确输出；
8. 图片实际文件尺寸不超过显示尺寸的 2 倍。

第 2 项和第 5 项投入产出比最高，也最容易被跳过。

常见问题

alt 和 title 属性都要写吗？

优先写 alt。title 在搜索引擎中的权重很低，且会让鼠标悬停出现提示框，体验一般。两者同时写且内容一致时，部分读屏软件会重复朗读，反而有害。

图片加了懒加载，为什么还是被收录了？

因为图片地址仍在 HTML 的 src 里。懒加载影响的是「什么时候下载」，不影响「地址是否可被发现」。真正会导致发现不了的是用 JS 动态插入 src。

教程截图应该用 PNG 还是 JPEG？

截图通常是「大块纯色 + 少量文字」，PNG 或 WebP 无损模式效果更好、体积更小。但如果截图里包含大片渐变或照片内容，JPEG 反而更小。简单判断：文件里颜色种类少就用 PNG，颜色丰富就用 JPEG 或 AVIF。