最稳妥方式是直接在或顶部插入块；必须用双引号、无注释、无尾逗号、@context为"https://schema.org"，article类型须含headline、datepublished（iso 8601格式）、author（对象含@type和name）等强制字段。
直接在 或 顶部插入一个合法的 <script type="application/ld+json"></script> 块，是定义网页结构化数据最稳妥、Google 解析成功率最高的方式。其他格式（如 Microdata、RDFa）容易因 HTML 结构变动或嵌套错误失效，不推荐新项目使用。
JSON-LD 脚本必须满足哪些硬性语法条件
Google 的解析器对 JSON 格式零容忍——错一个双引号、多一个逗号、带一句注释，整块就被跳过。
-
@context必须严格写成"https://schema.org"（注意是https，不是http，也不能少斜杠或大小写混用） - 所有键名和字符串值必须用双引号
"，单引号'直接报错 - 对象或数组末尾禁止出现尾逗号，例如
"name": "张三",中的逗号必须删掉 - 不能含任何注释（
//或/* */），JSON 规范不支持 -
<script></script>标签必须独立存在，不能被<div>、<code><!-- -->或其他<script></script>包裹Article 类型字段缺失会导致富摘要完全失效
只写
"@type": "Article"不够，Google 明确要求以下字段必须同时存在且类型正确：-
headline：字符串，需与页面<h1></h1>文本严格一致（否则交叉校验失败） -
datePublished：ISO 8601 格式字符串，如"2026-05-27T14:22:00+08:00"；仅写"2026-05-27"可能被部分解析器拒绝 -
author：必须是对象，不能是纯字符串；至少含"@type"和"name"字段（个人用"Person"，机构用"Organization"） -
image：必须是绝对 URL 数组，如["https://example.com/cover.jpg"]；相对路径或需登录访问的地址会失效
PHP 动态输出 JSON-LD 时最容易踩的坑
用 PHP 拼接 JSON-LD 时，常见错误不是逻辑问题，而是转义和序列化失控：
- 原始数据未用
htmlspecialchars($val, ENT_QUOTES, 'UTF-8')处理，导致引号、反斜杠破坏 JSON 结构 - 调用
json_encode()时漏掉JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES，中文变 \uXXXX，URL 中的/变\/，可读性差且易出错 - 模板引擎（如 Twig、Blade）对
<script></script>内容二次转义，结果输出的是转义后的字符串而非原始 JSON - 多个实体（如 Article + Organization）强行合并成一个对象，应改用数组包裹多个独立对象
本地验证结构化数据是否生效的关键动作
别等上线再查——本地就能精准定位问题：
- 用 Google URL Inspection Tool（整合了 Rich Results Test），直接拖入 HTML 文件或粘贴完整源码（含
<script type="application/ld+json"></script>块） - 测试前务必关闭广告屏蔽、隐私类浏览器插件，它们可能过滤掉
<script></script>标签 - 若用了 SSR 框架（如 Next.js、Nuxt），确保 JSON-LD 在服务端吐出，而不是靠
useEffect客户端注入——Googlebot 不执行 JS - 检查 Network 面板中该脚本是否返回 200 且 Content-Type 是
application/ld+json，避免被 CDN 或 Nginx 错误重写 MIME 类型
真正难的不是写出一段 JSON-LD，而是让每一页的字段值都和当前上下文实时对齐、不越界、不冗余。比如首页放
WebSite，文章页放BlogPosting，FAQ 页用FAQPage——类型选错，再合规的 JSON 也白搭。 -
