你复制了一段结构化数据，检测工具没有报语法错误。可代码里的作者还是模板人物，日期写着今天，正式页面上却根本没有这段输出。检测绿色，并没有完成这次工作。
添加结构化数据，先查页面已有标记，再把所属页面可核对的事实写进合适类型。JSON-LD通常是容易维护的形式；发布后还要验证正式URL、可见内容与字段是否一致。下面从一篇教学文章开始，写出一段可以逐项解释的代码。
先看页面已经输出了什么
打开目标页源码，搜索application/ld+json，并用验证工具查看它检测到的对象。也要留意页面是否使用其他结构化数据格式；没有找到JSON-LD，不代表一定没有任何标记。
WordPress的SEO插件、主题和其他功能插件，都可能输出部分对象。一个页面同时有文章、作者与面包屑是正常关系，多段代码也不自动意味着错误。真正要查的是：它们描述谁，关键字段有没有冲突，由哪个组件负责维护。
例如同一篇指南有两份Article，一份作者为李林，另一份沿用模板中的王某；一份保留首次日期，另一份每次访问都填当前日期。这时应先修输出源，而非继续安装一个插件“补齐Schema”。
把当前类型、标题、作者、日期与输出来源记下来。已有组件能够准确维护的内容，就沿原来源修；确实缺少的部分，再决定怎样增加。它与页面SEO检查中的正文、作者和版本维护应当一致。
这张概念图里的不同颜色代表输出不一致，不是要求网站只能有一个Schema对象。多个互相关联且事实一致的对象，可以共同描述页面。
把一篇文章的事实写成JSON-LD
先列事实，别从空模板猜字段
假设有一篇《机床日常点检指南》，作者李林。以下人物、网址、图片和日期全部是教学设定，不是跨境YOUNG或真实客户资料。
| 页面可核对的信息 | 要表达的字段 |
|---|---|
| 标题：机床日常点检指南 | headline |
| 作者：李林，页面可进入其作者介绍 | author的类型、名字和url |
| 首次发表：2026年10月10日09:00，北京时间 | datePublished |
| 实质修订：2026年10月21日14:30，北京时间 | dateModified |
| 展示与文章有关的点检配图 | image |
| 正式文章地址 | url及关联标识 |
选Article，是因为这页的主要内容是一篇指南。不要因为指南讨论设备，就把整篇文章标成正在出售的Product。类型要描述实际对象；具体功能需要哪些属性，以Google文章标记说明为准。
一段完整的教学代码
下面的HTML片段应作为结构化数据输出，不是显示给读者看的代码文本。使用前要把所有教学身份、时间、地址与图片换成目标页面的真实值，并先检查已有输出。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"@id": "https://example.com/guides/daily-inspection/#article",
"url": "https://example.com/guides/daily-inspection/",
"headline": "机床日常点检指南",
"author": {
"@type": "Person",
"name": "李林",
"url": "https://example.com/authors/li-lin/"
},
"datePublished": "2026-10-10T09:00:00+08:00",
"dateModified": "2026-10-21T14:30:00+08:00",
"image": "https://example.com/images/daily-inspection.webp",
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://example.com/guides/daily-inspection/"
}
}
</script>
这是一份基础Article教学片段，不是所有文章、所有搜索功能的字段全集。Google对Article列出适用的推荐属性；不要把每个推荐项都理解成不填就违法，更不要为了消除提示填入不存在的图片、作者资质或日期。
看懂三个容易抄错的地方
@context说明使用的词汇体系，@type说明对象类型。@id是给这个对象的稳定标识；示例用文章地址加片段区分Article对象与所属WebPage，并不要求页面真的出现一个同名可见栏目。
作者的名字只填实际作者姓名，介绍页链接用于帮助识别同一个人。不要把“由某某发布”“高级SEO专家”全塞进名字字段，更不能因为站点属于公司，就把真实个人作者改成公司名称。
两种日期也有不同含义。首次发布日期不应每次修订都变成今天；修改日期要反映实际更新。示例中的+08:00明确了时区，不能把北京时间数字原样标成UTC。图片则应代表这篇内容，实际可访问，并符合对应功能要求，不能用无关Logo充当文章配图。
未知字段先查资料。AI可以帮助把已确认信息编码，但不能替你生成一个看似完整的作者经历、评分或更新历史。
把代码交给正确的输出位置
在自建页面中，可以按受支持方式把JSON-LD放在所属页面的HTML里；Google支持页内标记，不需要另外创建空白页面存放它。结构化数据入门说明也建议选择容易实施和维护的形式。
WordPress优先检查现有SEO组件能否管理这篇文章。需要自定义时，由有权限的维护者使用可维护的模板、插件接口或代码管理方式，并限定目标页面。不要把上面的固定Article片段放进全站页眉，让商品页、联系页与每篇文章都输出同一篇点检指南。
有些编辑环境会过滤script标签，或者把代码作为可见文本显示。编辑器里保存成功，不代表正式HTML含有正确标记。输出后查看正式页，并用URL测试确认实际取得的内容。
对批量文章，标题、地址、作者、日期和图片通常应从各篇真实字段动态生成。动态生成也需要适当编码，不能靠把一段文字直接拼进JSON字符串。带引号的标题尤其容易暴露问题：标题本身可以有引号，但JSON必须正确转义。已有输出组件能可靠处理时，不必重新写一套平行实现。
验证代码，再验证正式网址
先查语法和对象，再查页面输出
代码阶段先确认JSON能够解析，常见错误包括中文弯引号、末尾多逗号、字符串引号没有转义，以及把HTML转义后的显示文本当原代码。本文教学片段单独做了本地JSON解析检查；这只能证明本地语法可解析，不能冒充Google远端测试或生产部署结果。
随后按目标功能使用富媒体搜索结果测试。它关注Google支持的功能；Schema.org中合法的其他对象，未必会作为这种功能显示。若提示缺字段，先核对象类型和当前功能要求，再补真实资料，不照着红黄数量盲填。
上线后改用正式URL测试。代码输入模式通过而URL没有检测到，优先查发布位置、脚本过滤、缓存、渲染或访问限制，而不是继续修改已经正确的逗号。如果页面无法被Google访问，可沿抓取与索引排查处理。
再把每个关键值对回读者看到的事实
即使工具检测有效，还要读页面核对：作者是否同一人，标题是否对应，修改日期有没有真实更新，图片是否相关。自动工具无法完整判断这些质量问题。Google结构化数据常规指南要求标记与页面内容相关、真实，不能添加误导信息。
| 观察结果 | 下一步 |
|---|---|
| JSON解析失败 | 修复具体语法位置，再解析 |
| 代码测试可用，正式URL无输出 | 查实际输出与访问路径 |
| 正式页有两份冲突Article | 找输出来源，统一该对象事实 |
| 输出与可见事实一致，测试无关键错误 | 保留发布记录，观察后续搜索处理 |
最后一行也不等于保证富结果。语法、事实与功能条件正确，才能进入后续处理；Google是否展示仍受搜索情境等因素影响。
完成记录写清目标URL、输出负责人、字段来源、测试方式与时间、当前结果。文章以后更换作者、地址或代表图片时，同步检查这些字段。如果已经出现结构化数据人工处置，应按专项修复与复核流程处理，普通代码测试不替代该流程。
常见问题
已装SEO插件，还要再装一个Schema插件吗？
先查现有输出能否表达实际对象与所需字段。已有组件能维护，就优先修原来源；确有缺口再选实现方式。多装一个插件不等于信息更完整，还可能多出冲突输出。
JSON-LD里的信息是不是不用给读者看？
代码格式本身不必作为正文展示，但它描述的内容应与读者能核对的页面事实相符。不能只在隐藏标记里声称不存在的评价、作者或产品条件。
能让AI直接生成代码，然后发布吗？
可以用AI编码已确认事实，但仍需核类型、字段与真实来源，检查既有输出，解析代码并测试正式URL。特别要替换教学网址、人物、图片与日期，不能因为代码格式完整就直接上线。
