Schema结构化数据设置：文章/产品/面包屑三种类型的JSON-LD代码示例

发布时间：2026-07-08 08:48 分类：SEO 优化作者：188mi 来源：互联网阅读：81

Schema 结构化数据里，文章、产品、面包屑三类最常用，用 JSON-LD 写在页面即可生效。下面按清单给出可直接套用的代码，并说明字段怎么与真实内容对齐。

清单 1：三种类型各管什么，先对号入座

三种类型的适用范围并不重叠，先对号入座再写代码，能省掉大部分返工。

Article：资讯、博客、教程、新闻详情页。它告诉搜索引擎哪段文字是正文、谁写的、什么时候发的。
Product：商品详情页。承载价格、货币、库存状态、评分与评价数量、品牌型号。
BreadcrumbList：任何有层级导航的页面都能加，把“首页 > 栏目 > 子栏目 > 详情”的路径显式声明出来，帮助搜索引擎理解站点结构。

一个页面允许同时存在多个 JSON-LD 块，也可以用 @graph 合并成一个，三种类型互不冲突。列表页、聚合页则不建议硬套 Article。

清单 2：Article 的必填字段与代码

headline、image、datePublished、author、publisher 是硬要求，缺一个就可能在富媒体结果里掉出来。

headline 与页面 H1 保持一致，不要为了塞关键词写成长句。
image 必须是绝对 URL，且允许爬虫抓取。
datePublished 用 ISO 8601 并带时区；dateModified 只在内容实质更新时才改。
author 指向真实作者页，publisher 的 logo 用可公开访问的方形图。

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "页面标题，与 H1 一致",
  "image": ["https://example.com/cover.jpg"],
  "datePublished": "2025-05-01T09:00:00+08:00",
  "dateModified": "2025-06-11T10:20:00+08:00",
  "author": {
    "@type": "Person",
    "name": "作者名",
    "url": "https://example.com/author/1"
  },
  "publisher": {
    "@type": "Organization",
    "name": "站点名",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/post/132"
  }
}

清单 3：Product 最容易出错的几项

Product 的报错率明显高于另外两类，问题几乎都出在价格和库存上。

price 用页面真实展示的售价，促销价与划线原价分开填，不要写“面议”“起”这类无法解析的文本。
priceCurrency 写三位货币代码，人民币是 CNY。
availability 使用 InStock、OutOfStock、PreOrder 等标准枚举；缺货页面继续标 InStock 属于典型造假。
aggregateRating 只在页面真的展示评分时使用，ratingValue 与 reviewCount 要和页面数字对得上。
一页多规格、多卖家时改用 AggregateOffer，给出 lowPrice、highPrice、offerCount。

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "商品名称",
  "image": ["https://example.com/p/1.jpg"],
  "description": "商品简介，与页面描述一致",
  "sku": "SKU-001",
  "brand": { "@type": "Brand", "name": "品牌名" },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/p/1",
    "price": "199.00",
    "priceCurrency": "CNY",
    "availability": "https://schema.org/InStock"
  }
}

清单 4：BreadcrumbList 的顺序必须与页面一致

面包屑的关键是顺序和真实。每一层对应一个 ListItem，position 从 1 开始递增，item 指向该层级真实可访问的 URL，最后一项是当前页面本身。

层级以页面实际渲染出的导航为准，移动端与 PC 端不一致时按用户看到的那份写。
页面上面包屑不可见、结构化数据里却写完整路径，容易被判定为作弊。
首页这一层可以省略，但从栏目开始必须逐级完整，不能跳级。
路径带参数时，item 里保留规范化之后的版本。

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "首页", "item": "https://example.com/" },
    { "@type": "ListItem", "position": 2, "name": "SEO 优化", "item": "https://example.com/seo/" },
    { "@type": "ListItem", "position": 3, "name": "Schema 结构化数据" }
  ]
}

清单 5：代码写在哪，怎么上线

手写和插件两条路都行，区别在于可控程度。

模板手写：在详情页模板的 head 末尾插入 script type="application/ld+json"。标题、时间、价格用变量输出，不要写死，否则全站详情页会共用同一份数据。
WordPress：在主题 functions.php 里挂 wp_head 钩子输出，或用 Rank Math、Yoast 自带的 Schema 模板改写。插件生成的字段仍要逐项核对，尤其是价格和评分。
自建 CMS：把 JSON-LD 拆成后台的 SEO 字段，让编辑能改标题、摘要、封面，价格与库存从商品表直接读取。
缓存：改完刷新 CDN 与页面缓存（阿里云 CDN 控制台 → 域名管理 → 刷新缓存；Cloudflare → Caching → Purge Everything），否则校验工具拿到的还是旧版本。

清单 6：验证与提交的先后顺序

上线前后各验证一次，能挡掉大部分低级错误。

语法校验：把代码片段粘到 validator.schema.org，看是否有字段类型错误、缺失 @context。
富媒体预览：用 Rich Results Test 检查页面是否符合展示条件，它会直接列出缺失的必填字段。
收录侧确认：Search Console → 增强功能，看有效项、警告项与错误项的数量变化；百度侧在搜索资源平台 → 数据引入 → 结构化数据，按类目提交并观察反馈。
回归复查：换模板、换主题、换插件之后一周内再看一次错误项，避免旧字段被清空或重复。

清单 7：常见失效原因自查表

字段写了，页面上却看不到对应内容，图文不符是最常见的降权理由。
图片用相对路径或已失效，爬虫取图返回 403。
时间格式写成“2025年5月1日”，解析失败。
把 Article 标在栏目页、把 Product 标在分类页，类型与页面性质错位。
同一页面里同类型重复声明，@id 相互冲突。
依赖页面加载后由 JS 注入，渲染引擎没执行到，等于没写。