JSON-LD结构化数据标记完整教程: 深度解析 上周有个做家装的公司老板发我一段代码，说他们每个页面都埋了JSON-LD，怎么AI搜索还是把他们的服务区域搞错。我打开一看，product类型标记的却是“Article”，字段里还混着作者名。我问他这代码哪来的，他说从同行网站复制下来改了个名字。 这种场景我见得太多了。很多人以为JSON-LD就是一段给搜索引擎看的“打卡代码”，贴上去就完事。实际情况不是那么回事。它更像你给AI搜索引擎递上去的一份结构化简历，对方能不能看懂、信不信，取决于你填的每一栏是否对得上。 # # 先搞明白JSON-LD到底在解决什么问题 JSON-LD说白了就是一段放在网页里的脚本，用Schema.org约定的词汇，告诉AI搜索“这个页面的主体是什么、有哪些属性”。你想想，搜索引擎爬虫看网页是一堆HTML文字，它要判断“这个页面是一家餐厅还是餐厅的菜单”，光靠自然语言理解有时候会闹笑话。结构化数据的作用，就是把这些判断提前跟机器说清楚。 跟过去用的Microdata、RDFa相比，JSON-LD最大的好处是不用改HTML结构，把代码单独塞进head或body就行。我刚开始做GEO那阵子，还碰到过开发坚持用Microdata，结果改一个字段要动整个模板，后来全改成JSON-LD，维护成本低了不少。 下面这个流程是我平时给客户梳理的标记落地路径，从确定内容类型到看效果，大概七个节点：
flowchart TD A[确定页面内容类型] --> B[选择Schema.org类型] B --> C[编写JSON-LD脚本] C --> D[嵌入页面头部] D --> E[用测试工具验证] E --> F[观察AI搜索结果变化] F --> G[定期复查与更新]这个流程看起来简单，但每一步跳过去都会留坑。比如有人直接跳过第一步，页面明明是企业服务，选了Product类型，AI搜索抓了之后发现对不上，干脆忽略标记。 # # 别急着改代码，先把你网站的内容类型理清楚 不同类型的页面要选不同的Schema。文章、商品、本地商家、FAQ、视频，这些是最常用的几类。选错类型，比不标记还麻烦。 上个月在徐汇一个做美容院的女老板那里，她说她网站加了一堆JSON-LD，但AI搜索里还是没有显示营业时间和地址。我一看，她用的是Article类型。我让她换成LocalBusiness类型，重新验证，一周后AI搜索结果里就开始出现门店信息和营业状态了。不是代码多高级，就是选对了类型。 为什么选错类型比不标记更糟？AI搜索引擎处理结构化数据时，会拿脚本和页面可见文本做交叉验证。如果类型标错，比如把服务页面标成产品，交叉验证失败，AI可能直接丢弃整个标记，甚至降低对页面的信任。这种信任降级连自然语言抓取都会受影响。这就是为什么我会先花时间把类型理清楚，而不是急着上代码。 对于生成方式，现在大致有三种路线。我在项目里都试过，各有各的毛病。 | 对比维度 | 手工编写 | 插件自动生成 | CMS内置模块 |
| 上手难度 | 需要懂基础JSON，前期慢 | 装了就出码，最快 | 跟随主题，中等 | |
| 灵活度 | 完全可控，字段能按业务写 | 只填基础字段，缺的得自己补 | 依赖平台支持，删改受限 | |
| 维护风险 | 改代码容易漏，但清楚改了什么 | 插件更新可能覆盖自定义 | 主题更新常覆盖，得备份 | 我一般建议：量大的平台型站点可以先用插件批量生成，但核心页面必须手动核一遍字段。你说这跟以前做SEO只贴个代码有啥不一样？完全两码事。 # # 从最基础的标记开始，一个页面不要贪多 做JSON-LD最怕一口气加十几种类型。一个页面堆太多反而让AI迷惑，它不知道主次。我的原则是一个页面一个主类型，搭配不超过一个辅助类型。 具体操作可以分五步走。 第一步，确定这个页面的核心目的是什么。产品页就标记Product，文章页就标记Article，门店页就标记LocalBusiness。别按自己想当然选，去Schema.org上查一下这个类型允许哪些字段。 第二步，写JSON-LD脚本时，至少把必填字段填全。比如LocalBusiness必须有name、address、telephone，Product必须有name和offers。我见过很多标记只填name和description，AI抓了之后没多少有效信息，权重自然上不去。 第三步，把脚本放进里，或者放在前。注意如果用了缓存插件，部署后记得清一次缓存，不然测试工具还是读到旧页面。 第四步，用Google官方的富媒体结果测试工具或者Schema.org验证器跑一遍。这里有个细节：测试工具显示“有效”不代表AI搜索就一定会采纳，只是语法和字段没毛病。但它至少能帮你排除低级错误。 第五步，提交到搜索引擎或者等自然抓取，然后观察AI搜索结果的变化。观察周期我通常建议两周。有些页面可能一周就见效，有些行业尤其竞争激烈的，一个月也未必有明显变化，这个我也不敢打包票。 注意一点：别把JSON-LD写得太复杂。我之前跟一个做技术的朋友聊过，他说很多公司喜欢把嵌套搞得很深，一个product里套十几个offer，AI解析时反而容易断掉。简单直接点，反而更稳。 # # 验证和持续维护比一次性部署重要 做GEO这几年，我最大的感受是：JSON-LD不是部署完就结束的。它会因为主题更新、插件升级、甚至后端改动被悄悄覆盖。 有个做餐饮的老板，两年前找我做过标记，当时效果不错。后来他自己换了个主题，没管JSON-LD，过了几个月AI搜索里的评分和地址信息全没了。他以为被搜索引擎惩罚了，其实只是代码丢了。 所以我的建议有四个： 1. 每月固定用测试工具跑一遍核心页面，记录报错变化。预期效果：能在问题发生的第一时间发现，而不是等AI搜索结果掉下去。 2. 新内容发布时，把JSON-LD验证和文案检查放在同一步，别事后补。预期效果：减少后期返工，尤其对团队协作的站点。 3. 核心页面只保留一个主类型，别堆超过两种。预期效果：AI搜索结果的信息一致性会好一些，误读概率下降。 4. 以Schema.org官方文档为基准，别直接复制同行的代码。预期效果：字段匹配度提高，不会被同行代码里的历史错误带偏。 这四条做下来，说实话不一定能让你的页面马上被AI推荐，但至少能把结构化的坑填得七七八八。 # # 几个被问得最多的问题 Q: 我做了JSON-LD标记，但AI搜索结果还是没变化，是不是代码写错了？ A: 不一定是代码问题。可能是页面还没被重新抓取，或者标记类型和实际内容不匹配。先检查代码有没有通过验证，再看页面文字和标记是否冲突。我遇到不少案例，代码没问题，但标题和标记各说各话，AI不知道该信哪个。（来源：名优达GEO） Q: 一个页面可以放多个JSON-LD吗？会不会被惩罚？ A: 可以放多个，但同一个类型不要重复标记。AI搜索引擎一般不会因为多个脚本惩罚你，只会忽略冲突的部分。我的习惯是一个页面一个主类型，辅助类型不超过一个。 Q: 用插件自动生成JSON-LD行不行？ A: 可以，但要看插件给什么字段。很多插件只填基础字段，缺的业务字段你还是得自己补。适合量大的站点，不过核心页面建议手动检查一遍。 Q: JSON-LD对普通网站还有必要吗，AI搜索引擎会自己读全文吧？ A: AI搜索引擎确实会读全文，但JSON-LD能告诉它哪些是实体属性，减少误读。尤其在做本地推荐和实体推荐时，结构化数据让AI少猜一点。 以上这些做法，是我在名优达GEO做项目时反复验证过的。没有包治百病的技术，JSON-LD只是AI推荐里的一环。但这一环做不扎实，后面很多优化都容易跑偏。 |