八月底的一个下午，销售把一张截图甩到群里：某 AI 搜索在回答「我们的自动化灌装线能不能定制」时，正文引用的是我们官网，配图却是华南代理商的 logo。同一周，另一条回答里给贴标机产品配的图，是一栋和产品毫无关系的写字楼。官网内容没抄错，引用也对，图全乱了。这事我花了两天半排查、又用 45 天做对照验证，把 Organization 的 logo 和 Product 的 image 两条线全部重写了一遍。这篇把踩坑过程和修复代码原样交出来。

问题是怎么被发现的

先交代背景。我们是一家做灌装与贴标设备的厂商，官网是 ASP.NET Core 8 的 Razor Pages 项目，2024 年做过一轮 JSON-LD 结构化数据改造，Organization、Product、BreadcrumbList 都标了。改完之后在 Google 富结果测试里全绿，当时就觉得这事翻篇了。

GEO 的语境下，考核指标和 SEO 不一样。传统 SEO 看排名和点击，生成式引擎优化（GEO）看的是「AI 搜索回答里有没有引用你、引用的时候配没配对图」。市场部 8 月中旬开始做人工抽查，每天记录 20 个行业问题的 AI 回答，问题就是那时候浮出来的：

第四行最讽刺：自己的产品图被 AI 拿去配了竞品的回答。前三个错误的图，来源都不是我们的产品图库，而是官网上的「品牌位置」。

定位：从图片 URL 反推

AI 搜索的回答不会告诉你图从哪来，但把回答页面的 HTML 抓下来看 img 标签的 src，能看到图片来源域名的路径结构。我用浏览器直接保存回答页，对着 src 一条条筛，发现三类可疑 URL：

1. 代理商 logo，来自一张 partner-logo.png；
2. 写字楼照片，文件名是 about-us-building.jpg；
3. ISO 徽章，路径里带 certification-badge。

这三个文件全部出自我们自己的官网——partner-logo 在页脚合作栏，about-us-building 在关于我们，certification-badge 在页脚资质栏。也就是说，AI 引擎没有去外面乱抓，它在我们站内选图，只是选错了。

顺着这条线，我把首页、产品页、关于页的图片资源全部盘了一遍，抓出三个病灶。

病灶一：Organization.logo 用了 SVG

页面上品牌区用的是 SVG 文件 logo.svg，结构化数据里也直接写了这个地址。SVG 的问题在于：很多抓取管线对它的处理和位图不是一条路，矢量文件缩放不失控，但作为「品牌配图」被引用时，引擎更倾向取一张有固定宽高、能直接缩略展示的位图。logo.svg 取不到或不好用时，引擎就按自己的兜底逻辑另找一张「看起来最像品牌图」的图——页脚那张合作方 logo 就这么被顶上来了。

病灶二：Product.image 写成了懒加载占位

这个更隐蔽。前端的图片懒加载组件是这样用的：

@{
    // 产品图轮播：改造前的问题写法，保留作复盘对照
    // 图片真实地址藏在 data-src 里，src 只放灰色占位符
    // 后端拼出的是 JS 调用字符串，抓取方拿不到可读的 img 标签
    foreach (var img in Model.Images)
    {
        // img_lazy 返回形如 <div class="lazy" data-src="..."></div> 的空壳
        @Html.Raw($"img_lazy('{img.Url}', '{img.Alt}')")
    }
}

而 Product 的 JSON-LD 是从 Model.Images 直接序列化的，序列化时为了「省流量」，图片地址拼成了相对路径加一个懒加载标记。抓取方拿到 Product.image 时，得到的既不是能直接访问的完整地址，展开页面后又因为懒加载延迟，可能只截到灰色占位块。AI 引擎取不到合格的 image，就只能去页面其他地方「猜」一张。

病灶三：页脚第三方徽章密度太高

页脚资质栏放了六张小徽章（认证、合作、奖项），每张都带 alt 文字，其中两张 alt 里出现了公司名和「认证」字样。这些图在首页的「图-文-品牌」相关性信号里排名很靠前，因为它们紧挨着品牌词出现。AI 引擎做兜底选图时，这类图权重不低。

机制剖析：AI 引擎选图的优先级到底是什么

修复之前我把三类 AI 搜索的选图行为梳理了一遍，结论是它们大体遵循一个从结构化数据到页面内容的降级序列。这也是这次踩坑最值得沉淀的部分：配图错误大多不是引擎乱抓，而是你给的第一优先级字段不合格，引擎降级后按页面信号猜中的另一张图。

flowchart TD
    A[AI 引擎为品牌/产品选配图] --> B{Product.image 是否可用?}
    B -->|完整 URL 数组且可抓取| C[取 image 数组中的图片]
    B -->|缺失/相对路径/懒加载占位| D{Organization.logo 是否可用?}
    D -->|位图 URL 可访问| E[取 logo 作为品牌图]
    D -->|SVG 或不可索引| F[降级为页面启发式选图]
    F --> G[统计图片与品牌词的共现与位置信号]
    G --> H[页脚徽章/关于我们配图/合作伙伴 logo 被选中]

展开讲两层机制。第一层是字段优先级：Product 类回答优先读产品实体的 image 数组，品牌类回答读 Organization 的 logo，这两个字段都失效才会走第二层。第二层是页面启发式：引擎对页面内图片做位置加权（首屏、页脚、正文旁）和文本共现计算（图片 alt、周围文字与品牌词的距离），页脚徽章这种「贴着公司名和认证词」的图，在启发式里分数反而不低。

对照这个模型，三个病灶全部能解释：image 不合格走 logo，logo 是 SVG 再降级，页脚徽章在启发式里赢了。那张「我司产品图配竞品回答」的情况也说得通——竞品页可能引用或转载了我们的评测图，而我们的字段给不出更强的归属信号。

修复：三处代码改造

logo 字段：换位图、给足尺寸

logo 从 SVG 换成 PNG，按主流抓取方对品牌图的常见要求，我取的规格是宽度 600px、高度 60px 以上的横版 PNG（透明底另存一份白底版），放在 CDN 固定路径。Razor 里 Organization 的 JSON-LD 重写如下：

// Models/BrandJsonLdBuilder.cs —— Organization 结构化数据构建器
public class BrandJsonLdBuilder
{
    // logo 固定走 CDN 位图，禁止引用 SVG 或页面内装饰图
    // SVG 保留给页面视觉展示，结构化数据只喂 PNG 位图
    private const string LogoUrl = "https://cdn.example.com/brand/logo-600x120.png";

    // 每次首页渲染时调用，输出注入 <script type="application/ld+json">
    public JObject Build(string siteName, string homeUrl)
    {
        // logo 用 ImageObject 完整声明宽高，帮助引擎建立可索引的品牌图
        var logo = new JObject
        {
            ["@type"] = "ImageObject",
            // url 与 og:image、站点地图中的品牌图地址保持一致
            ["url"] = LogoUrl,
            // 宽高必须与真实图片一致，虚报会被部分引擎判为低质
            ["width"] = 600,
            ["height"] = 120
        };

        return new JObject
        {
            ["@context"] = "https://schema.org",
            ["@type"] = "Organization",
            // name 与页脚、关于页的公司全称保持完全一致，避免实体归一失败
            ["name"] = siteName,
            ["url"] = homeUrl,
            ["logo"] = logo
        };
    }
}

这里有一个细节：ImageObject 的 width/height 我一开始偷懒填了设计稿数值，和真实 PNG 差了 40px，后来统一用构建脚本读图片真实尺寸再注入，杜绝再改图忘改参数。

image 字段：全路径 URL 数组 + 真实可访问

Product 的 image 从「相对路径字符串」改成带域名全路径的 URL 数组，第一张图是主图，后面按参数图、场景图排序。构建逻辑：

// Services/ProductImageResolver.cs —— 产品图地址解析
public IReadOnlyList<string> Resolve(Product p, IHttpContextAccessor accessor)
{
    // 只取审核通过且能通过 HEAD 探活的图，防止 404 图进入结构化数据
    var valid = p.Images
        .Where(i => i.Status == ImageStatus.Published)
        .OrderBy(i => i.SortOrder)
        .ToList();

    // 强制拼全路径 URL：抓取方不应承担相对路径的解析责任
    var baseUrl = "https://cdn.example.com";

    return valid
        // 每个 URL 都做过 HEAD 探活，200 才放行
        .Where(i => _probe.Ok(baseUrl + i.Path))
        // alt 缺失的图直接淘汰，不给引擎留语义空洞
        .Where(i => !string.IsNullOrWhiteSpace(i.Alt))
        .Select(i => baseUrl + i.Path)
        // 主图 + 4 张辅助图，够用且不稀释信号
        .Take(5)
        .ToList();
}

配套把前端懒加载组件改成「src 放真实地址、loading=lazy 控制延迟」的标准写法，img_lazy 那套字符串拼接整个删掉。抓取方现在拿到的是一张不执行 JS 也能读到的 img。

alt 与文件名：给关键图一个稳定身份

最后是语义层。产品主图的文件名从 IMG_20240312_034.jpg 这类相机命名改成 automatic-filling-line-cip-model.jpg 格式，alt 统一为「产品全称 + 关键参数」的句式，页脚那六张徽章的 alt 里的公司名全部去掉，只保留徽章本身含义。

flowchart LR
    A[改造前] --> B[logo=SVG 相对路径]
    A --> C[image=懒加载占位字符串]
    A --> D[页脚徽章 alt 含品牌词]
    B --> E[引擎降级选图]
    C --> E
    D --> E
    E --> F[配图张冠李戴]
    G[改造后] --> H[logo=600x120 PNG + ImageObject]
    G --> I[image=全路径 URL 数组 + HEAD 探活]
    G --> J[徽章 alt 去品牌词]
    H --> K[引擎第一优先级命中正确图]
    I --> K
    J --> L[启发式降级也无高风险图]

45 天对照数据

改造 9 月 1 日上线，市场部的抽查样本继续按同样口径记录。45 天（9 月 1 日至 10 月 15 日）的数据如下，抽查共 900 条 AI 回答样本：

引用量的提升不能全记在改图上——同期我们还补了几篇参数对比内容，这个混杂因素我认。但配图正确率这个指标是干净的：字段没动内容，动的只有图的可索引性和归属信号，47 个百分点的改善基本可以归因于这次修复。

两个遗留问题记一下。一是仍有零星回答取到旧图，应该是缓存和镜像页面的滞后，10 月底再看一轮；二是 SVG logo 并没有删，页面视觉还在用它，只是结构化数据和 og:image 全部指向 PNG 位图——展示归展示，喂给引擎的归引擎。

几个容易误判的点

做这轮修复时绕过几个弯，写出来避免别人再踩。

一是别把锅扣给 AI 引擎的「乱抓」。我们一开始也以为是引擎的问题，甚至想过去各家反馈。抓着图片来源 URL 反推完才发现，三个错误图全都来自自己站内，字段不合格才是因，配图错误只是果。

二是 og:image 替代不了 image 数组。当时有同事提议「改 og:image 不就行了」，og:image 主要服务分享卡片场景，产品实体的图证据还是要回到 Product.image。两个都给，别互相替代。

三是 alt 不是随便填的关键词堆砌。见过同行把 alt 写成一长串关键词，这种图在语义信号里反而像噪音。「产品全称 + 关键参数 + 场景」一句话，比十个关键词有效。

往后看，多模态检索进入 AI 搜索的图选管线之后，图片本身的内容（而不是周围的文字）权重会继续上升，alt 和文件名是兜底，图不骗人才是根本。如果你的站点也在被「AI 配图张冠李戴」困扰，先按这篇文章的顺序抓一次回答页 HTML、反推图片来源 URL，大概率一天内就能定位到自己的病灶。欢迎在评论区交换你遇到的选图怪象，尤其是 SVG logo 和懒加载这两类。

参考与延伸

• schema.org logo 属性定义
• schema.org image 属性定义
• schema.org ImageObject 类型
• Google 搜索中心：Logo（Organization）结构化数据文档

GEO、AI搜索、JSON-LD、Schema.org、logo属性、image数组、ASP.NET Core、设备厂商AI获客