你写了个脚本全站搜 Organization，数出十几处，判定重复定义太严重，准备大删。停一下。这十几处里绝大多数只有 @id 和 @type 两个键，是合法的纯引用，带 @type 是语法要求，不是又定义了一遍实体。照那个数删下去，删掉的全是把页面连到主体的线。
判断重复定义，数 @type 从一开始就错了。纯引用也带 @type，跟完整定义在类型词上长得一模一样。真正该看的是同一个 @id 有没有把 name、url 这些字段写全了两遍以上。
按 @id 归堆，一个数就够
别数类型词，按 @id 归堆。把全站所有 JSON-LD 节点按 @id 分成一堆一堆，每一堆里数带完整字段的有几个。一张表能说清怎么分。
| 看什么 | 完整定义 | 纯 @id 引用 |
|---|---|---|
| 字段 | name、url 等写全 | 只有 @id 与 @type |
| 同一 @id 下几处 | 恰好一处 | 可以多处 |
| 怎么处理 | 保留那唯一一份 | 不能删 |
表里第二行是判断标准。同一个 @id 的完整定义恰好一处就对，多一处是重复，一处都没有说明只剩引用没有定义，两种都得回去改模板。带 @type 的纯引用不受这个数限制，删了它，作者、面包屑、文章归属会一起断。
本站踩过的两个情形
本站把组织主体的完整定义收到一处，其余模板和首页 @graph 全改成纯 @id 引用。首页原来还留了一份字段不全的 Organization，删掉换纯引用之后，Organization 重复定义由首页 2 处降为 0 处。线上 27 块 JSON-LD 逐块解析通过 0 失败，但这是修完结构之后才拿到的结果。
先修的不是实体，是模板结构。页脚引用那行放得太靠前，后面的脚本全跑到收尾标签外面成了游离脚本，全站 369 页一度全有，降到 0 才谈得上别的。这种结构问题会让 W3C 校验只报一句「Stray start tag script」就中断，后面检查全作废，看着像只有一处错。还有两个容易认错的，文章页另有一个 Organization 指向编辑部锚点，是另一个主体不是重复；查结构化数据必须显式带 /insights_2/ 这类分页地址，只查列表首页会漏，本站分页地址修前解析失败、修后 0 失败，旧台账那句全站 0 失败就是漏查分页页才站不住。
公开做法，按证据分三档
一档有规范原文撑着，可以当依据。JSON-LD 规范把 @id 定为节点标识、@graph 用来并列节点、纯引用靠标识回指，这不是经验是定义，写字段照它来。2026 年 8 月发布的可信传播团体标准中关于信息生态治理的原则性要求也算这一档，写文字出处不加链接。
一档是行业里普遍在做、却拿不出公开验证的。页头页脚各放一份主体完整字段、靠数类型词自检、把校验器零报错当成实体已唯一，都属这类，只归纳做法，不当依据，不写效果倍数，不点名任何服务商。
还有一档已经有公开反例或争议。同页堆多个同类型主体节点、把一次校验通过当长期基线，公开讨论里都提过会读到互相矛盾的主体信息，或同一组提示重复跑得到的品牌列表高度不稳定。这类只能写进不必做，不能写成承诺。
哪几类情形不必这么做
全站就一个页面、不复用公共模板，完整定义放哪儿都只有一处，按 @id 归堆没有对象可查，写对一次就行。只有后台发文框、拿不到全站页面源码的团队，全站聚合这步做不了，把本页写法改对即可，别拿一页推全站。还有游离脚本没修、校验器报一处就中断时，先修结构，实体结论一律等修完再谈。某类页面要不要输出结构化数据，是另一套按页触发的规则，不在这一层。
收成一句话
别数 @type，按 @id 聚合，看同一个 @id 有几处把完整字段都写了一遍，恰好一处才对。
想把写法和按 @id 聚合的检查口径拿去照做，实体只定义一次的技术文档给了完整定义与纯引用两种可复制片段，和一套能当场跑的检查清单。