本篇技术指南围绕 claude-seo 项目的seo-images子技能（skills/seo-images/SKILL.md）展开，系统讲解图片 SEO 的完整工作流：站内<img>元素审计（alt 文本、文件体积、格式、响应式、懒加载、CLS）、基于 DataForSEO 的图片 SERP 竞争分析，以及基于 exiftool / cwebp / ImageMagick / FFmpeg 的图片文件级优化（WebP/AVIF 转换、IPTC/XMP 元数据注入、AI 生成图片的 DigitalSourceType 合规标注）。读完本文，你将掌握一套可立即落地的图片优化检查清单、命令集与决策依据，并理解仓库中 scripts/parse_html.py 与 scripts/iptc_ai_label.py 两个脚本的底层实现逻辑。

一、技能定位与适用场景

seo-images是 claude-seo 项目 25 个 SEO 子技能之一，属于技术 SEO 与性能优化的交叉领域。它的技能声明（SKILL.md frontmatter）定义了一组明确的触发语，例如 "image optimization"、"alt text"、"image SEO"、"image size"、"image audit"、"optimize images"、"image metadata"、"image SERP"、"convert to webp"、"image file optimize"，并支持argument-hint: "[url]"参数，即用户可直接传入目标 URL 发起审计。

技能覆盖三大能力域：

从仓库结构看，该项目还提供了配套的 agents/seo-visual.md 视觉分析代理（负责截图、首屏与移动端渲染检查）以及独立的analyze_visual.py脚本用于识别首屏 hero 图片，三者可组合成完整的"图片 + 视觉"审计链路，但本技能聚焦的是图片本身的 SEO 属性与文件级优化。

二、On-page 图片审计：九个检查维度

2.1 Alt 文本：Google Images 排名权重最高的因素

alt 文本是图片 SEO 中唯一被 Google 明确视为排名信号的 HTML 属性。审计时按下述标准逐一检查页面内所有<img>元素：

• 存在性：所有<img>元素都应带alt属性（纯装饰性图片除外，装饰图片应使用role="presentation"或alt=""）；
• 描述性：alt 必须描述图片内容，而不是文件名（如image.jpg）或空洞词（如photo）；
• 关键词：在自然的前提下融入相关关键词，严禁堆砌；
• 长度：控制在 10–125 个字符之间。

优秀示例：

• Professional plumber repairing kitchen sink faucet
• Red 2024 Toyota Camry sedan front view
• Team meeting in modern office conference room

反面示例：

• image.jpg（文件名而非描述）
• plumber plumbing plumber services（关键词堆砌）
• Click here（无描述性）

2.2 文件体积：按图片类别分级阈值

文件大小直接影响 Core Web Vitals 中的 LCP（最大内容绘制），因此审计按图片类别设置三档阈值：

在无损质量的前提下，应尽可能压缩到目标阈值以内。

2.3 格式：优先 WebP/AVIF，用<picture>做渐进增强

不同格式的浏览器支持率与适用场景如下：

核心建议：用 WebP/AVIF 替代 JPEG/PNG，并通过<picture>元素提供格式回退链，让浏览器自动选择第一个支持的格式：

<picture> <source srcset="image.avif" type="image/avif"> <source srcset="image.webp" type="image/webp"> <img src="image.jpg" alt="Descriptive alt text" width="800" height="600" loading="lazy" decoding="async"> </picture>

JPEG XL：值得关注的演进格式。2025 年 11 月，Google Chromium 团队推翻了 2022 年的决定，宣布将使用基于 Rust 的解码器在 Chrome 中恢复对 JPEG XL 的支持，目前实现已完成但仍未进入 Chrome stable。JPEG XL 支持 JPEG 无损重压缩（零质量损失约节省 20% 体积）且有竞争力的有损压缩表现。当前尚不适用于线上部署，但值得持续跟踪其后续采用进度。

2.4 响应式图片：srcset+sizes

• srcset提供多种尺寸；
• sizes与布局断点匹配；
• 分辨率要适配设备像素比（DPR）。

<img src="image-800.jpg" srcset="image-400.jpg 400w, image-800.jpg 800w, image-1200.jpg 1200w" sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px" alt="Description" >

2.5 懒加载与lazy_method：识别真实懒加载机制

• 折叠线以下图片使用loading="lazy"；
• 禁止对首屏/hero 图片懒加载（会直接损害 LCP）；
• 需区分原生懒加载与 JavaScript 驱动的懒加载方案。

<!-- 折叠线以下 - 懒加载 --> <img src="photo.jpg" loading="lazy" alt="Description"> <!-- 首屏 - 立即加载（默认） --> <img src="hero.jpg" alt="Hero image">

关键实现细节（lazy_method字段）：仓库的 scripts/parse_html.py 为每张图片解析出一个lazy_method字段，用于分类其懒加载机制。这一设计的背景是：被 Perfmatters、EWWW Image Optimizer 等插件优化过的 WordPress 站点会移除原生loading="lazy"并把src替换为占位符加 data 属性，如果只检查loading属性，会把"实际上大量懒加载"的页面误报为"未懒加载"。检测顺序为 native → perfmatters → ewww → js-generic → none：

审计时应当把lazy_method与loading一起报告，这样用户就能判断：站点是否在使用 JS 驱动的懒加载方案（此时原生loading="lazy"属性刻意缺失，不属于回归缺陷）。该逻辑有完整单测覆盖，见 tests/test_lazy_detection.py，其中验证了"原生优先于><img src="hero.webp" fetchpriority="high" alt="Hero image description" width="1200" height="630">

关键警告：绝对不要对首屏/LCP 图片使用loading="lazy"，这直接拉低 LCP 得分。loading="lazy"只应保留给折叠线以下图片。

2.7decoding="async"：避免图片解码阻塞主线程

对非 LCP 图片添加decoding="async"，防止图片解码阻塞主线程：

<img src="photo.webp" alt="Description" width="600" height="400" loading="lazy" decoding="async">

2.8 CLS 预防：固定宽高与aspect-ratio

• 所有<img>元素设置width和height属性；
• 或使用 CSSaspect-ratio；
• 对无尺寸声明的图片打标记。

<!-- 好 - 设置了尺寸 --> <img src="photo.jpg" width="800" height="600" alt="Description"> <!-- 好 - CSS 纵横比 --> <img src="photo.jpg" style="aspect-ratio: 4/3" alt="Description"> <!-- 差 - 无尺寸 --> <img src="photo.jpg" alt="Description">

2.9 文件名与 CDN

• 文件名：描述性命名（blue-running-shoes.webp优于IMG_1234.jpg），全小写、连字符分隔、不含特殊字符，融入相关关键词；
• CDN 使用：检查图片是否由 CDN 提供（不同域名、CDN 响应头），对图片密集站点推荐启用 CDN，并检查边缘缓存头。

三、审计输出：摘要、优先级清单与整改建议

完成检查后按以下三部分输出结果：

3.1 图片审计摘要

3.2 按影响排序的优化清单

按文件体积节省潜力降序排列（节省最多的排最前）：

3.3 推荐整改动作

1. 将 X 张图片转换为 WebP（预计节省 XX KB）；
2. 为 X 张图片补充 alt 文本；
3. 为 X 张图片补充宽高尺寸；
4. 为 X 张折叠线以下图片启用懒加载；
5. 压缩 X 张超大图片。

四、图片 SERP 分析：用 DataForSEO 补齐竞争数据

当 DataForSEO MCP 扩展可用时，可用命令/seo images serp <keyword>将站内图片审计与 Google Images 排名交叉对照，输出竞争对手的图片 SERP 全景。

工作流：

1. 通过serp_google_images_live_advanced获取 Google Images 结果（depth=100）；
2. 提取头部域名、图片类型、alt 文本模式；
3. 输出竞争对手图片 SERP 全景表。

输出示例：

分析维度：

• 域名统治力：哪些站点占据最多图片位（按数量取前 10）；
• Alt 文本模式：排名靠前图片的常见 title/alt 规律；
• 格式分布：头部结果中 WebP vs JPEG vs PNG 的占比；
• 机会评分：你已有页面排名但缺乏图片占位的关键词。

若 DataForSEO MCP 不可用，应告知用户并建议安装该扩展。仓库证据：DataForSEO 扩展的/seo dataforseo serp-images <keyword>命令同样调用serp_google_images_live_advanced（见 extensions/dataforseo/skills/seo-dataforseo/SKILL.md），其成本参考显示 SERP Images 端点单价为 $0.002、支持 5 倍计费并按site:/filetype:操作符加权（见 skills/seo-dataforseo/references/cost-tiers.md）。

五、图片文件级优化：格式转换、元数据注入与压缩

命令入口为/seo images optimize <path>，用于对单个或批量图片文件执行 WebP/AVIF 转换、IPTC 元数据注入、压缩以及响应式变体生成。

5.1 工具优先级与前置检查

运行前先用which exiftool cwebp convert ffmpeg确认哪些工具可用。

5.2 格式转换命令

# WebP（推荐默认）- 保留元数据 cwebp -q 82 -metadata all input.jpg -o output.webp # 通过 ImageMagick 转 WebP（cwebp 未安装时的兜底） convert input.jpg -quality 82 output.webp # 通过 FFmpeg 转 AVIF（编码较慢，压缩率最佳） ffmpeg -i input.jpg -c:v libaom-av1 -crf 30 -still-picture 1 output.avif # 响应式变体（400w, 800w, 1200w） convert input.jpg -resize 400x -quality 82 image-400.webp convert input.jpg -resize 800x -quality 82 image-800.webp convert input.jpg -resize 1200x -quality 82 image-1200.webp

5.3 IPTC 元数据注入：Google Images 富结果展示

Google Images 会在搜索结果中展示 IPTC 的 Creator（创作者）、Credit Line（署名行）与 Copyright（版权）信息。这不是排名因素，但能改善富结果展示与品牌署名。

用 exiftool（推荐）：

# 读取全部元数据 exiftool image.jpg # 注入 IPTC + XMP 元数据，用于 Google Images 富结果 exiftool \ -IPTC:ObjectName="Product Photo Description" \ -IPTC:Caption-Abstract="Detailed image description" \ -IPTC:By-line="Brand Name Photography" \ -IPTC:Credit="Brand Name" \ -IPTC:CopyrightNotice="Copyright 2026 Brand Name" \ -IPTC:Source="brandname.com" \ -XMP:Title="Product Photo Description" \ -XMP:Description="Detailed image description" \ -XMP:Creator="Brand Name Photography" \ -XMP:Rights="Copyright 2026 Brand Name" \ image.jpg # 批量注入目录下所有图片 exiftool -overwrite_original \ -IPTC:By-line="Brand Name" \ -IPTC:CopyrightNotice="Copyright 2026 Brand Name" \ *.jpg *.webp *.png

用 ImageMagick（兜底）：

identify -verbose image.jpg | head -50 convert input.jpg \ -set comment "Product Photo Description" \ -set IPTC:2:80 "Brand Name Photography" \ -set IPTC:2:116 "Copyright 2026 Brand Name" \ output.jpg

重要格式差异：WebP 原生支持 EXIF 和 XMP，但不支持 IPTC。对 WebP 文件应改用 XMP 字段而非 IPTC，exiftool 会自动完成这一转换。

5.4 AI 生成图片：DigitalSourceType（Merchant Center 强制要求）

对由生成式 AI 产出的商品图片，Google Merchant Center 强制要求携带 IPTCDigitalSourceType: TrainedAlgorithmicMedia元数据。这是运营政策层面的合规要求而非排名因素——缺少该标注的 AI 图片 feed 可能被拒批。

仓库提供了专门的封装脚本 scripts/iptc_ai_label.py，将 audit + inject 做成 CLI 命令，避免依赖操作者手敲 exiftool 单行命令（该脚本的设计动机在其 docstring 中有明确说明，即让审计可与 claude-seo 的 CLI 模式及 Agent 循环集成）：

# 审计目录内 IPTC 标注情况（统计 missing/ai/captured 等） python3 scripts/iptc_ai_label.py audit ./images/ --json # 审计单张图片 python3 scripts/iptc_ai_label.py audit ./hero.webp --json # 为图片注入 AI 标注 python3 scripts/iptc_ai_label.py inject ./ai-hero.webp \ --source-type trainedAlgorithmicMedia # 其他词表值： # compositeSynthetic （拍摄 + AI 元素混合） # digitalCapture （完全拍摄的照片）

原始 exiftool 等价命令（临时使用）：

# 手动注入 exiftool \ -XMP-iptcExt:DigitalSourceType="https://cv.iptc.org/newscodes/digitalsourcetype/trainedAlgorithmicMedia" \ ai-generated-product.jpg # 审计：找出目录中缺少该标注的图片 exiftool -if 'not $XMP-iptcExt:DigitalSourceType' \ -filename -DigitalSourceType *.jpg *.webp *.png

IPTC 词表还定义了以下取值（脚本中的IPTC_VOCAB常量与之对应，见 scripts/iptc_ai_label.py）：

• trainedAlgorithmicMedia— 完全由 AI 生成（扩散模型商品图用此值）；
• compositeSynthetic— 拍摄与 AI 生成元素混合；
• digitalCapture— 完全拍摄的照片（无 AI 元素）。

实现细节：该脚本的audit会递归遍历目录下的.jpg/.jpeg/.png/.webp/.tif/.tiff文件（见_iter_images），通过 exiftool 读取XMP-iptcExt:DigitalSourceType，并把返回的完整 URI 归一化为短名后归类统计；inject会校验 source-type 是否在词表内、exiftool 是否可用、文件是否存在，再以-overwrite_original落盘。相关的纯逻辑测试（不依赖真实 exiftool，通过 mock 完成）见 tests/test_phase_j_executable.py，覆盖了词表校验、target 不存在、exiftool 缺失、未知 source-type 拒绝等错误路径。

执行约定：当对 AI 生成素材执行/seo images optimize时，应提示用户确认素材来源类型，并自动注入对应的 IPTC 值。另外，对 AI 生成的商品标题与描述，Google Merchant Center 也要求在 feed 中单独指定并标注 AI 生成文本——这属于 feed 层而非页面层的强制项，应与seo-ecommerce技能交叉核对。

5.5 元数据审计

# 快速审计 exiftool -IPTC:all -XMP:all -EXIF:ImageDescription image.jpg # 批量审计 - 找出缺少 IPTC Creator 的图片 exiftool -if 'not $IPTC:By-line' -filename *.jpg *.webp *.png

5.6 完整优化流水线

为达到最佳图片 SEO 效果，对每张图片按以下流水线执行：

1. 审计现有元数据：exiftool -IPTC:all -XMP:all image.jpg
2. 注入 IPTC/XMP 元数据：Creator、Copyright、Description
3. 转换为 WebP：cwebp -q 82 -metadata all image.jpg -o image.webp
4. 生成响应式变体：400w、800w、1200w
5. 验证元数据保留：exiftool image.webp
6. 生成<picture>HTML：AVIF > WebP > JPEG 回退链

六、Google Images 排名的"影响因素对照表"

明确区分"对排名真正重要"与"纯展示或无关"的因子，避免在无效环节浪费精力：

七、异常处理矩阵

审计与优化过程中可能遇到各类环境问题，处理策略如下：

八、总结

图片 SEO 是一个"双层"工程：页面层负责 alt 文本、响应式、懒加载与 LCP/CLS 优化（这是 Google Images 排名的主战场），文件层负责现代格式转换、元数据注入与合规标注（这是展示质量与政策合规的保障）。claude-seo 的seo-images技能把这两层打通为一个可执行的工作流——从parse_html.py的lazy_method智能懒加载识别，到iptc_ai_label.py的 AI 图片合规标注，配合 DataForSEO 的图片 SERP 竞争分析，形成"审计 → 诊断 → 优化 → 复检"的完整闭环。如需将审计结果接入更大的审计编排流程，可进一步阅读 skills/seo/ 主技能与 agents/seo-visual.md 视觉分析代理的协作方式。