适用读者：负责企业官网技术侧、想弄明白为什么 AI 搜索总不引用自家站点的工程师；正在给 Organization 实体补结构化数据的开发；被市场同事追问「AI 里搜我们品牌词为什么出来的是别人」的技术负责人。

九月初，做工业检测设备的客户老周发来一张截图：他在某个 AI 搜索入口问自家设备的校准周期怎么定，答案引用了两家评测站和一个问答社区，官网那篇带完整校准规程的技术文档一个字没被提。他的问题不是排名掉了，而是更尴尬的一句——引擎是不是压根不信我们官网。

这事儿我当时没法直接回答，但手头正好有一个完整的观察窗口，就把「给 Organization 实体补信任类属性」当成一次正式实验来跑，记满 45 天。生成式引擎优化（Generative Engine Optimization, GEO）这个方向里，讲关键词和内容布局的文章很多，讲组织级可信信号构建的很少，这篇补的是后者的第一手数据。

先说清楚这轮改的是什么

schema.org 的 Organization 类型下面有一组常年没人填的属性：publishingPrinciples、ethicsPolicy、correctionPolicy、diversityPolicy、masthead。它们承接的不是一个字段值，而是一个个真实存在的页面——编辑准则、伦理声明、勘误流程、多元化声明。多数企业官网连这些页面都没有，JSON-LD 里自然也没得挂。

为什么挑这四个属性当主对象，而不是去堆 foundingDate、sameAs 这些已经被写透的属性？我的取舍有三条。这组属性在 schema.org 的定义里明确指向「组织的发布与操守规范」，和 AI 引擎评估「这个来源的内容能不能追责」直接相关；四个字段语义上互相印证——准则怎么执行、写错了怎么改、团队构成如何，一起挂的说服力比单挂一个强得多；实现成本极低，两个静态页加一个 JSON-LD 节点，一下午能上线，正好适合做对照实验。

表格里「页面要讲清楚的事」是整轮改造里我最看重的一栏，后面踩坑部分会展开——空壳页挂上链接，比不挂还难看。

动手前先测基线，留一组控制页

八月底到九月初，我们先固定了测量方法：12 个品牌词加 8 个业务问题，测 3 个主流 AI 搜索入口，每周三上午各测一轮，记录回答里有没有出现官网域名、有没有出现对信任页面的直接引用。基线结果不好看：36 个品牌词测试组合里，回答带官网链接的只有 3 组；24 个业务问题组合里，引用官网的只有 1 组，引用的还是一个论坛转载版，不是原页面。

控制组的设计是这样：correctionPolicy 和 diversityPolicy 两个页面照常写、照常发布，但 JSON-LD 挂链先不做，压满两周再挂。这样如果第 30 天勘误页开始被引用，就能把功劳算到「挂链」头上，而不是「页面存在」头上。说白了，不控制这一组，数据再好看也说不清是谁起了作用。

整个实验的流程如下图：

flowchart LR
    A[基线测试] --> B[撰写四个信任页面]
    B --> C[准则页与伦理页先挂链]
    B --> D[勘误页与多元化页暂缓两周]
    C --> E[JSON-LD 挂链全部上线]
    D --> E
    E --> F[每周固定测试并记录]
    F --> G[第 45 天出对照数据]

两个页面加一段 JSON-LD，代码这么落地

依赖与环境：.NET 8（ASP.NET Core Minimal API），序列化用内置 System.Text.Json，无第三方包。最终返回给爬虫的节点长这样：

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "衡致仪器",
  "url": "https://www.hengzhi.example.com",
  "publishingPrinciples": "https://www.hengzhi.example.com/editorial-policy",
  "ethicsPolicy": "https://www.hengzhi.example.com/ethics",
  "correctionPolicy": "https://www.hengzhi.example.com/corrections",
  "diversityPolicy": "https://www.hengzhi.example.com/diversity"
}

生产代码里我们没在页面模板里手拼字符串，而是做了一个独立端点统一输出：

// 依赖：.NET 8 的 ASP.NET Core Minimal API，序列化用内置 System.Text.Json，无第三方包
// 目标：Organization 节点挂在独立端点上，各页面布局用 partial 引进 head
// 配置：appsettings.json 的 TrustSignal 节绑定成强类型，四个 URL 集中管理
var builder = WebApplication.CreateBuilder(args);
builder.Services.Configure<TrustSignalOptions>(builder.Configuration.GetSection("TrustSignal"));
var app = builder.Build();

// 路由路径随意，关键是让整站每个页面的 head 都能带上这段
app.MapGet("/schema/organization", (IOptions<TrustSignalOptions> opt) =>
{
    var o = opt.Value;
    // IOptions 注入进 lambda，配置热更新不用重启进程
    // 字典键直接写最终属性名，省掉 C# 命名习惯到 snake_case 的映射配置
    var node = new Dictionary<string, object>
    {
        // 实体四要素：上下文、类型、名称、官网地址
        ["@context"] = "https://schema.org",
        ["@type"] = "Organization",
        ["name"] = o.Name,
        ["url"] = o.Url,
        // 信任四件套挂链处，全部给带域名的完整地址，相对路径部分解析器会忽略
        // publishingPrinciples 指编辑准则页，ethicsPolicy 指伦理声明页
        // correctionPolicy 指勘误说明页，diversityPolicy 指多元化声明页
        // 页面正文要与声明互相印证，空壳页是负信号，宁缺毋滥
        ["publishingPrinciples"] = o.EditorialPolicyUrl,
        ["ethicsPolicy"] = o.EthicsPolicyUrl,
        ["correctionPolicy"] = o.CorrectionPolicyUrl,
        ["diversityPolicy"] = o.DiversityPolicyUrl
    };
    // 序列化用默认选项，字典键原样输出，不需要额外命名策略
    var json = JsonSerializer.Serialize(node);
    // 生产环境这个节点内容稳定，缓存成字符串，别每个请求都跑一遍序列化
    return Results.Text(json, "application/ld+json");
});

// 上线后先跑一遍 Google 富媒体测试，确认字段都能被解析出来
app.Run();

挂链之外还有一步容易漏：把四个页面的 URL 提交进 sitemap，并在站点页脚给常驻入口。这些页面得是「正常可导航的站点内容」，孤岛页面的信号会弱很多。

原理剖析：AI 引擎怎么给来源打可信分

AI 搜索在回答一个问题之前，先要决定「信谁」。这个过程大致分三层，可以用下面这张图概括：

flowchart TB
    A[抓取候选片段] --> B[按来源聚合排序]
    B --> C{信任类属性是否存在}
    C -->|存在| D[抓取指向的准则页面]
    D --> E{正文与声明是否互相印证}
    E -->|一致| F[来源可信分上调]
    E -->|空壳或矛盾| G[信号降权]
    C -->|缺失| H[退回通用质量信号评估]

第一层是检索召回，从索引里捞出候选片段，这里比拼的主要是内容相关性和页面质量；第二层是来源排序，候选片段按来源聚合，引擎在这个环节给来源整体打分，参考信号包括域名历史、站点声明实体与实际内容的一致性、结构化数据的完备程度；第三层才是生成，被选中的片段带着来源署名进答案。我们改的这组属性，作用点在第二层。

publishingPrinciples 这类属性本质上是机器可读的自证声明。光有声明不够——引擎会顺着 URL 去抓准则页面，验证正文是不是真的兑现了声明。页面内容、站点行为、结构化数据三者对得上，来源可信分才涨得动。这也是空壳页无效的原因：声明和页面互相矛盾，属于负信号。

和 E-E-A-T 的关系可以这么理解：E-E-A-T 出自 Google 搜索质量评估指南，是给人工评估员用的概念，不是引擎里某个直接打分的字段。落到 AI 引擎的实现上，经验和专业性主要落在作者实体那边，而「可信赖」这一条，在组织层面最直接的机器可读载体就是这几个信任属性。这轮 GEO 改造等于是把 E-E-A-T 里的 T，从评估指南里的形容词，翻译成了 JSON-LD 里的一个 URL。

见效为什么慢：抓取有周期，信任页是新页面，从提交到被稳定收录要一两周；来源可信分也不是实时更新的，观察窗口拉到 45 天，数据才够稳。

45 天里实际发生了什么

第 0 天测完基线；第 2 天四个页面发布，勘误页和多元化页压住不挂链；第 4 天 JSON-LD 上线，sitemap 提交；第 7 天看抓取日志，编辑准则页已经被两个引擎的抓取端访问过。第 15 天第二轮测试，数据几乎没动，市场部开始问是不是白费劲，我的回复是再等两周。第 21 天控制组两个页面挂链。第 26 天，一个入口在回答「数据准确性承诺」相关问题时，第一次直接引用了勘误说明页。第 30 天，品牌词测试里带官网链接的组合涨到 6 组，两条回答的文本里出现了「该品牌公开的编辑准则」这类表述。第 45 天收口，对照数据如下：

几个值得单独说的观察。控制组页面在第 21 天挂链之前，两个引擎里都是零引用，挂链之后第 30 天起才有动静，这个先后顺序是我们把效果归因到挂链的主要依据。品牌词回答里官网链接从 3 组涨到 7 组，涨幅不算夸张，但回答里「官方准则」「公开的伦理声明」这类措辞从无到有，说明引擎确实读到了这些页面，并在生成时把它们当成了佐证材料。

踩过的坑，按代价从大到小排

代价最大的一条是页面质量问题。伦理声明第一版只写了三百字套话，挂链两周毫无动静；重写成一千二百字、写明具体审稿流程和商业内容标注方式之后，第 30 天才开始有反应。声明页面要按真实制度写，别按文案写。

第二条是相对路径。内部测试环境里我偷懒挂了相对 URL，联调时用解析器一跑才发现字段被忽略。全部换成带域名的完整地址，这类低级错误上线前用 Google 的富媒体测试工具能查出来。

第三条最冤：运维发新版时顺手给新页面加了 noindex，抓取日志里根本进不去，白等了小一周才查到。新页面上线，先确认可抓取再谈别的。

第四条是声明和行为不一致。准则里写了「四十八小时内响应勘误」，站上却既没有勘误入口也没有记录页，这种说到没做到的矛盾信号比缺字段更糟，后来补了公开勘误记录才算把话圆上。

第五条是实验设计层面的：别一次全挂。控制组让归因变得清楚，四个字段一天全上，事后说不清哪个起了作用，这份数据的复盘价值就没了。

两个误区和一个趋势判断

误区一：把信任属性当权重开关，挂上就等排名暴涨。它更像资格项——补齐了不一定马上涨，缺了在来源竞争里先矮半截。尤其当竞争对手是自带域名权重的评测站和社区时，组织级可信信号是官网为数不多能自己掌握的变量。

误区二：以为页面写了就行。引擎验证的是说到做到，准则页和站点实际行为对不上，反而拉低可信分。

趋势上，AI 搜索的来源池筛选正在从页面级质量往来源级可信上移，组织层的信任信号会从可选项慢慢变成入场券。现在补齐成本还很低，两个静态页加一段 JSON-LD 的事；等它变成硬门槛再做，头一波红利就轮不到你了。

技术上收个尾：两个静态页、四个属性、一个 JSON-LD 节点、一个 45 天观察窗口，这就是全部投入，换来的是品牌词回答引用率从 3/36 到 7/36。你那边如果也在跑类似对照，测法和数据欢迎评论区交流。

参考与延伸

• schema.org Organization 类型定义：https://schema.org/Organization
• publishingPrinciples 属性定义：https://schema.org/publishingPrinciples
• Google 搜索中心，结构化数据工作原理：https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data
• Google 搜索中心，Organization 结构化数据：https://developers.google.com/search/docs/appearance/structured-data/organization

生成式引擎优化、publishingPrinciples、ethicsPolicy、Organization Schema、信任信号、品牌词 AI 回答、JSON-LD