结构化数据是不是越多越好

你大概觉得，结构化数据加得越全，机器越懂你。于是把公司、文章、问答几类一股脑塞进每个页面，连案例页和新闻页也铺上技术文章类型。结果反过来，铺得越满，机器越容易把同一家公司读成互相打架的几套信息。

这不是写得不够，是写得太多。最常见的错误，就是把同一家公司定义了三遍，机器合并实体时各取一半，地址是 A 地，电话是 B 号码，自己跟自己对不上。要不要做、做多少，不取决于你认得几类，取决于这一页是什么性质。

按页类型触发，别逐页铺满

判断法不复杂。先看这一页是什么，再决定输出哪一类，一页只输出该输出的，别在页脚把所有类型都堆一遍。

表里没列的，就别硬加。没有实体门店的远程交付业务，不必为了显得全去铺门店类。没有真的站内搜索页，就别加搜索动作字段，点了打不开，比不写更糟。观点型、解读型内容用 Article，有版本、有前置依赖、面向从业者的才用 TechArticle，全站一律套技术类型，类型判断会失真。

别靠数 @type 查重复定义

很多人判断有没有把公司写重，是去数页面里出现了几个 Organization 的 @type。这方法不对。合法的纯引用自己也带 @type，引用块里通常就一句类型加一个 @id，没有别的字段。数 @type 会把只引用不定义的块也算进去，越数越慌，最后把本来干净的页面改坏了。

正确的看法是盯住 @id。看同一个 @id 出现了几次，其中几次带着名称、地址、电话这些完整字段。同一个 @id 只在一处带完整字段，别处全是光秃秃的 @id，那是干净的，出现多少次都正常。带完整字段的超过一次，就是重复定义，哪怕两处一字不差，也算。机器合并时各取一部分，公司信息自己跟自己打架。本站把完整定义收在页脚一处，全站 43 处模板声明里，其余位置一律纯 @id 引用，就是按这条查的。

带分页地址的第二页第三页，单独查

还有一处最容易漏。模板在列表第一页跑得通，不代表分页也跑得通。分页带了偏移，循环的序号变量跟着变，判断条件容易失效，产出残缺结构，页面却不报错也不提示。

所以别只点开第一页就收工。带分页地址的第二页、第三页，要显式单独打开，把结构化数据取出来各验一遍。本站那次就是分页上出的岔子，第一页全好，翻到后面才露出来。写完就存档、再没重跑，这类问题当场就能挡住。

别人怎么做，分三档看

站外的做法也分三档，混着看会出事。

一类有规范词表和平台公开文档撑着，可以当依据。公开词表定义了各类该有哪些字段，搜索平台的公开文档写明了问答标记必须页面上真实可见。照着做就行，不用自己发明字段。

一类是行业里普遍在做、但缺公开验证的，只归纳、不当依据。把类型都堆上去，逐页内联一整块公司定义，觉得越多越显专业。这类看个方向就好，别拿来做验收标准。

还有一类有公开处理案例或明确争议，写进边界。标记了页面上根本不存在的问答，历史上确有站点因此被处理。同一实体多处完整定义引发字段冲突，也是公开讨论里常提的。这类做错了比不做更重。

什么时候不必这么做

纯静态小站，没几个页面，也没有文章页和问答页，页脚把公司和站点各定义一次就够了，非首页补一条面包屑，其余不必硬铺。只有后台发文权限、碰不到模板输出层的团队，把那张表拿去问服务商就好。验收标准落在富摘要一定出现上的，这套也给不了，结构化数据管不了展示效果，各家平台各有各的策略。

一句话的判断标准

按页类型触发，同一个 @id 的完整定义全站只留一处，分页地址逐页验过，做到了就是够用，再多加一类、多写一处完整定义，都是往自相矛盾那头走。

想自己把这几类逐项核一遍，结构化数据最小可用集的技术文档列了每类的触发条件、必填字段和三层验证，照着跑一次就清楚自己多铺了没有。