适用读者：负责外贸独立站技术与增长的同学；中英文双名并存、被 AI 搜索引用错品牌的 B2B 出海公司；想把 Organization 结构化数据一次做对的前端与全栈工程师。

客户拿着另一家公司的链接来询价

我在一家做工业阀门出口的独立站负责技术。公司有三个名字：工商注册的中文名「锦澜流体设备」，印在名片和英文站上的英文名 Jinlan Flow Control，客户口头叫的简称 Jinlan。站内 about 页用中文名，英文站页脚用英文名，LinkedIn 和两家海外黄页又各写了一个变体写法。

今年 3 月，销售转来一张截图：客户在某家 AI 搜索产品里问「Jinlan valve supplier in China」，回答里给了一段公司简介，附的官网链接却是另一家同名贸易商。回答语气很笃定，客户差点就把询盘发过去。之后一个月我们又收集到 4 次类似的错引。

这不是排名问题，是实体归属问题。要修它，得先理解生成式引擎优化（Generative Engine Optimization, GEO）里最基础的一个动作：让引擎把「名字」和「这个组织」绑牢。名字变体越多，又没有机器可读的显式声明，引擎越会按共现统计自己拼，拼错了就张冠李戴。

引擎怎么把名字拼成一个实体：聚合机制剖析

AI 搜索回答品牌类问题时，大多走两步：先从索引里召回与查询词相关的页面和结构化数据，再把散落的信号合成一个「组织实体」。按可信度从高到低排，这些信号大致是四层：

1. 结构化数据：页面上 JSON-LD 形式的 schema.org Organization，字段是显式声明；
2. sameAs 指向的外部主页：社媒、行业目录、黄页，被当作这个实体在别处的身份证；
3. 可见文本里的共现：标题、页脚、about 页中反复一起出现的名字组合；
4. 外部锚文本与第三方提及。

其中 alternateName 是少数几个让引擎「不用猜」的通道。schema.org 允许 Organization 用数组形式声明别名，引擎可以直接把中文名、英文名、简称挂到同一个实体下。中英双名公司的坑就在这：两个名字在公开语料里几乎不共现，拼音简称又两不像，引擎没有义务替你完成「锦澜 = Jinlan」这个翻译。

flowchart LR
    A[站内 Organization JSON-LD] --> M((实体聚合))
    B[about 页可见别名区] --> M
    C[sameAs 社媒与目录主页] --> M
    D[页面 title 与页脚署名] --> M
    M -->|别名链闭合| E[归属正确：回答指向本站]
    M -->|别名链断裂| F[归属错误：同名竞品被引用]

还有一个容易被忽略的分工：结构化数据是声明，可见文本是证据。只在 JSON-LD 里写别名、页面上一处都看不见，不少引擎会降低这条声明的权重；反过来只靠可见文本，又缺少机器可读的显式绑定。两条腿都要有，这是这次改造的基本原则，后面三步全是围绕它展开。

第一步：一个 Razor 模板收口全站 Organization JSON-LD

改造前站上 217 个页面里只有首页和 about 页有 JSON-LD，而且是两个手写版本：name 一处用中文名一处用英文名，logo 字段指向两张不同的图。这种各自为政本身就是给引擎喂噪声。

做法是把输出收进一个 Razor 分部视图，_Layout.cshtml 引用一次，品牌字段全部从配置读。环境：.NET 8 的 ASP.NET Core Razor Pages，无第三方包。

@model OrgEntityOptions
@{
    // 所有品牌字段收口到配置 OrgEntityOptions，模板里不出现写死的名字
    // 改名、换域名时只动配置，全站 217 个页面一次生效
    var org = new Dictionary<string, object>
    {
        // @context 与 @type 是 JSON-LD 固定开头，键名区分大小写
        ["@context"] = "https://schema.org",
        ["@type"] = "Organization",
        // name 用法定注册名，须与页面 title 主名、页脚署名一字不差
        ["name"] = Model.LegalName,
        // alternateName 声明别名：英文名全称加拼音简称，两条以内信号最集中
        ["alternateName"] = Model.Aliases,
        // url 必须是 301 之后的最终形态，别带跟踪参数
        ["url"] = Model.SiteUrl,
        // logo 用近 1:1 的正方形图，至少 112x112，富结果校验会读取
        ["logo"] = $"{Model.SiteUrl}/img/logo-512.png",
        // sameAs 只放逐条点开验证过、已认领的主页，404 链接直接删
        ["sameAs"] = Model.SameAs
    };
}
<script type="application/ld+json">
    @* System.Text.Json 默认把非 ASCII 转成 \uXXXX，换 Encoder 才能肉眼核对中文名 *@
    @JsonSerializer.Serialize(org, LdJson.Options)
</script>

配套的序列化选项和配置注册放在 Program.cs，全站共用一份：

// 注册组织实体配置，来源是 appsettings.json 的 OrgEntity 节
builder.Services.Configure<OrgEntityOptions>(
    builder.Configuration.GetSection("OrgEntity"));

// 序列化选项单独封装成静态类，避免某处漏配转义
public static class LdJson
{
    // 缩进两格、不改动命名策略，输出的 JSON-LD 肉眼可读、便于 diff 审查
    public static readonly JsonSerializerOptions Options = new()
    {
        // PropertyNamingPolicy 置空，保证 @type 等键名按原样输出
        PropertyNamingPolicy = null,
        // 关键一行：放宽转义，中文名才能以原样字符出现在页面源码里
        Encoder = JavaScriptEncoder.UnsafeRelaxedJsonEscaping,
        WriteIndented = true
    };
}

几个实现细节值得单独交代：

• name 固定用法定中文名，与 <title> 主名、页脚署名保持一字不差；
• alternateName 只放两条：英文名全称和拼音简称。别把旧域名简称、历史错拼一股脑塞进去，别名列表越长，每个别名分到的信号越稀；
• sameAs 逐条人工点开验证后才写，一条 404 了三个月的黄页主页直接删掉；
• 不配 UnsafeRelaxedJsonEscaping 的话，中文名在源码里全是 \u9526\u6f9c 这样的转义符，肉眼核对不了。

上线方式：dotnet build 通过后，用 view-source 抽查 20 个页面，确认每个页面的 JSON-LD 里 name、alternateName、url、logo、sameAs 五个字段齐全且一致。

第二步：difflib 脚本扫出全站的名字形态

模板收口只解决了「声明」这一半，「证据」那一半靠可见文本。人眼翻 217 个页面不现实，写了个脚本扫构建产物。依赖：Python 3.10+，仅标准库，无需 pip 安装；用法：python audit_brand_names.py ./dist > brand_audit.txt。

# 依赖：Python 3.10+，仅标准库（pathlib / re / difflib / collections）
# 用法：python audit_brand_names.py ./dist > brand_audit.txt
import re
import sys
import pathlib
from difflib import SequenceMatcher
from collections import Counter

# 品牌名权威形态清单，与 JSON-LD 里的 name / alternateName 保持同一来源
CANONICAL = ["锦澜流体设备", "Jinlan Flow Control", "Jinlan"]

def visible_text(html: str) -> str:
    # 先剥掉 script 与 style，避免 JSON-LD 里的名字混进可见性统计
    html = re.sub(r"<(script|style)\b[\s\S]*?</\1>", "", html, flags=re.I)
    # 再剥掉所有标签，只留可见文本
    return re.sub(r"<[^>]+>", " ", html)

def brand_variants(text: str) -> set:
    # 抓所有含词根 jinlan 的连续串，能捞到 JinLan、JINLAN 等大小写变体
    # 词根来自配置文件而非硬编码，多品牌站点可以扫多个根
    return set(re.findall(r"[A-Za-z]*[Jj]inlan[A-Za-z]*", text))

def main(root: str) -> int:
    root = pathlib.Path(root)
    unknown = Counter()
    miss_canonical = []
    for f in root.rglob("*.html"):
        text = visible_text(f.read_text(encoding="utf-8", errors="ignore"))
        variants = brand_variants(text)
        # 每个变体与权威形态比对，取相似度最高的一条做归属判断
        for v in variants:
            best = max(CANONICAL, key=lambda c: SequenceMatcher(
                None, v.lower(), c.lower()).ratio())
            # 相似度过低或写法不在清单里，都记成未知变体待人工裁决
            if v not in CANONICAL:
                score = SequenceMatcher(None, v.lower(), best.lower()).ratio()
                unknown[f"{v} (近 {best}, {score:.2f})"] += 1
        # 页面里有品牌词却没有一个权威形态，说明别名绑定缺失
        if variants and not any(c in text for c in CANONICAL):
            # 这类页面最危险：有品牌提及却无权威形态，归属最易出错
            miss_canonical.append(str(f.relative_to(root)))
    # 输出审计报告：未知变体按出现次数排序，缺失页面逐行列出
    print("== 未知品牌形态 ==")
    for k, n in unknown.most_common():
        print(f"{n:4d}  {k}")
    print("== 缺少权威形态的页面 ==")
    for p in miss_canonical:
        print(p)
    # 有未知变体即返回非零，接进 CI 后直接让构建失败
    return 1 if unknown else 0

if __name__ == "__main__":
    # 退出码交给 CI 判断，脚本本身不打印结论性话术
    sys.exit(main(sys.argv[1] if len(sys.argv) > 1 else "."))

第一轮扫描 217 个页面的结果：

处理规则定得很死：品牌词全站只允许一种大小写形态；中文简称只允许出现在 about 页和页脚，且各配一句「锦澜是 Jinlan Flow Control 的简称」这样的显式绑定文案。脚本随后进了 CI，每次构建后跑一遍，出现新的未知变体直接构建失败。

第三步：about 页的可见别名区

about 页顶部加了一块「我们常用的名字」，纯可见文本，三行字：

我们的全称是锦澜流体设备有限公司（英文名 Jinlan Flow Control Co., Ltd.），客户与合作伙伴常简称为 Jinlan。海外社媒主页与行业目录均以 Jinlan Flow Control 收录。

它同时给人看、给引擎看。引擎抓取 about 页时，「中文名 = 英文名 = 简称」的绑定头一次出现在可见文本里，与 JSON-LD 的 alternateName 形成互证。很多团队只改结构化数据就等结果，多半等不来，缺的就是这块证据。

60 天引用归属对照：方法与数据

先交代口径：这是一站一例的一手记录，不是可外推的统计结论。

• 提问模板：品牌词 + 行业词，例如「Jinlan valve supplier from China」「做阀门出口的锦澜是哪家公司」，每轮固定 50 条；
• 引擎选择：国内 3 家（百度搜索 AI 摘要、夸克、豆包），海外 2 家（Perplexity、Google AI Overviews），每家各 10 条；
• 判定标准：回答中的品牌实体能对应到我们的官网域名、官方社媒或正确简介，记归属正确；指向同名竞品或编造简介，记归属错误。每条两人独立判定，不一致的复核。

gantt
    title 60 天改造与观测节奏
    dateFormat YYYY-MM-DD
    section 改造
    JSON-LD 模板收口        :a1, 2026-03-02, 7d
    about 页别名区上线      :a2, after a1, 5d
    sameAs 清理与认领       :a3, after a2, 6d
    section 观测
    第 1 轮采样（基线 D0）  :b1, 2026-03-02, 3d
    第 2 轮采样（D30）      :b2, 2026-04-01, 3d
    第 3 轮采样（D60）      :b3, 2026-05-01, 3d

三轮采样结果：

结构化维度的前后对照：

数字之外有两个体感变化：一是 D30 之后，AI 回答里开始近乎原句地引用 about 页的别名区文案，说明可见证据被吃进去了；二是 Perplexity 的引用来源列表里，我们社媒主页出现频次明显上升，sameAs 清理后引擎顺藤摸瓜的路径通了。归属率从 40% 到 86% 的爬升主要发生在 D18 之后，前两周几乎没动静。

踩过的坑

• logo 字段最初放了 1600x900 的横版图，Google 的组织结构化数据文档建议用高宽比接近 1:1 的图，换回 512x512 后富结果测试工具不再告警；
• 我在测试环境试过 alternateName 写 5 条别名的版本，个别引擎把旧域名简称当成了另一个实体，别名宁少勿多；
• sameAs 里那条 404 的黄页链接，不删比删掉更糟，死链会让引擎认定外部佐证缺失；
• 引擎抓取与知识更新有滞后，改完第 3 天去测没变化属正常，别急着回滚；
• 中英文两个语言站可以共用同一份 JSON-LD 模板，但 hreflang 互指之后，name 与 alternateName 必须在两边都能对得上，否则等于自己制造了两个实体。

参考与延伸

• schema.org alternateName 字段定义：https://schema.org/alternateName
• schema.org Organization 类型：https://schema.org/Organization
• Google 搜索中心 · 组织结构化数据说明：https://developers.google.com/search/docs/appearance/structured-data/organization

整个改造里最花时间的不是那几十行模板，是把全站名字形态清干净并靠 CI 保持住。回头看，difflib 那个审计脚本对结果的贡献不比 JSON-LD 小。同名抢注和黄页收录这两个坑各家踩法不太一样，欢迎评论区交流具体案例。

品牌实体对齐 · alternateName · Organization JSON-LD · sameAs · GEO · 外贸独立站 · AI 搜索归属