Google图片SEO：发现、索引、语义与性能验收

直接答案：本文把 Google 图片 SEO 拆成一条有依赖顺序的验收链：先分清图片收录与网页收录，再检查图片 URL 是否可被抓取，确认图片来源是否可被发现，最后核对落地页上下文与可索引性。每一步都给出判断依据、失败路径与记录字段，帮助你对每张目标图片产出一份可复核的逐图验收记录。

先分清图片收录与网页收录

排查图片问题的第一步不是改 alt，也不是压缩图片，而是先确定你面对的到底是哪一类失败。图片收录与网页收录是两套独立判断：一张图片可能所在页面已被索引，但图片本身没有进入图片结果；也可能页面本身就无法索引，图片自然缺少展示的前提。把这两件事混在一起，会导致你在错误的层级上反复修改。

判断顺序建议如下。先记录图片 URL 本身的状态，再记录该图片所在落地页的索引状态，两者分别填写，不要合并成一栏。如果落地页不可索引，那么无论图片 URL 多么干净、alt 写得多完整，图片都缺少一个可被引用的上下文；此时优先解决页面层问题，而不是继续优化图片属性。

反过来，如果落地页可索引而图片仍未出现，问题更可能落在图片 URL 的可抓取性、来源暴露方式或语义信息上。

这里有一个常见误判：把网页收录状态当作图片收录结论。网页被索引只能说明页面进入了索引，不能推出页面内的每张图片都被单独处理。Google 的图片相关文档把图片的发现与上下文作为独立话题讨论，官方帮助页也把“如何让图片出现在图片搜索中”作为单独说明，这本身就提示两者不是同一个判断（见 [Google 图片 SEO 指南](https://developers.google.com/search/docs/appearance/google-images) 与 [Google 图片搜索帮助页](https://support.google.com/websearch/answer/175288?hl=en)）。

本节的产出是一组两栏状态记录：图片 URL 状态、落地页索引状态。差异本身就是排查线索——两者都正常却仍无图片表现，说明要继续往来源暴露与语义层走；页面异常则先修页面。

检查图片 URL 是否可被抓取

上一节确认了“图片与网页要分开判断”，本节处理最底层的一环：图片 URL 本身是否处于可被抓取的状态。如果这一层断裂，后面所有关于 alt、尺寸、站点地图的工作都不会产生可验证的效果，因为抓取系统根本没有拿到这个资源。

需要检查三类信号。第一是响应状态：直接请求图片 URL，记录返回的状态类别，而不是凭印象判断。第二是抓取规则：确认 robots 相关规则没有把图片路径整体排除在外，注意图片常与页面处于不同目录甚至不同子域。第三是实际抓取结果：在你能使用的官方工具中查看该 URL 是否被抓取过、结果如何，并记录观察时间。

失败路径通常有三种。其一是状态异常，例如资源被移动、被删除或需要鉴权，此时应回到资源托管侧修复，而不是在页面里改属性。其二是规则误伤，例如为屏蔽某个目录而写下的规则顺带覆盖了图片路径，修复方式是收窄规则范围。其三是“看起来正常但抓不到”，例如图片由脚本在交互后才插入，静态抓取看不到来源，这类问题要到下一节处理。

本节不要做的事：不要把排名或流量变化当作修复生效的证明。状态码从异常变为正常、抓取记录出现新条目，这些才是可复核的证据。

本节的产出是一张图片 URL 状态检查表，字段至少包含：图片 URL、请求时间、响应状态、robots 覆盖情况、抓取记录观察结果、结论。异常状态优先修复，修复后再进入下一节。

确认图片来源可被发现

上一节确认了 URL 可被抓取，本节要回答的是：这张图片在 HTML 中是否被明确暴露出来。可抓取不等于可发现——一个能正常返回的图片 URL，如果只存在于脚本逻辑、CSS 背景或用户交互之后，静态解析就找不到它。

逐项核对来源。第一，检查 `src` 是否存在且指向真实资源，这是最基础的可发现来源。第二，检查 `srcset` 与 `sizes`：响应式图片通过多候选来源交付，需要确认候选集合中的 URL 都是有效且可抓取的，而不是只验证了其中一个。第三，检查懒加载实现：懒加载本身不是问题，但如果真实来源被推迟到滚动或交互之后才写入，静态视角下这张图片就没有来源。

第四，检查是否存在“占位图替换真实图”的模式，确认占位 URL 不会被误当作最终资源。

这里要特别区分 `src` 与 `srcset` 等回退来源。当两者同时存在时，不要只验证其中一个就下结论；候选来源中任意一个失效，都可能让部分场景下的交付失败。响应式图片的技术文档说明了 `srcset` 与 `sizes` 如何影响交付，同时也说明保留可发现的图片来源是前提（见 [响应式图片文档](https://web.dev/learn/images/responsive-images)）。

失败路径包括：图片仅由脚本注入、`srcset` 中混入失效 URL、懒加载把真实来源藏在数据属性里、以及图片被当作纯装饰性背景而未提供任何可发现来源。修复方向是让真实资源在初始 HTML 中就有明确来源，而不是依赖运行时行为。

本节的产出是一份图片来源清单，逐图记录：`src` 是否存在、`srcset` 候选是否有效、`sizes` 是否合理、懒加载属性与真实来源的关系、缺失项标记。

核对落地页上下文与可索引性

上一节确认了图片来源可被发现，本节回到承载它的页面：图片是否位于一个可索引、且有意义的上下文中。孤立存在的图片资源缺少语义支撑，即使 URL 与来源都正常，也难以被正确理解。

先确认页面索引状态。如果落地页本身不可索引，图片就失去了被引用的上下文，此时应优先处理页面层问题。再确认图片在页面中的位置：它是否出现在正文相关内容附近，是否有标题、段落或说明文字与之对应。图片优化类资料普遍把页面上下文、说明文字与可索引性放在同一组讨论中（见 [图片优化指南](https://searchengineland.com/guide/image-optimization-for-seo) 与 [图片 SEO 实操指引](https://yoast.com/image-seo/)），这说明上下文不是可选项。

需要避免的失败路径有三种。第一是孤立图片页：页面只有一张图，没有任何解释性文本，语义无从建立。第二是图片与正文主题无关，被当作填充元素插入。第三是页面可索引但图片位于被折叠、被延迟渲染的区域，导致上下文与图片的关联在初始状态中不成立。

本节还要为下一阶段准备输入：记录每张图片的 alt 与邻近文本的当前状态，但本节不做改写，只做记录。这样做的原因是，语义层的判断需要以“页面可索引且上下文成立”为前提，否则改好的 alt 也可能落在一个无效页面上。

本节的产出是落地页上下文检查项，逐图记录：落地页 URL、索引状态、图片在正文中的位置、是否存在对应标题或说明文字、是否属于孤立图片页、结论。

逐图验收记录表

以下表格用于把前四节的检查结果汇总到同一张记录上。请对每张目标图片复制一行，逐字段填写；未确认的字段留空并标注为未解决项，不要凭推测填写。

| 图片 URL | 可发现来源（src/srcset） | 图片 URL 状态 | 落地页索引状态 | alt 与邻近文本 | 尺寸与格式 | 图片站点地图覆盖 | CDN 响应 | 结论与未解决项 | | — | — | — | — | — | — | — | — | — | | | | | | | | | | |

使用这张表时注意三点。第一，前四列对应本文已完成的四层排查，填写时按顺序推进，不要跳列。第二，后四列属于后续阶段，本部分只要求你保留字段位置，不要提前下结论。第三，结论列必须写成可复核的陈述，例如“URL 状态异常，待托管侧修复”，而不是“已优化”。

本部分的排查顺序回顾

四节的依赖关系是单向的：图片与网页分开判断 → URL 可抓取 → 来源可发现 → 页面可索引且上下文成立。任何一层断裂，后续层的修改都无法被验证。因此当你发现某张图片仍未出现在图片结果中时，正确的做法是从第一节重新走一遍，而不是直接跳到语义或性能层。

写可验证的 alt 与邻近文本

走到这一步，你已经确认了图片 URL 状态、可发现来源，以及落地页是否处于可索引状态。语义层是下一个独立判断：即使图片能被抓取、能被发现、所在页面能被索引，alt 与邻近文本仍然可能让图片的语义变得模糊或自相矛盾。这一层的产出不是“写得更漂亮”，而是“写得可验证”——任何一个人拿到你的记录，都能判断这段文字是否准确描述了这张图片。

alt 属性的基本作用是提供机器可读的图片替代文本，它应当描述图片内容本身，而不是描述你希望这张图片排名的关键词（ZH10）。这条边界很重要：alt 不是关键词投放位。如果一张图片展示的是“银色不锈钢保温杯侧面开盖状态”，alt 写成“保温杯保温杯推荐保温杯品牌便宜保温杯”就同时违反了两件事——它没有描述图片，而且堆砌的关键词无法帮助任何读者或系统理解这张图。

邻近文本指的是图片周围的标题、图注、正文段落和链接文字。它的作用是补充 alt 无法承载的信息，例如这张图在论证什么、它属于哪个步骤、它与前后文的关系。判断一致性时，用下面这个对照方式逐图记录：

执行顺序建议是：先读 alt，再读邻近文本，最后读正文段落。如果三者指向的对象不同，优先修正 alt，因为它是图片自身最直接的语义来源；如果 alt 正确但邻近文本在描述另一张图，问题出在页面结构而不是 alt。

一个常见的失败路径是“为每张图都补一段关键词段落”。这会让邻近文本从语义补充变成重复堆砌，反而降低可读性。另一个失败路径是把 alt 留空并声称“装饰性图片不需要 alt”——装饰性图片确实可以留空 alt，但你必须先确认它真的是装饰性的，而不是承载信息的图片。这个判断要写进记录，不能默认。

证据边界需要说清楚：官方图片指南说明了图片发现、上下文与 alt 的作用范围，但没有给出“这样写就一定会被收录”的承诺（ZH1）。alt 属性资料属于背景性说明，不是 Google 的官方规则（ZH10）。因此这一节的结论只能是“语义是否一致、是否可验证”，不能写成“语义优化后收录概率提升”。

完成这一节后，每张目标图片都应当有一条可复核的语义记录。这条记录会成为下一节判断尺寸、格式与响应式交付的输入——因为响应式交付会改变浏览器实际加载哪张图，而语义记录里的 alt 必须与最终展示的那张图保持一致。

检查尺寸、格式与响应式交付

语义记录完成后，下一层是交付层。这一层要回答的问题不是“图片好不好看”，而是“浏览器实际加载的是哪张图、以什么尺寸和格式加载、这个加载路径是否仍然保留了可发现来源”。

尺寸检查的起点是展示位置。先量出图片在页面上的实际渲染宽度，再对照源文件宽度。如果源文件宽度远大于渲染宽度，说明存在不必要的传输体积；如果源文件宽度小于渲染宽度，说明图片会被放大显示，可能影响观感。这两种情况都要记录，但不要在这一步就下结论说“必须压缩”——先记录事实。

格式检查要区分两件事：文件格式本身，以及服务器返回的内容类型。格式影响加载表现，但格式选择没有唯一正确答案，取决于图片内容和你的交付能力。记录时写清楚当前格式、文件体积，以及是否使用了现代格式。

响应式交付是这一节最容易出问题的地方。当页面使用 srcset 与 sizes 时，浏览器会根据视口和像素密度从多个候选来源中选择一张加载（ZH8）。这意味着：你在 HTML 里写的那个 src 可能不是浏览器实际加载的那张图。

如果候选来源中的某个 URL 返回错误状态、指向不存在的文件，或者缺少必要的尺寸描述，那么这张图片在部分设备上就可能加载失败——而你在桌面浏览器里检查时完全看不到这个问题。

因此响应式交付的检查必须包含：

1. 列出 srcset 中所有候选 URL，逐个确认可访问。 2. 确认 sizes 描述与页面实际布局一致，避免浏览器选错候选。 3. 确认 src 回退来源存在且有效，作为不支持 srcset 时的兜底。 4. 记录每个候选 URL 对应的实际文件尺寸。 5. 在至少两种视口宽度下确认最终加载的是哪个候选。

失败路径有两种典型形态。第一种是 srcset 里混入了已删除或已改名的图片 URL，导致部分设备加载失败。第二种是只写了 srcset 而省略了有效的 src 回退，使不支持该特性的环境拿不到图片。两种都要在记录里标注为“未解决项”，而不是直接跳过。

性能视角可以补充判断，但不要越界。LCP 优化资料讨论的是显著图片与资源发现的关系（ZH9），它可以帮助你判断某张图片是否属于需要优先加载的资源，但它不回答“这张图片是否会被收录”。把性能结论写进性能栏，不要写进收录栏。

这一节的产出是每张图片的尺寸、格式与响应式交付记录，其中必须包含“浏览器实际加载的候选 URL”这一项。它直接决定下一节图片站点地图该覆盖哪些 URL。

用图片站点地图补充发现路径

图片站点地图的作用是提供一条额外的发现路径，它有特定的语法要求（ZH2）。这里必须先建立一个边界认知：站点地图是补充，不是替代。如果图片本身没有出现在任何页面的可抓取 HTML 中，单靠站点地图并不能保证它被收录；站点地图只是把图片 URL 明确地告诉抓取系统，减少“因为链接路径太深而没被发现”的情况。

检查站点地图时，按下面的顺序核对：

1. 确认站点地图文件本身可访问，且返回正常状态。 2. 确认语法符合图片站点地图的要求，图片条目嵌套在对应的页面条目下。 3. 确认每个图片条目中的 URL 与页面实际使用的图片 URL 一致——包括响应式交付中实际加载的那个候选 URL。 4. 确认目标图片确实出现在站点地图中，而不是只覆盖了部分图片。 5. 记录站点地图的提交状态与最近一次核对时间。

覆盖范围是这一节最容易出错的地方。如果页面使用响应式交付，而站点地图只列了 src 中的那个 URL，那么浏览器实际加载的其他候选 URL 就没有被站点地图覆盖。这不一定是错误，但你必须知道并记录这个差异，而不是假设“站点地图列了图片就等于全部覆盖”。

另一个失败路径是把站点地图当成修复工具：图片没被收录，就往站点地图里加一条，然后认为问题解决了。正确的做法是先回到前面的层——URL 状态是否正常、图片是否在可抓取 HTML 中可被发现、落地页是否可索引——只有这些层都通过之后，站点地图才是有效的补充。

证据边界：官方文档说明的是图片站点地图的语法与发现指引，不保证收录结果（ZH2）。图片搜索帮助页同样是一般性说明，不含排名承诺（ZH3）。因此这一节的结论只能写成“站点地图是否覆盖目标图片、语法是否有效”，不能写成“提交站点地图后图片会被收录”。

这一节的产出是图片站点地图覆盖清单，标注每张目标图片是否被覆盖、覆盖的是哪个 URL。它决定下一节 CDN 验证要检查哪些 URL。

验证 CDN 与分发路径

如果站点地图覆盖的 URL 与实际分发的 URL 不一致，前面的检查就会失效。CDN 是这一层的主要变量：它可能改写图片 URL、改变响应头、或者对同一张图片在不同边缘节点返回不同内容。

验证的核心是“源站看到的”和“用户与抓取系统看到的”是否一致。按下面的顺序执行：

1. 记录源站图片 URL 与 CDN 对外 URL 的映射关系。 2. 对 CDN URL 发起请求，确认返回正常状态码。 3. 确认返回的内容类型与图片格式匹配。 4. 确认返回的内容确实是目标图片，而不是占位图或错误页。 5. 在至少两个不同网络环境下重复请求，观察响应是否一致。 6. 记录任何源站与 CDN 之间的差异。

失败路径有三种常见形态。第一种是 CDN 返回了 200 状态码但内容是错误页，这会让状态检查通过而实际图片不可用。第二种是 CDN 对图片 URL 做了重写，导致站点地图或 HTML 中记录的 URL 与实际分发的 URL 不一致。第三种是 CDN 缓存了旧版本图片，源站已更新但分发仍是旧内容。三种都要记录为未解决项。

这里要特别强调一个判断边界：CDN 响应正常不等于图片会被收录。官方图片指南说明的是图片发现与上下文，不涉及分发层的收录保证（ZH1）；图片搜索帮助页也不提供这类承诺（ZH3）。CDN 验证的结论只能是“分发路径是否可用、是否与记录一致”。

这一节的产出是 CDN 响应验证记录，包含源站 URL、CDN URL、状态码、内容类型和差异说明。它和前面各节的记录一起，构成下一节汇总表的输入。

汇总逐图验收记录

前四节各自产出了一份局部记录。这一节的任务不是重新检查，而是把局部记录合并成一张逐图验收记录表，让每张图片的完整状态在一行内可见，并明确标出哪些项已通过、哪些项未解决。

合并时遵循一个原则：只记录观察到的结果，不记录推断。例如“图片 URL 返回 200”是观察，“图片应该能被收录”是推断，后者不写入结论栏。同样，排名或流量变化不能作为优化生效的证明——它们受太多变量影响，无法归因到单张图片的某一项修改。

逐图验收记录表使用下面的字段结构。这是一张空白模板，按你的实际图片逐行填写：

填写时注意几个容易混淆的字段。“可发现来源”要写清楚这张图是通过 src、srcset 中的哪个候选、还是其他方式被发现的，因为不同来源对应不同的检查路径。“图片 URL 状态”和“落地页索引状态”必须分开填写，因为图片收录与网页收录是两套独立判断，一张图片 URL 正常不代表它所在的页面可索引，反过来也一样。

“结论与未解决项”要写成可复核的句子，例如“URL 状态正常，alt 与图注一致，srcset 中第二个候选返回 404，待修复”，而不是“基本正常”。

汇总完成后，按依赖顺序决定修复优先级：先修复图片 URL 状态与可发现来源，因为这两项不通过时，后面的语义、尺寸、站点地图和 CDN 检查都没有意义；再处理语义与交付项；最后处理站点地图覆盖与 CDN 差异。每修复一项，回到对应行更新记录，并保留修改前后的对照。

未解决项不要删除。它们是你下一轮复核的起点，也是判断“这次排查是否真的完成”的依据。如果一张图片的未解决项里仍然有 URL 状态或可发现来源问题，那么这张图片的验收就没有通过，无论其他字段看起来多完整。

证据边界同样适用于汇总表：官方文档说明的是发现、语法与上下文，不提供收录或排名保证（ZH1、ZH2、ZH3）。因此这张表的用途是记录可验证的排查结果，不是预测图片在搜索结果中的表现。

下一步

按这张逐图验收记录表，从图片 URL 状态与可发现来源开始逐层填写；每修复一项就更新对应行并保留修改前后对照，未解决项留待下一轮复核。