json-ld必须用标签,置于head或body顶部,内容为纯json;@type需精准匹配页面类型并满足强制字段;多实体推荐用@graph数组平级声明;须服务端渲染且用google url inspection tool验证。

JSON-LD 的 script 标签必须写对类型和位置
不是随便放个 script 就行。必须用 <script type="application/ld+json"></script>,且内容只能是纯 JSON —— 不能有 JS 变量声明、不能有注释、不能用单引号、不能有尾逗号。
它可放在 或 顶部,但不能嵌在另一个 script 里,也不能被 JS 动态插入(Googlebot 不执行 JS,2026 年仍如此)。
- 错误写法:
const data = { "@context": "https://schema.org" };—— 这是 JS,不是 JSON-LD - 错误写法:
"url": "./logo.png"—— 相对路径,搜索引擎无法访问 - 错误写法:
"datePublished": "2026-05-10"—— 虽然合法,但缺时区易被忽略;推荐带时区的 ISO 8601,如"2026-05-10T12:00:00+08:00"
@type 选错就等于没写:按页面真实内容匹配最细粒度类型
硬套 Article 或 WebPage 很难触发富摘要。Google 明确偏好语义更精确的类型,比如博客正文页该用 BlogPosting,产品页必须用 Product,个人主页优先用 Person。
每个类型有强制字段,漏一个,整段标记可能被忽略:
-
BlogPosting:必须含headline、datePublished、author(且author至少带@type和name) -
Product:必须含name、offers(内含price和priceCurrency)、image -
Person:推荐带sameAs数组(GitHub、LinkedIn 等),image字段若存在,应为ImageObject对象,含url、width、height
多个实体共存时,用 @graph 数组比嵌套更稳
一个页面常同时描述文章、作者、网站、面包屑 —— 别试图塞进一个对象里,也别用多段独立 script。Google 支持 @graph 数组,把不同实体平级列出,关系靠 @id 和 mainEntityOfPage 等字段维系。
例如博客页常用结构:
{
"@context": "https://schema.org/",
"@graph": [
{
"@type": "WebPage",
"@id": "https://example.com/post#webpage",
"url": "https://example.com/post"
},
{
"@type": "BlogPosting",
"@id": "https://example.com/post#blogposting",
"mainEntityOfPage": { "@id": "https://example.com/post#webpage" },
"headline": "标题",
"author": { "@id": "https://example.com/#person" }
},
{
"@type": "Person",
"@id": "https://example.com/#person",
"name": "作者名"
}
]
}
这样既避免字段冲突,又让实体间引用清晰,Search Console 解析成功率明显更高。
本地验证不靠猜,直接用 Google URL Inspection Tool
别等上线再查。把完整 HTML 源码(含 script type="application/ld+json" 块)粘贴进 Google 的 URL Inspection Tool,它会实时标出 JSON 语法错、字段缺失、URL 不可达等问题。
注意两点:
- 测试前关掉广告屏蔽、隐私类浏览器插件,它们可能过滤掉
script标签 - SSR 框架(如 Next.js、FastHTML)必须确保 JSON-LD 在服务端渲染输出,而不是只靠
useEffect客户端注入
真正容易被忽略的是:同一份网站级数据(如 Organization、WebSite)只应在首页加一次,其他页面重复注入不仅冗余,还可能稀释主域权威信号。
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!











