结构化数据与GEO：应该标记什么，不该承诺什么

优先实施的类型

• WebSite与WebPage：表达站点和正式页面关系。
• Organization与Person：表达运营主体、作者和关联身份。
• Article：表达标题、作者、发布日期和修改日期。
• Dataset：为公开数据说明变量、许可、时间范围和下载地址。
• BreadcrumbList：表达清楚的栏目层级。

实施规则

JSON-LD中的名称、日期、作者、图片和描述必须能在页面上找到。不要把未公开客户、虚假评分或未经证实的资质藏进结构化数据。每次生成后进行语法与平台测试。

FAQ标记只在页面确实以问答帮助读者时使用，不为获得展示而复制同一组问题到大量页面。

官方边界

Google明确说明其生成式AI搜索不需要特殊Schema，结构化数据也不是准入要求。正确价值在于降低歧义和支持现有搜索功能，而不是绕过内容质量与可信度。

结构化数据只能描述页面已有事实

Article、Organization、Person、BreadcrumbList等标记应与页面可见内容一致。作者、发布日期、组织关系或评价如果只存在于代码中、正文却看不到，会给核验带来矛盾。

发布后应使用验证工具检查语法，并在页面改版时同步更新。标记通过验证只说明格式可读取，不代表搜索或AI平台一定展示，也不能替代正文质量与真实来源。

• 每页保持唯一规范URL和稳定标识。
• 作者与发布者关系在正文和披露页可见。
• 图片、日期和面包屑与实际页面一致。

从可见页面到结构化标记的检查顺序

先确认页面上真的能看到标题、作者、日期、组织名称、图片和正文，再用对应的Schema.org类型描述这些内容。文章页可以使用Article与BreadcrumbList，组织和人物页可以分别说明名称、URL与关系；不存在于页面或无法证明的奖项、评分、客户数量不应只写进标记。

标记生成后需要通过语法验证，并抽查搜索引擎实际读取结果。页面标题、规范地址或作者变化时，JSON-LD也要同步更新。多套插件同时输出重复或冲突实体时，应保留一套清楚来源。结构化数据的价值是减少歧义和机器解析成本，不是获得展示或排名的保证。

• 可见内容与JSON-LD事实一致。
• 同一实体使用稳定的@id和正式URL。
• 日期反映真实发布与重要修改。
• 验证通过后仍要检查重复、冲突和过期信息。