JSON-LD必须置于<head>末尾或<body>开头，使用<script type="application/ld+json">标签，内容为纯JSON，不可动态插入、不可嵌套在其他HTML标签内，且需服务端渲染。
JSON-LD 放在哪才能被 Google 稳稳抓到
必须放在 <head> 或 <body> 内部，不能套在其他标签里（比如 <div> 或 <template> 中），也不能用 JS 动态插入（如 document.createElement("script")）。Googlebot 抓取时基本不执行 JS，动态注入的 <script type="application/ld+json"> 极大概率被跳过。
常见错误现象：Search Console 显示“未检测到结构化数据”，但源码里明明有——十有八九是脚本块被 JS 插入、或被 SSR 框架延迟渲染（如 Next.js 的 useEffect）、或放在了 <noscript> 里。
-
<head>最稳妥，优先放这里 - 如果 CMS 或框架限制只能往
<body>注入，确保它在首屏 HTML 中（别等滚动或交互后才出现） - 绝对不要用
async、defer或type="module"，这些属性会让浏览器忽略application/ld+json类型
Article 类型触发富摘要的硬性条件
加了 "@type": "Article" 不等于能出富摘要。Google 只认三要素齐全的 Article：必须同时存在 headline、datePublished、author，缺一不可。
使用场景：仅限详情页（如博客正文、新闻稿），首页或列表页硬塞 Article 反而会被忽略，更适合用 WebPage 或 CollectionPage。
立即学习“前端免费学习笔记（深入）”；
-
datePublished必须是 ISO 8601 格式，例如"2024-05-20T09:30:00+08:00"；只写"2024-05-20"也行，但"2024/05/20"或中文日期会失效 -
author推荐用对象而非字符串：{"@type": "Person", "name": "张三"}；如果是机构，@type得是"Organization" -
image字段填的 URL 必须返回 200 状态码、可公开访问、且为绝对路径（https://开头）
为什么 JSON-LD 比 Microdata 更少翻车
Microdata 依赖 HTML DOM 结构，一旦 itemscope 嵌套错层、itemprop 写在错误父级、或属性漏掉，整块标记就失效；而 JSON-LD 是纯文本数据块，与 HTML 渲染完全解耦，SPA 页面切换路由、服务端渲染不稳定时也不受影响。
性能影响几乎为零——它不执行、不发请求、不阻塞渲染，但要注意别在每个页面都重复注入同一份网站级数据（比如 WebSite 信息），该用的地方才放。
- Google 对 JSON-LD 的提取成功率比 Microdata 高 15–20%，尤其在 React/Vue 项目中
- Microdata 容易因 CSS 框架类名变更、组件重构、甚至空格缩进变化而意外失效
- RDFa 更小众，调试工具支持弱，且属性命名规则更复杂（如
propertyvsitemprop）
本地验证时最容易忽略的三个细节
别等上线再查，用 Google 的 URL Inspection Tool（已整合 Rich Results Test）直接拖入 HTML 文件或粘贴源码，它能准确定位语法和语义问题。但很多开发者卡在验证前就失败了。
- JSON 必须用双引号，单引号（
'headline'）或末尾多逗号（"name": "xxx",）直接导致解析失败 -
@type拼写大小写敏感："BlogPosting"正确，"BlogPost"或"blogposting"全部无效 - 浏览器插件（尤其是广告屏蔽、隐私保护类）可能过滤掉
<script type="application/ld+json">标签，验证时务必禁用
真正麻烦的不是写不对，而是写对了但内容和页面实际不一致——比如 price 字段标了 99 元，页面上却是 199 元，Google 会判定为误导性标记，长期可能影响信任度。
