图片搜索流量怎么拿：文件名、alt、图注、WebP 与 ImageObject 结构化数据七步实操

  1.  Home
  2. Text  
    3. Share to：

被忽略的流量入口：图片搜索

大部分个人站长做 SEO，眼睛只盯着「网页搜索」的结果页，从没打开过「图片搜索」的流量报表。结果是：一篇文章里的配图，白白浪费了一个天天都有海量请求的入口。以我的经验，一个内容型站点如果在图片搜索上做对了基础工作，图片入口能贡献全站 8%~20% 的自然流量——这部分流量竞争强度远低于网页搜索，原因很简单：大部分站长根本没管过它。

图片搜索的原理和网页搜索不太一样。它主要靠三个信号排序：文件名与 alt 文本、图片周边的正文语义、以及图片本身的特征（尺寸、清晰度、比例、是否是原创）。这意味着你不需要做外链、不需要拼关键词密度，只要把「图片本身被正确描述」这件事做好，就能拿到排名。

第一步：先看你现在有没有图片流量

在 Search Console 里，效果 → 搜索类型 → 图片 能直接看到图片搜索的曝光与点击。如果这里有数据但排名靠后，说明方向对了只是没做优化；如果完全没有数据，通常是三个原因之一：图片是 CSS 背景图（爬虫不认）、图片长宽比在结果页里不适合展示、或者 robots.txt 把图片目录屏蔽了。

顺手确认爬虫没被挡：

# 检查 robots.txt 里有没有误屏蔽图片目录
curl -s "https://www.example.com/robots.txt?_=$(date +%s)"

# 确认图片真实可访问（很多站是被防盗链 + 爬虫打架导致图片 403）
curl -sI "https://www.example.com/usr/uploads/2026/09/demo.jpg?_=$(date +%s)" | head -5

特别注意防盗链：如果你用 Nginx 的 valid_referers 做了防盗链，空 Referer 一定要放行，否则搜索引擎爬虫抓图时会拿到 403，图片就永远进不了索引。正确的写法里必须有 valid_referers none blocked server_names，这里的 none 就是给爬虫留的门。

第二步：文件名是权重最高的一步，且不可逆

把 IMG_20260928_143022.jpg 改成 nginx-fastcgi-cache-config-example.jpg，这一步的收益比任何其他操作都大，但绝大多数 CMS 默认生成的哈希文件名已经写进数据库和页面了，想改要付出代价。所以正确的策略是：上传前就改好文件名。

规则很简单：

  • 用英文小写，单词之间用连字符 -，不要用下划线（连字符是搜索引擎公认的分词符）
  • 包含 2~4 个描述性关键词，别堆砌。反面例子：nginx-nginx-cache-cache-config-2026-best.jpg 属于典型的关键词堆砌，会被判低质量
  • 中文站也可以用拼音，但更好的做法是保留英文技术名词（技术类内容的搜索词本来就常是英文）

如果是自己的 CMS，可以在上传流程里做一层自动重命名。比如 Typecho 的附件上传 hook，或者更简单——用一个本地脚本在上传前批量规范化：

#!/bin/bash
# 批量把上传目录里的乱文件名改成「页面标题-序号」形式
# 用法: rename_imgs.sh "nginx-fastcgi-cache" /path/to/imgs
PREFIX="$1"; DIR="${2:-.}"
i=1
for f in "$DIR"/*.jpg "$DIR"/*.png; do
  [ -e "$f" ] || continue
  ext="${f##*.}"
  new=$(printf "%s/%s-%02d.%s" "$DIR" "$PREFIX" "$i" "$ext")
  mv -n "$f" "$new" && echo "renamed -> $new"
  i=$((i+1))
done

第三步：alt 文本写对，而不是写满

alt 的作用是「图片无法显示时替它说话」，搜索引擎把它当作图片的标题来读。写法上：

要做的：用一句自然的话描述图片的内容实质。比如一张 Nginx 缓存命中的状态页截图，alt 应该是「Nginx fastcgi_cache 命中率 X-Cache-HIT 状态页截图」。

不要做的：

  • 把整段关键词塞进 alt（nginx 缓存 优化 教程 配置 加速 网站性能）——这是最典型的过度优化信号
  • alt 留空或写成「图片」「img」「截图」——等于放弃这个机会
  • 用 alt 做标题党（震惊！这个方法让网站快 10 倍）——图片搜索需要的是描述性文本，不是情绪化文本

如果图片是纯装饰（分隔线、背景纹理），alt 应该留空字符串 alt=""，配合 aria-hidden="true"，这才是无障碍规范里正确的写法，而不是硬编一个描述。

第四步：周边正文比 alt 更重要

搜索引擎判断一张图「讲的是什么」，权重最高的其实是图片附近的正文文本——图片上方的标题、下面的图注、以及同一段落里的句子。这就是为什么技术文章里的截图天生占优势：上下文里全是精确的技术名词。

两个可直接落地的做法：

  1. 给关键截图加 <figure> + <figcaption>，把图注写清楚。语义化标签本身就是信号，而且图注文本会参与匹配。
  2. 在图片所在段落里，自然地出现一次图片描述的对象名。不要为了图片单独造一段话，读起来要通顺。
<figure>
  <img src="/usr/uploads/2026/09/nginx-cache-status-page.png"
       alt="Nginx fastcgi_cache 状态页显示 X-Cache HIT 命中"
       width="1200" height="640" loading="lazy">
  <figcaption>配置完成后，刷新两次页面即可在响应头里看到 X-Cache: HIT，说明缓存已生效。</figcaption>
</figure>

注意 width / height 一定要写真实值，这既是 Core Web Vitals 里 CLS 的要求，也能帮爬虫提前知道图片比例，决定要不要放进图片搜索结果。

第五步：格式、尺寸与比例的选择

图片搜索的结果页是网格布局，横图（约 4:3、16:9）展示效果最好，方形次之，极端竖长图会被裁切得很奇怪。所以内容配图尽量用横图。

格式上按优先级：

  • WebP：当前兼容性最好、压缩率最高的选择，同等视觉质量下比 JPEG 小 25%~35%。
  • AVIF：压缩率进一步领先，但编解码耗时高，适合构建时离线处理，不适合实时生成。
  • PNG：只用于需要透明通道的示意图（比如架构图）。照片类内容用 PNG 是纯粹的浪费，一张 1920 宽的截图存 PNG 可能有 3MB，转 WebP 后不到 300KB。

转换命令（ImageMagick 7）：

# 单张转换，质量 82 是清晰度与体积的平衡点
magick input.png -quality 82 output.webp

# 批量转换，并去掉元数据（顺带解决 EXIF 隐私问题）
for f in *.png; do
  magick "$f" -strip -quality 82 "${f%.png}.webp"
done

# 别忘了服务端要能正确返回 MIME，否则浏览器会把 webp 当下载文件
# Nginx 里确认 types 包含: image/webp webp;

⚠️ 一个常见的坑：很多低配服务器装着 ImageMagick 却没有 WebP delegate。magick -list format | grep -i webp 里如果没有 rw+ 权限标记，转换会静默失败或报 no decode delegate。Debian 系装上 libwebp-dev 再重新编译或在 configure 时开启即可，宝塔面板装的版本一般已带。

第六步：延迟加载别用错，否则爬虫看不见图

loading="lazy" 是原生的，爬虫能识别，可以放心用。有问题的是 JavaScript 实现的懒加载：如果图片真实地址写在 data-src 里，而 src 是一个 1×1 的占位图，那么搜索引擎拿到的就是那个占位图，永远索引不到真实内容。

两种解法：

  1. 换用原生 loading="lazy"，这是最优解。
  2. 如果必须用 JS 方案，那么首屏图片和文章中靠前的图片一律不要懒加载，并且给所有懒加载图加 <noscript><img src="真实地址"></noscript> 兜底。

第七步：给图片加上 ImageObject 结构化数据

如果一张图是文章的核心内容（比如一张信息量很大的流程图），可以单独为它标注 ImageObject。虽然不一定直接出富摘要，但能显著提升被「图片搜索 + 知识面板」引用的概率：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "ImageObject",
  "contentUrl": "https://www.example.com/usr/uploads/2026/09/nginx-cache-status-page.png",
  "name": "Nginx fastcgi_cache 命中状态页",
  "description": "响应头显示 X-Cache: HIT，表示缓存命中，PHP 未执行。",
  "width": 1200,
  "height": 640,
  "representativeOfPage": false
}
</script>

注意 JSON-LD 里的 URL 必须是绝对地址，且和页面里 img 的 src 完全一致——不一致会被判为无效标注。

验证：怎么确认优化生效了

  1. 用 Search Console 的 URL 检查 输入图片地址，看是否「已编入索引」。
  2. 在 效果 → 搜索类型 → 图片 里，按查询维度看哪些图片查询带来了曝光，反过来优化 alt 和图注。
  3. 用 site:example.com 转到图片标签，看自己站上有多少图进了索引。这个数字是事后最重要的指标。
  4. 自己上传一张图后，等 3~7 天再查——图片索引比网页慢，别急着下结论。

常见问题

Q：图片放在第三方图床 / OSS 上，还算我的图片流量吗？
A：算，但排名会归到图床域名下，而且需要你能控制那个域名的 robots.txt。权衡下来，个人站建议自建图床并绑定自己的二级域名（如 img.example.com），既省服务器带宽，又能保住 SEO 归属。这跟站点接入 CDN 是同一套思路。

Q：一篇文章配几张图合适？
A：技术教程类文章，每 500~800 字配一张有信息量的截图/示意图是合理的。别为了配图而配图——堆十几张装饰性图片会让页面变重，反而拖累核心网页指标。

Q：把图片压缩后画质变差，会影响排名吗？
A：会。图片搜索会评估清晰度，压得糊成一团的图即使排名上去也留不住点击。质量参数压到 80~85 是安全的，低于 70 就要肉眼检查文字截图的边缘。

图片 SEO 的好处在于：它是一次性投入、长期被动收租的工作。一次把文件名、alt、图注、格式这几件事做对，之后每篇文章发布时只要沿用同一套规范，图片流量就会自己长出来。对个人站长而言，这是投入产出比最高的一块低垂果实。

Last modification：September 28th, 2026 at 09:24 pm
© 允许规范转载

相关文章

Leave a Comment