本文约 3,864 字，预计阅读 10 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：配图花了两小时，图片搜索一个点击都没有
写文章时认真做了十几张配图，发布三个月后在 Search Console 里查，图片带来的点击是 0。打开 Google 图片搜索输入关键词，同行的截图排在第一页，自己的图根本搜不到。问题通常不在图片本身，而在四个细节全都没做：文件名是 IMG_20260115_143022.jpg，ALT 属性空着，图片原图 4000px 宽直接插进正文，格式还是十年前的 JPEG。
Google 图片搜索的索引逻辑和网页搜索不完全一样：它更依赖「图片周围与图片自身的文字信号」。文件名、ALT、图注、周边正文、所在页面的标题，共同构成这张图的语义。缺少其中任何一环，图片就只有一个视觉含义，Google 无法判断它该出现在哪些查询下。而尺寸和格式影响的不是索引，是用户体验与 Core Web Vitals——原图直出会把 LCP 拖到 4 秒以上，页面整体表现一起下滑。
原理分析：四个要点各自解决什么问题
| 要点 | 影响的对象 | 做错的后果 |
|---|---|---|
| 文件名 | 图片自身的语义信号、CDN 缓存键 | 无关键词信号，图片搜索几乎不展现 |
| ALT 属性 | 图片语义 + 无障碍 + 图片加载失败时的替代文本 | 语义丢失，屏幕阅读器无法识别 |
| 尺寸（width/height/srcset/sizes） | CLS 布局偏移、LCP 加载时间 | 页面跳动、CLS 超标、移动端加载原图 |
| 格式（WebP/AVIF/JPEG） | 文件体积、解码耗时 | 体积过大拖慢 LCP，Lighthouse 扣分 |
四个要点里有优先级。文件名和 ALT 决定「能不能被搜到」，是索引问题；尺寸和格式决定「加载快不快」，是体验问题。如果只能做两件事，先做文件名与 ALT，因为它们直接决定有没有流量；如果流量已经稳定，再优化尺寸与格式，因为这时候瓶颈变成了体验与排名。另外要注意：同一张图放在不同页面，Google 会根据所在页面的主题判断它的语义，所以配图与正文主题一致比图片本身更重要，不要用一张通用装饰图配在所有文章里。
保姆级实操
步骤 1：在上传环节就解决文件名。 靠人工改名一定坚持不下去，用钩子在上传时自动整理：
// functions.php：上传时把中文/空格文件名规范为小写英文短横线
add_filter( 'sanitize_file_name', function ( $filename ) {
$parts = explode( '.', $filename );
$ext = array_pop( $parts );
$name = sanitize_title_with_dashes( implode( '.', $parts ) );
return $name . '.' . $ext;
}, 10 );
// ALT 兜底：附件未填写替代文本时，用标题或别名生成，避免出现空 ALT
add_filter( 'wp_get_attachment_image_attributes', function ( $attr, $attachment ) {
if ( empty( $attr['alt'] ) ) {
$alt = get_post_meta( $attachment->ID, '_wp_attachment_image_alt', true );
if ( ! $alt ) {
$title = get_the_title( $attachment->ID );
$attr['alt'] = $title ? $title : str_replace( '-', ' ', get_post_field( 'post_name', $attachment->ID ) );
} else {
$attr['alt'] = $alt;
}
}
return $attr;
}, 10, 2 );
步骤 2：写 ALT 的三条规则。 描述图片「是什么」而不是「为了 SEO」；控制在 120 字符以内；不要每张图都以「图片」「截图」开头。装饰性图片（分隔线、背景纹理）用空 ALT：alt=""，让屏幕阅读器跳过。
步骤 3：输出带尺寸与响应式属性的图片。 WordPress 的 the_post_thumbnail() 与区块编辑器默认会输出 srcset/sizes，但手写 HTML 时必须自己补：
<figure class="wp-block-image size-large">
<img src="/wp-content/uploads/2026/01/wordpress-psi-mobile-score-1024x576.webp"
srcset="/wp-content/uploads/2026/01/wordpress-psi-mobile-score-1024x576.webp 1024w,
/wp-content/uploads/2026/01/wordpress-psi-mobile-score-300x169.webp 300w,
/wp-content/uploads/2026/01/wordpress-psi-mobile-score-768x432.webp 768w"
sizes="(max-width: 768px) 100vw, 768px"
width="1024" height="576"
loading="lazy" decoding="async"
alt="WordPress 站点优化后 PageSpeed Insights 移动端得分 92 的实测截图">
<figcaption>同一套主题优化前后的 PageSpeed Insights 移动端得分对比</figcaption>
</figure>
步骤 4：给重要图片加结构化数据。 产品图、教程步骤图可以在 JSON-LD 里用 ImageObject 补充 caption、license、creator 字段，帮助 Google 理解版权与用途。
步骤 5：为图片搜索单独准备入口。 图片应有独立的可访问 URL（不要只在 JS 里动态生成），且图片所在页面不能 noindex。如果图片放在 CDN 子域，要确保该子域可被 Googlebot 抓取，robots.txt 里不要屏蔽 /wp-content/uploads/。
步骤 6：验证。 用 Google 图片搜索直接搜目标关键词看是否出现；再用网址检查工具看渲染后的 HTML 里图片资源是否全部加载成功（「查看已抓取的页面」里若有图片 404，说明路径或防盗链有问题）。
常见踩坑
- 用
DSC_0023.jpg这类相机原始文件名，零语义，图片搜索基本无望。 - ALT 堆关键词，把「WordPress 教程 SEO 优化 图片 alt 写法 最佳实践」整段塞进去，反而不如图注自然。
- 在正文里插入 4000px 原图，移动端实际显示 360px，白白浪费几百 KB。这一步与 WebP AVIF 图片格式 的做法配合才完整。
- robots.txt 屏蔽了 uploads 目录，图片永远不会被索引。
- 图片靠 JS 懒加载且 src 写在 data 属性里，Googlebot 拿不到真实地址，这一点在 图片懒加载与索引 里有详细说明。
- 所有文章共用一张头图，Google 会把同一张图关联到多个不相关主题，语义被稀释。
- 案例：某教程站把配图都放在对象存储上，并开启了 Referer 防盗链，只允许本站域名。Googlebot 抓取时没有 Referer，图片全部返回 403，三个月后该站在 Google 图片搜索里的展现量从每月 1.2 万跌到不足 300，排查时一直以为是文件名问题，最后才发现是防盗链规则。
- 忘记给图片加
width/height，正文加载时反复跳动，CLS 直接超过 0.25。
总结
判断图片 SEO 是否合格的标准：把图片单独放到 Google 图片搜索里输入目标关键词，能不能在第一页找到它；再用 PageSpeed Insights 测同一页面，移动端图片传输体积是否超过 500KB。执行顺序固定为——上传前自动规范文件名 → 逐张补 ALT（装饰图留空）→ 输出带 srcset/sizes 与显式宽高的标记 → 换成现代格式并压缩 → 确认 uploads 目录与防盗链规则放行 Googlebot。做完这五步，图片搜索通常四到六周开始出现稳定展现。后续的批量提交可以配合 图片 sitemap 提交 的做法一起做。
