图像 SEO 完全指南 - 通过 Alt 文本、文件名和尺寸优化提升搜索流量

为什么图像 SEO 重要 - 获取 Google 图片搜索流量

Google 图片搜索占全部搜索流量的 20% 以上。优化图像 SEO 可以从这个巨大的流量池中获取访客，同时改善页面整体的搜索排名。

图像 SEO 的价值:

• Google 图片搜索是第二大搜索引擎
• 图像结果出现在通用搜索结果中 (图像包)
• 优化的图像改善页面加载速度，间接提升排名
• 图像 alt 文本为页面提供额外的关键词信号

Google 如何理解图像: Google 通过 alt 文本、周围文本、文件名、页面标题和结构化数据来理解图像内容。虽然 Google 有图像识别能力，但文本信号仍然是最重要的排名因素。

图片搜索的流量规模：Google 图片搜索是继 Web 搜索之后的第 2 大搜索引擎。据 Sparktoro 的调查，Google 上约 20% 的搜索是以图片搜索进行的；在电商站点、菜谱站点、旅游站点、设计相关站点上，来自图片搜索的流量有时会占到整体的 30-50%。

Alt 属性的最佳写法 - 平衡搜索引擎与无障碍

alt 属性同时服务于 SEO 和无障碍访问，需要在两者之间找到平衡。

写作原则:

• 描述图像内容，而非图像的功能或装饰性质
• 包含相关关键词，但不堆砌
• 简洁明了，通常 5-15 个词
• 不以"图片是"或"这是一张"开头

示例:

• ❌ alt="图片" - 无信息量
• ❌ alt="WebP 格式 图像压缩 Web 优化 性能 速度" - 关键词堆砌
• ✅ alt="WebP 格式与 JPEG 的文件大小对比图表" - 描述性且含关键词

特殊情况:

• 装饰性图像：alt="" (空字符串，非省略)
• 链接图像：alt 描述链接目标而非图像内容
• 图表/信息图：alt 概述关键数据点
• 产品图：包含产品名称、型号、颜色等

长度与用词的界限：关键词的堆砌 (keyword stuffing) 会成为被 Google 处罚的原因。要保持简洁，以 125 字以内为目标 —— 屏幕阅读器会把冗长的 alt 文本一口气读完，累赘的描述反而损害用户体验。也不要包含「图像」「照片」这类词，因为屏幕阅读器已经会先读出「图像：」再读内容。

好例子与坏例子：alt="图像" 没有任何信息；alt="SEO 图像优化 图像 SEO 搜索引擎优化 图像" 是关键词堆砌；alt="Google Search Console 的图片搜索效果报告界面" 具体而自然；alt="WebP 与 JPEG 的画质对比 - 同一压缩率下的视觉差异" 准确传达了内容。装饰用途的图像 (分隔线、背景图案等) 应设置空的 alt (alt="")。

文件名与目录结构 - URL 级别的优化

图像文件名和 URL 路径为搜索引擎提供额外的内容信号。

文件命名规则:

• 使用描述性的英文单词，用连字符分隔：webp-compression-comparison.jpg
• 避免：IMG_20240101.jpg、photo1.png、untitled.webp
• 包含关键词但保持自然
• 全小写，不使用空格或特殊字符

目录结构:

• 按类别组织：/images/tutorials/、/images/products/
• URL 路径也是排名信号：/images/webp-format/comparison-chart.webp

文件大小优化:

• Google 偏好加载快的页面，大图像拖慢速度
• 使用 WebP/AVIF 格式减小文件大小
• 压缩质量 75-85 通常是 SEO 的最佳平衡点

文件名的命名规则：使用能表达内容的英文单词 —— 不要用 IMG_20240315_001.jpg，而要像 golden-retriever-running-park.jpg 这样用能表达图像内容的单词；用连字符分隔单词 —— Google 会把连字符识别为单词的分隔；过长的文件名会让 URL 冗长，分享时也不方便；避免使用日文文件名 —— 会被 URL 编码成 %E7%94%BB%E5%83%8F 这样的字符串，可读性尽失。

目录结构与 URL 变更时的处置：像 /images/products/blue-wireless-headphones.webp 这样让目录结构反映分类，Google 就更容易理解站点的结构，应避免 /img/001.jpg 这类无意义的结构。图像的 URL 发生变更时 (改版等)，要设置 301 重定向，以保持既有的图片搜索排名。

结构化数据与图像站点地图 - 向 Google 明确传达信息

通过结构化数据和图像站点地图，主动向 Google 提供图像的详细信息。

Article 结构化数据中的图像:

{"@type": "Article",
"image": ["https://example.com/photo-1x1.jpg",
"https://example.com/photo-4x3.jpg",
"https://example.com/photo-16x9.jpg"]}

提供多种宽高比的图像，Google 会根据展示位置选择最合适的。

图像站点地图:

<url>
<loc>https://example.com/page</loc>
<image:image>
<image:loc>https://example.com/image.webp</image:loc>
<image:title>描述性标题</image:title>
</image:image>
</url>

注意：图像站点地图帮助 Google 发现通过 JavaScript 加载的图像或 CSS 背景图像，这些可能不会被常规爬取发现。

四类与图像相关的结构化数据：活用结构化数据 (Schema.org) 与图像站点地图，可以把图像的详细信息明确传达给 Google，提高在丰富结果中展示的概率。ImageObject 描述图像自身的元数据 (URL、宽、高、说明文字、版权信息)；Article 的 image 属性 —— 在文章的结构化数据中包含 image 属性，图像更容易出现在 Google Discover 与丰富结果中，推荐宽度为 1,200 px 以上；Product 的 image —— 在商品的结构化数据中包含多个图像 URL，出现在商品轮播中的可能性更高；HowTo 的 image —— 在指南类文章的每个步骤中包含图像，就能在 Google 的指南丰富结果中带图展示。

图像站点地图的写法与适用场合：在 <image:image> 内放入 <image:loc>https://example.com/images/photo.webp</image:loc>、<image:title> 与 <image:caption>。它对于传达由 JavaScript 动态载入的图像、以 CSS 背景图像形式设置的图像等 Google 爬虫在常规抓取中不易发现的图像特别有效；最常见的形式是在通常的 sitemap.xml 中追加 <image:image> 元素。

Core Web Vitals 与图像优化 - LCP 和 CLS 解决方案

图像是影响 Core Web Vitals 的最大因素，优化图像直接改善 LCP 和 CLS 分数。

LCP (Largest Contentful Paint) 优化:

• 首屏大图通常是 LCP 元素
• 使用 <link rel="preload" as="image"> 预加载 LCP 图像
• 不对 LCP 图像使用 loading="lazy"
• 使用 fetchpriority="high" 提升优先级
• 确保图像 URL 在 HTML 中直接可见 (非 JavaScript 动态加载)

CLS (Cumulative Layout Shift) 防止:

• 始终设置 width 和 height 属性
• 使用 CSS aspect-ratio 预留空间
• 避免图像加载后改变容器大小

INP 考虑：大量未优化的图像会占用主线程解码时间，影响交互响应。使用 decoding="async" 让图像解码不阻塞主线程。

LCP 的五项改善措施：选择合适的格式 —— 按 AVIF > WebP > JPEG 的优先顺序，用 <picture> 元素分发最优格式，AVIF 能以 JPEG 的 50% 以下体积实现同等画质；分发合适的尺寸 —— 不要分发比显示尺寸更大的图像，用 srcset 与 sizes 属性让设备选择最合适的尺寸；预载 —— 作为 LCP 元素的图像 (主视觉等) 用 <link rel="preload" as="image" href="hero.webp"> 优先载入；活用 CDN —— 从 CDN 分发图像，由离用户更近的边缘服务器高速交付；fetchpriority 属性 —— 对 LCP 图像设置 fetchpriority="high"，指示浏览器优先下载。

CLS 的三项防止措施：明示 width 与 height —— 务必在 <img> 标签上设置 width 与 height 属性，让浏览器在图像载入前就能预留空间；活用 aspect-ratio —— 用 CSS 的 aspect-ratio 属性固定容器的宽高比，防止图像载入时的布局位移；显示占位图 —— 图像载入中先显示低画质占位图 (LQIP: Low Quality Image Placeholder) 或模糊图像，载入完成后再替换为正式图像。

懒加载与预加载 - 优化加载策略

合理的加载策略确保关键图像快速显示，非关键图像不浪费带宽。

原生懒加载:

<img src="photo.webp" loading="lazy" alt="...">

• 浏览器在图像接近视口时自动加载
• 无需 JavaScript，性能开销为零
• 不要对首屏图像使用 (会延迟 LCP)

预加载关键图像:

<link rel="preload" as="image" href="hero.webp" type="image/webp">

• 告诉浏览器尽早开始下载
• 仅用于 LCP 图像或首屏关键图像
• 过度预加载会适得其反 (竞争带宽)

响应式预加载:

<link rel="preload" as="image" imagesrcset="small.webp 400w, large.webp 800w" imagesizes="100vw">

配合 srcset 预加载正确尺寸的图像，避免下载过大的版本。

延迟载入 (Lazy Loading) 的两种实现：原生 lazy loading —— 使用 <img loading="lazy"> 属性是最简单的方法，截至 2026 年全部主要浏览器均已支持；Intersection Observer API —— 需要更精细控制时使用，调整阈值 (threshold) 与外边距 (rootMargin)，让图像在滚动到可见之前就完成载入。

预载的实现与应避免的反模式：LCP 图像的预载 —— 把 <link rel="preload" as="image" href="hero.webp" type="image/webp"> 放在 <head> 内，图像的下载无需等待 HTML 解析完成，LCP 会大幅改善；响应式图像的预载 —— 用 <link rel="preload" as="image" imagesrcset="small.webp 400w, large.webp 800w" imagesizes="(max-width: 600px) 400px, 800px"> 可实现对应 srcset 的预载。反模式方面，不要给首屏图像设置 loading="lazy"，这会浪费带宽并延迟真正重要图像的载入；应同时使用 decoding="async"，让图像的解码处理不阻塞主线程。若 Google 的 PageSpeed Insights 出现「图像延迟载入」的警告，原因是视口外的图像没有设置 loading="lazy"。