Image SEO 需要同时完成四件事:图片帮助页面、看不到图片时仍可访问、搜索系统能发现文件,以及用合适质量快速加载。Alt 很重要,但无法修复不相关、被阻挡或过大的 Hero Image。
Google 会结合图片、Alt 与附近页面 Context。W3C 也会按信息图、功能图、装饰图、复杂图或重复图决定不同 Text Alternative。先定义任务,再正确书写或留空 Alt。
快速答案:按这个顺序优化
| 层级 | 问题 | 通过条件 |
|---|---|---|
| 目的 | 图片是否帮助真实页面任务? | 解释、证明、比较、识别或完成动作 |
| 无障碍 | 看不到图片会失去什么? | 仍有同等意义或功能 |
| 发现 | Google 能找到文件与 Landing Page? | HTML、页面与图片 URL 可抓取 |
| Context | 系统能理解它为什么在这里? | 相关附近文字、Caption 或 Structured Data |
| 传送 | Browser 收到合适版本? | 正确尺寸、格式、Responsive Source |
| 优先级 | 是否为 First Viewport 关键内容? | LCP 提早加载;后面图片延迟 |
| 衡量 | 是否改善原定结果? | 搜索、无障碍与性能证据 |
写 Alt 前先分类图片
每个 <img> 都需要 alt 属性,但不一定需要文字。alt="" 会告诉辅助技术忽略装饰或完全重复的图片;遗漏属性可能导致文件名或 URL 被读出。
| 图片任务 | Text Alternative | 例子 |
|---|---|---|
| 信息照片 / Screenshot | 简短传达当前 Context 的有用意义 | 描述显示的发现,不必说所有颜色 |
| 链接 / 按钮里的功能图 | 描述目标或动作 | “下载 SEO Audit Template” |
| 装饰图 | alt="" | 没有信息的抽象背景 |
| 重复图 | 附近文字已完全表达时用空 Alt | “搜索”文字旁的搜索 Icon |
| 复杂图表 | 短 Alt + 附近完整解释或 Data Table | 命名图表并用文字解释趋势 |
| 含必要文字的图片 | 附近没有时包含必要文字 | 只有海报图中出现活动日期 |
| Logo | 识别机构时使用机构名 | “SEOWithJack” |
| Portrait | 身份相关时使用姓名或 Role | “Jack Lee,SEO Consultant” |
按照当前页面用途写 Alt
Alt 取决于 Context。同一张照片在 Team Page、案例 或装饰 Banner 上可能需要不同处理。描述用户必须理解或完成的事,不要写文件名、关键词清单或“这是一张图片”。
图片作为链接时,Alt 类似 Anchor Text,应描述去哪里或做什么。title 属性不能代替 Alt。
| 情况 | 较弱 | 有用 |
|---|---|---|
| Audit Screenshot | “SEO screenshot dashboard ranking report SEO” | “Search Console 报告显示已收录与排除页面” |
| 产品比较 | “两台 Laptop” | “13 英寸与 15 英寸 Laptop 并排比较” |
| 可点击 PDF Cover | “Report Cover” | “下载 2026 技术 SEO Checklist” |
| Chart | “Traffic Chart” | “三月迁移后 Organic Click 下降” |
| 装饰 Gradient | 描述所有颜色 | alt="" |
| 图片与 Caption 意义相同 | 重复整个 Caption | 没有额外意义时使用空 Alt |
让图片存在于真正可发现的 HTML
Google 表示可以发现标准 <img> 的 src,包括 <picture> 内的 <img>。Google 不索引 CSS Image。装饰可用 CSS Background;内容、证据与代表图片应使用正常 HTML Image。
如果 JavaScript Gallery 要互动后才把 URL 从 data-src 换出来,必须检查 Rendered HTML 与 Crawler Access。重要图片不应依赖 Click、Login 或被阻挡 Script 才存在。
- Landing Page 成功回应且可索引。
- Image URL 返回正确图片与 Content Type。
- Robots 没有阻挡页面或图片。
- 重点图片存在于
<img src>或可抓取 Responsive Pattern。 <picture>与srcset保留<img src>Fallback。- 不需 Login、Cookie 或用户动作才能取得图片。
- CDN URL 稳定且 Googlebot 可访问。
- 移除或替换 Broken、Placeholder 与 Hotlink。
使用稳定文件名与一致 URL
Google 把 Filename 形容为轻量提示,不是重复关键词的位置。新图片可使用短而描述性的名称,Extension 应符合实际格式。同一图片出现在多个页面时,尽量引用同一个 URL。
不要只为美化 Filename 而更换已经收录的 Image URL。迁移成本可能大于很小的命名收益。
| Asset | 建议 Filename | 避免 |
|---|---|---|
| 案例 Screenshot | redirect-validation-report.webp | IMG_4821-final-final.webp |
| Service Photo | technical-seo-audit-review.jpg | best-seo-seo-malaysia.jpg |
| Chart | organic-clicks-before-after-migration.svg | chart1.svg |
| Portrait | jack-lee-seo-consultant.jpg | DSC00038.jpg |
| 本地化 Diagram | zh-cn-crawl-index-flow.svg | 继续使用看不懂的英文图 |
按视觉任务选择格式
Google 目前支持在 Image src 使用 BMP、GIF、JPEG、PNG、WebP、SVG 与 AVIF。没有放诸四海皆准的“最佳格式”或 KB 目标;还要看 Browser Support、画面质量、编辑流程与 Fallback。
含小字的 Screenshot 可能需要 Lossless 或接近 Lossless;照片通常适合 Perceptual Compression。应比较实际输出。
| 内容类型 | 起点 | 注意 |
|---|---|---|
| 照片 | AVIF/WebP;有需要保留优化 JPEG | 皮肤、Gradient、过度压缩 |
| UI Screenshot | 高质量 WebP/AVIF 或优化 PNG | 文字模糊、颜色边缘 |
| Logo / 简单 Icon | 安全且合适时用 SVG | 不可信 Script、缺少 Accessible Name |
| 透明 Raster | WebP、AVIF 或 PNG | 边缘与背景异常 |
| 简单 Animation | 现代动画格式、CSS 或 Video | 大 GIF 与分心 |
| 复杂 Illustration | 实际测试 SVG 与 Raster | SVG 过度复杂或 Raster 尺寸太大 |
按实际显示位置准备尺寸
CSS 可以把 4,000px 图片显示成 700px,但 Browser 仍可能下载大文件。应围绕真实 Layout Width 与 Device Pixel Density 生成少量有用 Candidate,不要制造大量任意版本。
srcset 列出来源,sizes 描述预计显示宽度,由 Browser 选择。只有需要格式 Fallback 或真正不同 Crop 时才使用 <picture>。
| 位置 | Candidate 策略 | QA |
|---|---|---|
| Full-width Hero | 多种宽度直到真实 Design Max | Mobile Crop 保留主体 |
| 篇文章 Body Image | Content Column 与高密度显示宽度 | 文字与 Label 可读 |
| 一排四张 Card | 按 Card Width 准备小图 | Mobile 不下载 Desktop Grid Asset |
| Thumbnail List | 独立 Thumbnail Size | 120px 位置不传 Hero File |
| Art-directed Banner | <picture> 提供 Mobile Crop | 每个 Source 表达相同意义 |
文件到达前预留空间
设置 Intrinsic width 与 height,或提供可靠 Aspect Ratio,让 Browser 预留位置。Responsive CSS 仍可流动缩放;HTML Dimension 描述 Source Ratio,不是强制视觉大小。
- Width/Height 符合 Intrinsic Ratio。
- CSS 在 Breakpoint 保持正确比例。
- Crop 不隐藏重要文字或证据。
- Gallery/Carousel 有稳定 Initial Height。
- Caption 不会突然覆盖或推走内容。
- 错误与 Fallback 状态仍可使用。
- Mobile Orientation 改变不会跳动。
- 检查 Real-user CLS,不只一次 Lab Run。
LCP 图片必须特别处理
可能成为 Largest Contentful Paint 的图片应在 Initial HTML 可发现、不能 Lazy-load,并尽早开始加载。Measurement 确认是 LCP 后,可测试 fetchpriority="high";不要全部图片设 High Priority。
Preload 适合 Browser 无法提早发现的真正关键图片。普通 Initial HTML <img> 未必需要。通过Core Web Vitals 指南分别诊断 TTFB、Resource Delay、Transfer 与 Render Delay。
| 位置 | Loading | Priority |
|---|---|---|
| Hero / Likely LCP | Eager / Default | Measurement 后考虑 fetchpriority="high" |
| 其他 Above-fold | Default | 通常交给 Browser |
| Below-fold Editorial | loading="lazy" | Default |
| 隐藏 Carousel Slide | 适当 Lazy / Lower | 不要和可见 Slide 竞争 |
| 无法更换的 CSS LCP Background | 小心 Preload | 测试确切 Responsive URL,避免 Double Download |
按位置 Lazy-load,不要成为习惯
Native loading="lazy" 适合 Offscreen Image,不是每张图的勋章。页面加载时可见的图片,尤其 LCP,不应等待 Layout 与距离判断。
除非有可抓取 Fallback,否则避免用 JavaScript 把真正 src 隐藏在非标准属性。
- 在代表性 Template 找出实际 LCP。
- Above-fold / LCP 不 Lazy-load。
- 适合的 Offscreen Image 才 Native Lazy。
- 真正 Source URL 保留在 HTML。
- 不要 Preload 很多图片制造 Bandwidth Competition。
- 长 Cache 图片改变时使用 Version。
- 验证 CDN Resize 与 Format。
- 监控 Broken Image 与异常大传输。
把图片放在能解释它的 Context
Google 会利用 Caption、Image Title 与附近文字理解 Subject。相关页面上的相关图片,比在不同文章重复 Generic Stock Photo 更有价值。
不要把唯一重要答案锁在 Screenshot。搜索系统和辅助技术需要 Visible Text,用户也需要复制、翻译与放大。
| 元素 | 任务 | 正确决定 |
|---|---|---|
| 附近 Paragraph | 解释图片为何重要 | 分析 Screenshot,不只介绍 |
| Caption | 加入 Source、Date 或 Takeaway | 只在帮助读者时使用 |
| Figure / Figcaption | 关联媒体与可见 Caption | 适合 Chart、Evidence、Credit |
| Alt | 提供非视觉等同意义或功能 | 不需重复很长 Caption |
| Transcript / Table | 承载复杂资料 | 用于 Diagram、Chart、Text-heavy Visual |
刻意选择页面代表图片
Google 自动选择 Preview,但可通过 primaryImageOfPage、篇文章 Image 与 og:image 表示偏好。图片应相关、高质量,并在适合时出现在可见页面。
不要每页都用同一个 Generic Logo、不相关 Stock Photo 或极端比例图片。通过Structured Data 流程保持真实一致,并用Content Refresh 流程检查旧图。
| Surface | Field | 检查 |
|---|---|---|
| Visible Page | <img>/Figure | 相关证据或代表 |
| WebPage Schema | primaryImageOfPage | Absolute Accessible URL |
| 篇文章 Schema | image | 符合文章与 Guidelines |
| Social Preview | og:image | Crop、Context 与 URL 正确 |
| Image Result | Landing Page + Image Context | 点击后页面仍有用 |
用 Image Sitemap 与 CDN 处理发现缺口
Image Sitemap 可让 Google 发现原本难找的 Image URL,但不会让不相关图片排名,也不能代替正常 HTML。只加入 Canonical Page 上有用的 Public Image。
Image Sitemap 可以引用 CDN Domain。实际可行时在 Search Console 验证 CDN Ownership,让 Crawl Error 可被报告。先修复不断改变的 URL、过期签名与 Bot Block。
- Canonical Landing Page 可索引。
- 提交的 Image URL 返回正确文件。
- 只包括有用 Public Image。
- 可行时验证 CDN / Source Domain。
- Robots / Signed URL 不会让权限过期。
- 同一 Asset 不被拆成不必要 URL。
- 迁移时处理 Old Image URL。
- Deployment 后实际测试发现。
记录 Ownership、Permission 与 Licensing
能在搜索看到图片,不代表有权使用。记录图片是原创、客户提供、Licensed Stock、Commissioned、Public Domain 或 Generated,并保存 Terms 与 Source Evidence。
Google 支持通过 Structured Data 或 IPTC Photo Metadata 提供 Creator、Credit、Copyright、License 与 Acquire-license Page。不要只为省少量 Bytes 就删除关键 Rights Metadata。
| 记录 | 用途 |
|---|---|
| Source / Creator | 证明来源 |
| Owner / Permission | 确认网站可发布 |
| License Scope | 商业、编辑、地区、修改限制 |
| Credit | 确保 Attribution 正确 |
| Expiry / Renewal | 权利结束后停止使用 |
| Original / Derivative | 未来 Crop 与替换 |
| AI / Composite Provenance | Transparency 与内部 Policy |
| Removal 联系 | Rights Issue 时快速处理 |
从 Template 到单张 Asset 审核
- 列出 Image URL、Landing Page、Status、Format、Intrinsic Dimension 与 Transfer。
- 分类为 Informative、Functional、Decorative、Redundant 或 Complex。
- 判断 Alt 是 Missing、正确留空还是需要重写。
- 验证页面与文件 Public 且可抓取。
- 找出 CSS-only 重点图与非标准 Lazy Source。
- 比较 Intrinsic Dimension 与 Mobile/Desktop Rendered Slot。
- 在核心 Template 识别实际 LCP 与 Resource Timing。
- 检查 Width、Height、Ratio、Crop 与 Fallback。
- 审核 Filename、Nearby Text、Caption 与 Representative Metadata。
- 测试 Broken URL、Redirect、CDN、Cache 与 Content Type。
- 确认 Ownership、Credit 与 License Evidence。
- 按 User Impact、Template Scale、Image Opportunity 与 Effort 排序。
分别衡量图片结果
Search Console 的 Image Type 代表 Google Images Tab 结果。按 Page、Query、Country、Device 与 Date 分析;不要假设它涵盖所有普通 Web Result 或 Discover 内的图片。
把搜索数据与 Real-user Performance 和业务结果结合。图片即使没有 Image 搜索 Click,也可能因为解释流程、减少客服问题或辅助转化而成功。
| 目标 | 证据 | 谨慎解释 |
|---|---|---|
| 发现 | Image Impression 与 Indexed Landing Page | Index 不保证 Visibility |
| 相关访问 | Image Click、Query、Landing Page | 检查到达后动作 |
| 速度 | Field LCP 与 Resource Timing | Lab 用于诊断,Field 代表用户 |
| 稳定 | Field CLS + Visual QA | 图片不一定是唯一 Shift |
| 无障碍 | Alt 分类与 Assistive Test | 自动工具不能判断 Meaning |
| 转化 | Form、Product View、Assisted Action | 不要把结果归因一个改变 |
| 营运健康 | Broken Image、Transfer Weight、CDN Error | 先处理 Template-wide 问题 |
常见 Image SEO 错误
- 每个 Alt 都加关键词。
- 装饰图不用空 Alt。
- 信息图缺少 Alt 属性。
- 重点编辑图片只用 CSS Background。
- Lazy-load LCP Hero。
- Small Card 传送原始相机文件。
- 不检查 Mobile 意义就使用同一个 Desktop Crop。
- Preload 或 High Priority 太多图片。
- 每篇 篇文章 都用同一个 Generic Logo。
- 以为 Image Sitemap 能修复 Blocked Image。
- 没有检查法律和 Attribution 就删除 Rights Metadata。
- 只衡量 File Size,不看用途、无障碍与转化。
常见问题
每张图片都要写 Alt 吗?
每个 <img> 都需要 Alt 属性,但装饰和完全重复图片通常使用 alt="";信息图和功能图需要有用等同意义。
Alt 应该多长?
没有 SEO 字数指标。以能在当前 Context 理解意义或动作的最精简文字为准;复杂内容放在附近 Visible Text。
Alt 要放 Keyword 吗?
使用描述图片所需的自然用词。主题确实出现在图片时会自然包含,不要强塞或重复。
WebP / AVIF 一定更好吗?
通常压缩良好,但仍取决于图片、Quality Setting、Browser Support 与制作流程,应测试实际画面与传输。
图片要控制在多少 KB?
没有统一目标。根据 Rendered Slot、视觉细节、图片数量与真实用户网络建立 Performance Budget。
Hero 要 Lazy-load 吗?
页面加载时可见或可能成为 LCP 就不要。让它提早发现,再衡量 Fetch Priority 是否帮助。
Google 会索引 CSS Background Image 吗?
Google 明确表示不索引 CSS Image。想被发现的有意义图片应使用标准 HTML Image。
需要 Image Sitemap 吗?
重点图片难以发现或网站图片很多时可使用,但它不能代替 Crawlable HTML 与有用 Landing Page。
可以使用 Stock 或 AI 图片吗?
拥有正确使用权并真正帮助页面即可。保留 Provenance 与 License;不要把生成图片伪装成真实客户、结果或事件证据。
怎样衡量 Image SEO?
在 Search Console 筛选 Image 搜索,再结合 Page / Query、Field Performance、Accessibility Review 与 Landing Page 业务结果。
官方参考资料
- Google 搜索 Central: Google Images best practices
- Google 搜索 Essentials
- Google 搜索 Central: Image license metadata
- web.dev: Responsive images
- web.dev: Image performance
- web.dev: Optimize Largest Contentful Paint
- web.dev: Browser-level image lazy loading
- W3C WAI: Alt decision tree
- MDN: The img element
- Ahrefs: Image SEO best practices
- Google Search Console API: 搜索 Analytics query
分享代表 Template 或 Image Crawl。Jack 可以把 Accessibility、Discovery、Responsive Delivery、LCP、Metadata 与 Licensing 问题整理成优先实施计划。



Google 排名如何演变:从 PageRank 到现代搜索系统2026年9月2日
Google AI 内容与 SEO:什么被允许、什么是垃圾内容,以及怎样安全发布2026年9月2日
Google Florida Update 2003:事实、理论与 SEO 教训2026年9月2日