JSON-LD必须用<script type="application/ld+json">标签，置于head或body顶部，内容为纯JSON；@type需精准匹配页面类型并满足强制字段；多实体推荐用@graph数组平级声明；须服务端渲染且用Google URL Inspection Tool验证。
JSON-LD 的 script 标签必须写对类型和位置
不是随便放个 script 就行。必须用 <script type="application/ld+json">，且内容只能是纯 JSON —— 不能有 JS 变量声明、不能有注释、不能用单引号、不能有尾逗号。
它可放在 <head> 或 <body> 顶部，但不能嵌在另一个 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）只应在首页加一次，其他页面重复注入不仅冗余，还可能稀释主域权威信号。
