适用读者：负责企业官网前端、SEO 与站点地图的工程师，需要让品牌在 AI 回答里被正确引用归因的技术负责人，以及正在落地结构化数据的读者。

去年我们接了一个工业阀门企业官网改版的收尾活。客户在 AI 应用里问「做衬氟阀门的那家企业的官网是哪个」，回答的参考来源写成了域名拼音，隔了两天再问，来源栏干脆写「该官网」。品牌名四个字，从头到尾没出现过一次，而客户的官网 title 里明明写着这四个字。

问题不在内容质量，也不在域名权重。我们花了三天定位，结论落在首页的站点标识声明上：WebSite 结构化数据缺了 name 与 alternateName，og:site_name 和 <title> 里的品牌片段写法不一致，三个子域各自声明了三个不同的站点名。AI 引擎抓得到页面，但拿不到一个稳定的站点标识。

现场：先看引擎实际读到了什么

定位这件事的工具链不复杂，顺序比工具重要。第一步是 view-source 看首页原始 HTML，搜索引擎和 AI 抓取器拿到的是未执行 JavaScript 的那一版，React 组件里运行时注入的 JSON-LD 在大部分抓取场景下等于不存在。我们那个客户用了一个前端组件在 useEffect 里 document.head.appendChild 脚本标签，浏览器里 F12 看得见，curl 抓下来是空的。

第二步是 Google Rich Results Test 和 Schema Markup Validator 各跑一遍。前者报「未检测到可用的项目类型」，后者把首页那段 Organization 标成 name 缺失。两个工具给出的结论不同，原因也很直白：前者只认它支持的富媒体类型，后者做纯语法与属性校验。

第三步是把不同入口的标识字符串抄到一张纸上对比。这一步最容易被跳过，却往往是问题的真正答案。当时那张纸上写着六行：首页 title 是「衬氟阀门厂家_工业防腐设备定制 - 某某阀门科技」；栏目页 title 是「某某阀门科技 - 产品中心」；og:site_name 写的是「某某阀门」(少了「科技」两个字)；logo 的 alt 是空的；首页 JSON-LD 里 Organization.name 是完整的「某某阀门科技有限公司」；而 WebSite 节点压根没有。

六行里有五种写法，其中两种还是缩写。引擎要做的是从这些候选里挑一个能长期稳定的字符串，候选本身互相打架，它就只能退回到 host。

站点标识的候选来源与冲突表现

引擎读站点标识的候选来源不止一处，各自的可信度、覆盖范围和失效条件完全不同。把这张表贴在改版评审会上，比讲十分钟概念管用。

这张表里有一处细节值得单独说：WebSite.name 和 Organization.name 是两个不同节点上的属性，语义上一个是「网站的名字」，一个是「组织的名字」。企业官网的场景里两者通常写成同一个字符串，写不一致就等于告诉引擎「这个网站属于 A，网页里描述的组织是 B」。

原理剖析：品牌实体识别与引用归属（Entity Attribution）

引用归属（Entity Attribution）指的是引擎在生成回答时，决定把一段被引用的内容挂到哪个实体名下的过程。它和「抓取」「索引」是三件不同的事，很多团队卡住是因为把归属问题当成了收录问题处理。

链路上大概有四个判断点。

建立实体候选集。 引擎解析页面后，会从 JSON-LD、微数据、RDFa、meta 标签、<title>、正文标题、图片 alt 里收集命名候选，并按来源类型排优先级。结构化数据的权重高于 meta，meta 高于正文抽取。这里的关键是：只有来自结构化数据或站点级 meta 的候选，才会被当作站点级标识；正文里出现的品牌词只算内容信号，不算站点标识。

做实体消歧。 候选拿到手之后要判断它们是不是同一个东西。判断依据包括 @id 是否一致、url 是否互相指向、sameAs 是否共享同一组外部链接、字符串是否高度相似。@id 写成带域名的完整 URL 且全站不重复的做法在这里收益明显，再用 publisher 把 WebSite 与 Organization 连起来，消歧几乎是确定的。

按一致性与稳定性排序取舍。 冲突时引擎会看两个维度：一致性和稳定性。一致性指多个候选是否指向同一字符串，稳定性指这个字符串在不改版的情况下能维持多久。title 里的品牌片段每加一个栏目就要变一次，稳定性差；og:site_name 虽然稳定，但声明的意图是社交分享，一致性权重低。三个维度叠加后，WebSite.name 是最容易被长期采信的那个位置。

归属落地成引用格式。 确定实体之后，引擎在回答里输出引用时，会按「品牌名 + 页面标题 + 链接」的组合来组织。如果站点标识没定下来，它宁可用域名兜底，也不会冒险把正文里出现的第一个品牌词当成站点名——那可能是一个竞品名，也可能是一句宣传语。 这就是为什么修复后回答里的变化不是「多出现几次」，而是从「该官网」直接跳到完整品牌名。

多子域各自声明会带来什么

我们的客户有三个子域：主站 www、商城 shop、帮助中心 help。改版前三个团队各写各的，商城那边的 WebSite.name 写的是商城品牌名，帮助中心写的是「某某阀门科技帮助中心」。从引擎视角看，这是三个互不相干的站点。

flowchart TD
    A[抓取首页 HTML] --> B{页面是否存在 JSON-LD}
    B -- 存在 --> C[解析 WebSite 与 Organization 节点]
    B -- 不存在 --> D[回退读取 og:site_name 与 title]
    C --> E{WebSite.name 是否为空}
    E -- 为空 --> D
    E -- 有值 --> F[与 Organization.name 比对]
    D --> G[从 title 抽取品牌片段]
    G --> H{多个子域声明是否一致}
    F --> H
    H -- 不一致 --> I[判定为多个独立站点]
    I --> J[站点标识降级为 host]
    J --> K[回答里输出域名拼音]
    H -- 一致 --> L[绑定到同一个品牌实体]
    L --> M[回答里输出完整品牌名]

修复思路是给子域分层。主域上声明完整的 WebSite 与 Organization，@id 用带域名的完整 URL 锚定主域；子域上不再重复声明站点级节点，只在需要时用 isPartOf 指回主域的 WebSite 标识。这样三个入口仍然可以有不同的 title 和面包屑，但站点标识只有一个来源。

flowchart LR
    subgraph 改版前
        M1[www 子域] --> P1[WebSite.name 完整品牌名]
        N1[shop 子域] --> Q1[WebSite.name 商城品牌名]
        O1[help 子域] --> R1[WebSite.name 品牌名加帮助中心]
    end
    P1 --> S{实体消歧}
    Q1 --> S
    R1 --> S
    S -- 三个字符串互不相同 --> T[拆成三个站点实体]
    T --> U[引用归属分裂]
    U --> V[子域被引用时品牌名缺位]
    W[www 声明 WebSite 与 Organization] --> X[子域用 isPartOf 指回主域]
    X --> Y[实体收敛为一个]
    Y --> Z[任意子域被引用都输出同一品牌名]

改造：把站点标识收敛成一份可复用的输出

依赖与环境：.NET 8 / ASP.NET Core 8.0，Razor Pages 或 MVC 视图引擎，System.Text.Json 内置即可。结构化数据用 schema.org 词汇表，校验工具为 Schema Markup Validator 与 Google Rich Results Test。示例里的 // 注释只为讲解，JSON 规范不支持行注释，上线前需要移除或改用 JSONC 预处理。

// 首页 head 中输出的 JSON-LD，WebSite 与 Organization 通过 @id 互相锚定
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebSite",
      // 站点节点描述网站本身，name 是站点标识的首选来源
      // @id 必须写成带域名的完整 URL，且全站不重复，这是消歧最有效的一处
      "@id": "https://www.example.com/#website",
      // 与 name 同源的规范首页地址，建议保留末尾斜杠
      "url": "https://www.example.com/",
      // name 与 Organization.name 必须逐字符一致，包括括号与空格
      "name": "某某阀门科技有限公司",
      // alternateName 覆盖中文简称、英文名与常见误写
      "alternateName": ["某某阀门", "Moumou Valve"],
      // 声明主语言，避免中英混排被判定为内容属性不明
      "inLanguage": "zh-CN",
      // publisher 指回组织节点，把网站与组织绑成一个实体
      "publisher": { "@id": "https://www.example.com/#organization" }
    },
    {
      "@type": "Organization",
      // 组织节点与被引用的品牌实体一一对应，@id 需与 publisher 的取值一致
      "@id": "https://www.example.com/#organization",
      // 与 WebSite.name 逐字符一致，这里重复写是为消歧提供交叉验证
      "name": "某某阀门科技有限公司",
      "alternateName": "某某阀门",
      // 组织主页地址，通常与 WebSite.url 相同
      "url": "https://www.example.com/",
      // logo 建议用方形 PNG 或 SVG，并在 img 的 alt 里写同一个品牌名
      "logo": {
        "@type": "ImageObject",
        // 图片需可公开访问且不带查询参数，避免抓取端取到 403
        "url": "https://www.example.com/static/logo-square.png",
        // 宽高按图片实际像素声明，与文件不一致会被判为无效属性
        "width": 512,
        "height": 512
      },
      // sameAs 帮助引擎把多个平台的账号归到同一个实体
      "sameAs": [
        "https://weibo.com/example",
        "https://www.tianyancha.com/company/000000000"
      ]
    }
  ]
}

配置项集中放在 appsettings.json，视图层只做拼装，避免三个子域各写各的字符串。

// SiteIdentity.cs — 站点标识的单一数据源，装配进 DI 后在视图里直接读取
namespace Company.Web.Seo;

// 用 record 保证不可变，避免运行期被某个中间件改写
public sealed record SiteIdentity
{
    // 站点标识字符串只有这一个出口，任何模板都不得自行拼接品牌名
    // 与 WebSite.name、Organization.name、title 品牌片段共用同一个值
    public required string BrandName { get; init; }

    // 简称与英文名，落到 alternateName 数组
    public required IReadOnlyList<string> AlternateNames { get; init; }

    // 主域完整地址，用于拼 @id
    public required string HomeUrl { get; init; }

    // 稳定 ID，固定为 {HomeUrl}#website，不允许按子域变化
    public string WebsiteId => $"{HomeUrl.TrimEnd('/')}/#website";

    // 组织节点 ID，供 publisher 与 isPartOf 引用
    public string OrganizationId => $"{HomeUrl.TrimEnd('/')}/#organization";
}

// SeoRegistration.cs — 从配置绑定，并在多子域场景下强制同源
public static class SeoRegistration
{
    // 在 Program.cs 中调用：builder.Services.AddSiteIdentity(builder.Configuration);
    public static IServiceCollection AddSiteIdentity(
        this IServiceCollection services, IConfiguration config)
    {
        // 绑定强类型配置，缺失关键字段时在启动阶段就抛错
        var identity = config.GetSection("SiteIdentity").Get<SiteIdentity>()
            ?? throw new InvalidOperationException("缺少 SiteIdentity 配置节");

        // 品牌名两端空白会与 title 里的写法不一致，这里统一裁掉
        services.AddSingleton(identity with { BrandName = identity.BrandName.Trim() });
        return services;
    }

    // Razor 里调用：输出 head 中的 og:site_name
    public static string RenderOgSiteName(this SiteIdentity id)
    {
        // meta 的 content 与 JSON-LD 的 name 来自同一字段，杜绝写法漂移
        // 该标签需放在 head 内、og:title 之前
        return $"<meta property=\"og:site_name\" content=\"{id.BrandName}\" />";
    }

    // 子域页面使用：声明自己属于哪个站点，而不是重新定义一个站点
    public static string RenderIsPartOf(this SiteIdentity id)
    {
        // isPartOf 只引用主域 WebSite 的 @id，不重复声明 name
        return $"\"isPartOf\": {{ \"@id\": \"{id.WebsiteId}\" }}";
    }
}

Razor 布局页里的用法就一行：@Html.Raw(SiteIdentity.RenderOgSiteName())，放在 <head> 里 og:title 之前。同一份 BrandName 还要喂给 logo 的 alt 和 title 的品牌片段，title 拼接规则在改造里定成「品牌名 + 空格 + 栏目名」，不再允许写成「栏目名 - 品牌名」。

数据：改造前后品牌名在 AI 回答中的表现

改造覆盖了首页、产品中心、关于我们和帮助中心四个模板，第 8 周做了一次对照抽样。抽样的方式是固定 128 个企业相关问句，覆盖中文与英文两种提问，逐一记录回答的引用来源字段。

有一点需要说明：改造后剩下的 4 条错误全部出现在英文提问里，因为 alternateName 里的英文名当时用了两种拼写，第 9 周统一后又抽了一次，剩 1 条属于模型自身的回答漂移，站点侧不可控。这份数据的意义不在百分比本身，而在于它证明站点标识是一个两周内能改完、效果可观测的抓手。

误区澄清与趋势预判

第一个误区是把 WebSite 结构化数据当成收录开关。它不负责让页面被抓取，只负责给抓取到的页面一个站点身份。有团队为了提升收录量补 WebSite 节点，收录没动，标识倒是修对了。

第二个误区是认为 og:site_name 可以替代 WebSite.name。这两者的消费方不同，声明意图也不同。稳妥的做法是两者写同一个字符串，而不是二选一。

第三个误区是给每个子域都写一份完整的 WebSite 声明。子域越多，标识冲突越多，正确做法是让主域承担声明，子域只做 isPartOf 引用。

往前看一年，站点标识会从「加分项」变成「入场券」。中文 AI 应用对来源归属的展示越来越细化，从只给链接到给站点名加作者，再到区分官方来源与转载来源，判断依据都指向同一组站点级声明。改版窗口期是成本最低的时候，等引擎侧的判断规则稳定下来，再补就要重新等一轮抓取与重新消歧。

具体到执行层面，建议把这五处纳入改版验收清单：WebSite.name、Organization.name、og:site_name、title 品牌片段、logo 的 alt，同一次提测里比对字符级一致，多子域走 isPartOf 引用，@id 用带域名的完整 URL。这五处对齐，AI 引擎在归属一段内容时才拿得到稳定答案，回答里也就不会再出现域名拼音和「该官网」这种兜底写法。如果遇到 alternateName 与 title 互相干扰的案例，欢迎在评论区贴出实际抓取结果一起看。

参考与延伸

• schema.org 的 WebSite 类型定义，name、alternateName、publisher 的完整说明：https://schema.org/WebSite
• schema.org 的 Organization 类型定义，logo、sameAs、@id 的使用约定：https://schema.org/Organization
• Google Search Central 关于站点名称（site names）如何被识别与选取的官方文档：https://developers.google.com/search/docs/appearance/site-names
• schema.org 的 alternateName 属性说明，多语言与简称场景的参考：https://schema.org/alternateName

关键词：WebSite Schema, site name, 品牌实体, og:site_name, 结构化数据, 生成式引擎优化, AI优化AIO, Entity Attribution