Structured data / JSON-LD
JSON-LD 到底有什么用？一篇给 AI 网站上线前读的结构化数据科普
从搜索引擎如何理解页面讲起，解释 JSON-LD 的真实作用、适用边界、常见误区，以及 AI/no-code 网站上线前应该怎么验证。
Open Schema Generator如果你用 AI 或 no-code 工具搭了一个网站，页面看起来可能已经很完整：有标题、有介绍、有按钮、有图片，甚至还有一整套漂亮的响应式布局。但搜索引擎看到的不是“漂亮”，而是一份需要被解析的文档。JSON-LD 的意义，就藏在这两种视角之间。它不是排名作弊器，也不是每个页面必须塞进去的 SEO 仪式，而是一种让机器更稳定理解页面事实的说明方式。
一个页面上线后，搜索引擎到底在读什么
人打开网页时，会先看版式、主标题、视觉重点和上下文；搜索引擎抓取页面时，则要把 HTML、链接、图片、脚本、状态码、canonical、robots 规则和内容语义一起拼起来。它当然能读 H1，也能分析段落，但它仍然要做很多推断：这个页面是文章还是工具？这张图是主图还是装饰图？这个日期是发布时间还是版权年份？这些问答是正文内容，还是导航里的常见问题？
传统 HTML 并不是为表达这些语义细节而设计的。它能告诉浏览器“这里有一个标题”“这里有一个段落”，却不总能清楚告诉搜索系统“这是一篇由某个作者在某天更新的教程”。当页面越复杂、模板越通用、内容越由 AI 生成时，这种模糊感会变得更明显。JSON-LD 要解决的，就是把一部分需要猜的东西，改成页面主动声明的事实。
JSON-LD 像是贴在页面旁边的一张机器说明卡
JSON-LD 的全称是 JavaScript Object Notation for Linked Data。听起来很学术，但落到网页里，它通常就是一段 type 为 application/ld+json 的 script。浏览器不会把它显示给用户看，搜索引擎、社交平台、知识图谱系统却可以读取它。你可以把它想象成页面旁边的一张说明卡：这个 URL 代表什么实体，它的名称是什么，主图是哪张，作者是谁，发布时间是什么，和站内其他页面有什么层级关系。
这张说明卡本身不创造内容。页面没有真实文章，写 Article 也不会让它变成好文章；页面没有产品价格，写 Product 也不会凭空获得商品富结果；页面没有可见问答，FAQPage 只是在描述不存在的东西。JSON-LD 的价值来自“确认”和“澄清”，不是“伪装”。它越忠实于页面，越有帮助；越像隐藏关键词区，越没有意义。
为什么 AI 和 no-code 网站更容易需要它
AI 建站工具最强的地方，是能很快生成一个看起来完整的网站。它也最容易留下一个问题：不同页面在机器眼里长得太像。首页、工具页、文章页、落地页可能共享同一个模板，同一批组件，同一种标题区，甚至同一段默认 SEO 设置。用户看得出页面差异，因为文案和布局足够直观；机器却可能需要更多信号，才能判断每个 URL 的真实角色。
no-code 平台还有一个常见坑：全站只配置了一段通用 Organization 或 WebSite JSON-LD，然后每个页面都继承它。这种做法不算错，但它只说明“这个站是谁”，没有说明“这个页面是什么”。一个 Schema 生成器工具页，应该比普通营销页多一些 SoftwareApplication、WebApplication 或工具用途相关的信息；一篇教程，则更适合 Article 或 BlogPosting；一组真正展示出来的问题和答案，才适合 FAQPage。页面级 JSON-LD 的作用，就是补上这些差异。
先选页面类型，而不是先复制代码
很多教程会直接给你一段 JSON-LD 示例代码，但真正可靠的顺序应该反过来：先判断页面类型，再决定 Schema。比如你正在写一篇“如何添加 JSON-LD”的教程，它主要是知识内容，Article 或 BlogPosting 是合理起点；如果页面同时有清晰的面包屑，可以再加 BreadcrumbList；如果文章末尾有用户可见的问答，可以考虑 FAQPage。每一种类型都应该能回答一个问题：它到底帮助机器理解页面的哪一部分？
不要把 Schema 当作越多越好的标签云。结构化数据不是给页面贴满“Article、FAQ、Product、SoftwareApplication、HowTo”的集合。一个页面如果没有步骤化操作，不要硬写 HowTo；没有价格和购买意图，不要硬写 Product；只是普通介绍文案，也不必强行包装成 FAQ。搜索引擎越来越擅长忽略不匹配的结构化数据，长期看，克制比堆砌更稳。
一段靠谱的 JSON-LD 应该和页面内容互相校验
写 JSON-LD 时，最重要的不是字段多，而是字段准。name 应该和页面标题保持一致或高度相关；description 应该概括页面真实内容，而不是写一段和 Meta description 完全无关的广告语；url 和 mainEntityOfPage 应该指向规范 URL，并与 canonical 对齐；image 应该是公开可访问、能代表当前页面的图片，而不是旧模板里的默认封面。
日期尤其值得认真处理。datePublished 表示首次发布时间，dateModified 表示最后实质更新，不应该每次构建都自动改成今天。对于多语言页面，JSON-LD 也要跟着语言变化：中文页用中文标题和描述，英文页用英文标题和描述，canonical 指向当前语言版本，inLanguage 也应该匹配。这些细节看起来琐碎，却决定了搜索系统能不能把页面、语言、图片和更新时间稳定连起来。
放在哪里不神秘，能被抓到才重要
JSON-LD 通常放在 head 里，但它并不必须只能放在 head。只要最终渲染出的页面里有 application/ld+json 的 script，搜索引擎能读取到，放在 body 也可以。对 Nuxt、Next、Astro 这类框架来说，更推荐在服务端渲染或预渲染阶段输出结构化数据，因为这样爬虫拿到 HTML 时就能看到它，不必等待复杂的客户端脚本执行。
这也是 AI/no-code 网站需要特别检查的地方。很多平台允许你在“自定义代码”“页面 head”“全局脚本”“嵌入组件”里添加代码，但不同入口的输出时机不一样。有些只在客户端挂载后出现，有些不会进入静态 HTML，有些在 CMS 模板里会被转义。上线后不要只相信编辑器预览，最好打开线上页面，查看源代码或渲染后的 DOM，确认 JSON-LD 真的存在，而且内容是当前页面的内容。
验证 JSON-LD，不只是看绿色通过
结构化数据测试工具能告诉你 JSON 是否能解析、字段是否符合某个 Schema 类型、是否缺少推荐字段。但这只是第一层验证。真正上线前，还要问几个更接近现实的问题：这个页面是否返回 200？有没有 noindex？robots.txt 有没有挡住？canonical 是否指向自己或正确的规范页？sitemap 里是否包含这个 URL？页面正文是否真的支持 JSON-LD 里声明的事实？
很多低质量页面的问题，不是 JSON-LD 写错了，而是页面整体不值得被信任。比如页面内容很薄，却写了完整 Article；页面上没有 FAQ，却写了 FAQPage；产品价格已经变化，JSON-LD 还是旧价格。测试工具可能不会替你判断这些语义问题，但搜索引擎会。把 JSON-LD 放进上线 QA 流程，而不是把它当作最后复制粘贴的一段代码，这是更可靠的做法。
什么时候不用 JSON-LD，反而更好
不是每个页面都需要复杂 JSON-LD。纯隐私政策、简单联系页、临时落地页、内容还没成型的测试页，通常不需要花很多精力写一大段结构化数据。对于这类页面，正确的 title、description、canonical、robots 和内部链接可能更重要。JSON-LD 应该服务于明确的页面实体，而不是为了让每个 URL 看起来都“做过 SEO”。
如果你只能记住一个判断标准，可以这样想：当页面上有一个值得被机器明确识别的对象，JSON-LD 就有意义。文章、产品、工具、组织、面包屑、活动、视频、真实 FAQ，都是典型对象。反过来，如果页面只是一个过渡页、薄内容页、重复模板页，先把内容和索引基础做好，再考虑结构化数据。好的 JSON-LD 是锦上添花，但前提是那块锦本身存在。