图片 SEO 与替代文字：优化完整工作流程

说明性示例：咖啡机页面将大图用作 CSS 背景，文件名不明确，附近也缺少型号说明。请检查图片分发、无障碍替代信息和上下文；仅靠 robots.txt 无法诊断这些问题。

图片 SEO 不是发布后在 alt 字段填入关键词，而是涵盖选择、命名、导出尺寸、附近文案、HTML 嵌入、CDN 分发、元数据和站点地图的一连串决策。良好链路改善图片发现，同时保护页面速度和无障碍。

Google 通过多种信号理解图片

替代文字重要，但不会单独发挥作用。搜索系统可以考虑：

• 落地页内容和各级标题。
• 附近段落、说明和标题。
• 图片文件名和 URL。
• alt 属性。
• 结构化数据和 Open Graph 元数据。
• 指向图片或落地页的链接。
• 对文件应用计算机视觉。

“咖啡馆柜台上的 X200 咖啡机”图片，应放在真正讨论 X200 的页面，靠近其设计或使用方式的文案。将它放进缺少上下文的图库，再写很长 alt 属性，无法获得同样清晰度。

使用抓取工具能发现的 HTML 元素

Google 搜索中心建议使用 <img> 元素嵌入内容图片，并在 src 中提供 URL。CSS 背景适合装饰，却不适合希望在 Google 图片中被发现的图片。

基础示例：

<img
  src="/images/x200-black-coffee-machine.webp"
  alt="Black X200 coffee machine beside a burr grinder"
  width="1200"
  height="800"
>

响应式实现可使用 srcset、sizes 或 <picture>，同时保留有效 img src 作为核心元素。检查源码和渲染后 HTML，确保 URL 不是仅在抓取工具不太可能执行的交互后才加入。

纯装饰可以留在 CSS。没有理由只因为纹理、背景图标和分隔线是图形文件，就全部提交到图片站点地图。

按图片用途撰写替代文字

替代文字帮助看不到图片的人理解其贡献的信息或功能。一个公式无法涵盖所有类型。

信息图片

描述理解周围章节所必需的信息：

alt="Chart showing organic clicks rising from 1,200 to 1,850 in three months"

相邻段落已说明所有数值时，替代文字可以更短，避免屏幕阅读器用户听两遍相同数据。

产品图片

说明产品和有用视角或变体：

alt="Side view of blue AirFlow running shoe with white rubber sole"

不要每张照片都重复“购买便宜正品跑鞋”。正面、背面、鞋底和材质细节图需要不同描述，因为提供的信息不同。

功能图片

图片是按钮或链接时，描述动作或目标：

<a href="/cart">
  <img src="/icons/cart.svg" alt="Open shopping cart">
</a>

装饰图片

使用 alt=""，让辅助技术跳过：

<img src="/decor/divider.png" alt="">

缺少 alt 属性和有意留空，在无障碍方面并不相同。空值明确表示图片不承载信息。

包含文字的图片

尽可能把重要文字放进真实 HTML。图片中的文字难以调整大小、翻译、访问和更新。标志是常见例外；其 alt 通常标明组织，或标志返回首页时的链接功能。

看似优化却失败的替代文字

常见问题包括：

• 列出图片中不存在的关键词和地点。
• 每张产品图都用相同描述。
• 上下文明确，却全部以“……的图片”开头。
• 写 200 字段落，而非使用说明和正文。
• 自动把未经清理的文件名复制为 alt。
• 让视觉模型识别物体，却不考虑图片在文章中的角色。

模型可能识别“白板旁的人”，但编辑知道它是在展示审核流程，还是介绍会议演讲者。有用 alt 结合可见信息和上下文用途。

文件名与 URL 结构

x200-black-coffee-machine.webp 比 DSC00991.webp 提供更多轻微信号，也更易管理。实用规则：

1. 名称简短但可区分。
2. 使用真实描述，而非关键词列表。
3. 一致地用连字符分隔单词。
4. 保留匹配格式的扩展名。
5. 内容未变时，不要每次部署都改变图片 URL。

管理数千资源时，可从产品 ID、变体和拍摄角度派生命名：x200-black-front.webp、x200-black-side.webp。一致规则帮助 DAM、CDN 和内容团队防止重复。

本地化图片含翻译文字或市场专属信息时，本地化文件名可能合理。同一张无语言图片跨语言共享时，一个稳定 URL 能改善缓存；每页仍可翻译 alt 和说明。

有意识地选择格式与压缩

没有格式能胜任所有用途：

• **JPEG：**支持广泛，照片效果好，但不支持实用的 alpha 透明。
• **PNG：**适合透明和清晰细节，照片往往较大。
• **WebP：**适合许多图片类型，现代浏览器广泛支持。
• **AVIF：**相近视觉质量下可生成更小文件，但须考虑编码时间和后备流程。
• **SVG：**适合标志、图标和矢量图；接受用户上传时应净化处理。

按接近实际显示的尺寸导出。600 像素区域不需要 5,000 像素源图。但仍应为高清屏幕提供更高密度变体。在媒体流水线生成多个尺寸，而非让浏览器下载原图后缩小。

压缩不应模糊产品边缘、文字或买家需要的细节。应在多个显示设备上目视检查样例，而不只根据节省百分比批准。

响应式图片不只是减少文件大小

srcset 让浏览器根据视口和像素密度选择资源：

<img
  src="/images/audit-dashboard-800.webp"
  srcset="/images/audit-dashboard-480.webp 480w,
          /images/audit-dashboard-800.webp 800w,
          /images/audit-dashboard-1280.webp 1280w"
  sizes="(max-width: 720px) 100vw, 720px"
  alt="Dashboard listing SEO issues by priority"
  width="1280"
  height="800"
>

错误的 sizes 值可能使浏览器选择过大文件。检查移动端和桌面端 Network 面板，了解真正加载的资源，而非只确认存在 srcset。

每个内容变体使用稳定 URL。不断变化的查询版本可能削弱缓存，并在日志中制造多个图片地址。

Width、height 与 CLS

width 和 height 让浏览器在下载前计算宽高比。CSS 可保持图片响应式：

img {
  max-width: 100%;
  height: auto;
}

不预留空间，文件到达时下方内容会移动，增加 Cumulative Layout Shift。对裁剪容器，定义稳定 aspect-ratio 和合适 object-fit。

Core Web Vitals 优化指南解释首图如何影响 LCP，以及不稳定尺寸如何影响 CLS。

在正确位置使用懒加载

原生懒加载可延后视口下方图片：

<img src="/images/step-8.webp" alt="..." loading="lazy">

不要随意延迟首图或可能成为 LCP 的图片。让浏览器尽早发现关键资源，适当时考虑 fetchpriority="high"，不要把 URL 隐藏在 JavaScript 后。

实用策略：

• 立即加载可能成为 LCP 的主图。
• 懒加载图库和远在下方的媒体。
• 不要只为懒加载全部内容而添加沉重脚本。
• 预留正确占位比例。
• 在慢速网络和真实设备测试。

更改媒体流水线后，用页面速度检查器测量 LCP、CLS 和传输的图片字节。

说明文字与周围文案

不是每张图片都需要说明。读者需要来源、结果、日期、人物、条件或应注意细节时再添加。图表说明可表明数据范围；前后对比应标明条件。

把图片放在相关讨论附近。六步流程信息图若距离标题三屏，上下文就弱，也会打断阅读。

图片包含重要数据时，在 HTML 中概述结论。无障碍和 SEO 都不应完全依赖像素。

特色图片、Open Graph 和结构化数据

搜索和社交分享缩略图由多个信号自动选择。网站可通过以下方式表达偏好：

• og:image。
• Article、Product 或其他合适 schema 类型的 image 属性。
• primaryImageOfPage。
• 正文中显眼的特色图片。

选择相关、高分辨率且宽高比不过分极端的资源。避免每篇都使用通用标志，或在缩略图中小字消失的文字密集图片。使用社交预览检查器检查社交展示。

结构化数据中的每个图片 URL 都必须可访问。如果 CDN 屏蔽抓取工具、要求 Cookie 或签发会过期的 URL，有效标记也无法让文件变得可获取。

图片站点地图何时有帮助

重要媒体难以在普通 HTML 中发现、由复杂应用加载，或构成网站主要价值时，图片站点地图很有用。可以在现有页面站点地图中添加图片条目，无需完全另建系统。

图片站点地图无法修复：

• 被屏蔽资源。
• 错误响应。
• 与落地页无关的图片。
• 太小或低质量文件。
• 已 noindex 的落地页。

图片位于另一个 CDN 域名时，在 Search Console 验证该域名，以便报告抓取问题。使用协议正确、绝对且稳定的 URL。

CDN、缓存与访问控制

CDN 能降低延迟，但以下情况会造成搜索问题：

• 防盗链屏蔽 Googlebot 或无 referer 请求。
• 签名 URL 几分钟后过期。
• 每次尺寸调整生成不稳定地址。
• 响应带错误 MIME 类型。
• 源站已有文件，缓存却返回 404。
• CDN 的 robots.txt 屏蔽图片目录。

不带 Cookie 测试，并尽可能使用多个用户代理和地区。查看 CDN 日志，确认抓取工具收到 200、准确内容类型和预期字节大小。

不要不考虑后果，就仅为从 JPEG 转到 WebP 重命名整个图库。内容协商，或配合重定向和站点地图修改的受控更新可能可行，但须考虑缓存、图片外链和重新抓取。

按模板审核图片

抽样首页、文章、分类、产品、落地页和本地化模板。逐一提问：

1. 内容图片在 img src 中，还是 CSS 背景？
2. Alt 是否存在、符合用途，并适当变化？
3. 文件名是否描述性，URL 是否稳定？
4. Width 和 height 是否预留空间？
5. 哪张图片是 LCP，是否被延迟？
6. 移动端加载多少图片字节？
7. 说明和附近文案是否提供上下文？
8. 图片 URL 是否返回 200 和正确 MIME 类型？
9. OG 和 schema 中是否表示特色图片？
10. 战略重要图片是否纳入站点地图？

随后按规模排序。一个卡片组件让 20,000 个产品缺 alt，应在模板修复。十张命名不佳的博客图片，可以单独编辑。

SEO 检查器检查页面基础属性，免费 SEO 审核帮助在更改共享组件前发现重复缺陷。

团队交接工作流程

持久的图片 SEO 需要明确归属：

• **摄影/设计：**交付干净原文件、合适裁剪和使用权。
• **内容：**选择资源，撰写符合上下文的替代文字和说明。
• **前端：**实现 HTML 图片、响应式来源、尺寸和加载。
• **后端/DAM：**命名文件、生成变体、保留元数据并维持稳定 URL。
• **DevOps/CDN：**管理缓存、MIME 类型、抓取访问和错误监控。
• **SEO：**定义战略落地页、站点地图规则、测试和衡量。

如果替代文字最后才由不知道资源出现位置的人补上，一致性就会受损。CMS 应支持按使用场景设置 alt，因为同一文件在另一上下文可能需要不同描述。

衡量结果

按页面组跟踪前后：

• Search Console 中图片搜索类型的点击和展示。
• 从 Google 图片进入落地页的访问。
• LCP、CLS 和图片总传输大小。
• 缺 alt 或返回错误的图片比例。
• 战略图片的抓取覆盖。
• 从图片搜索开始的会话转化。

不要期待今天编辑 alt，明天流量就变化。图片必须重新抓取和处理。结果也取决于查询的视觉属性；即使实现毫无缺陷，法律文章的图片流量也可能少于食谱。

结论

有效图片 SEO 始于有用资源，将其放在相关页面，通过可抓取 HTML 分发。替代文字解释角色；文件名、说明、元数据和站点地图增加上下文；响应式尺寸、压缩和加载保护快速稳定体验。

不要把 alt 变成关键词容器，不要向小屏幕发送巨型原图，也不要把主要内容图片隐藏为 CSS 背景。当内容、前端和 CDN 团队共享一套流程，图片就能被发现，而不牺牲无障碍或 Core Web Vitals。

参考资料：Google 搜索中心图片 SEO 最佳实践、web.dev 响应式图片指南和W3C 图片无障碍教程。