#JSON-LD
该话题下聚合了社区中所有标记为「JSON-LD」的公开帖子。
JSON-LD 的 @id 写错作用域，AI 摘录直接张冠李戴
2026/10/25上周跑批发现一个邪门问题：同一个产品页，AI 摘录里把「保修期」写成了「7天无理由退货」，还理直气壮引用了我们的 FAQ 段落。我一开始以为是模型幻觉，但把页面 JSON-LD 拉出来看，根子其实在 @id 的作用域上。 先定口径：我这次只验证「同一实体下多个问答节点是否共享了错误的 @id 前缀」
给Schema.org的FAQPage加了字段级权限控制，AI答案里终于不混入内部问答了
2026/10/24上周排查一个线上问题：客户官网的FAQ页面里混入了几条内部QA草稿，结果AI摘录时直接把「内部价获取方式」这种答案吐给了用户。查了一圈，发现是结构化数据没做字段级权限控制。 先定口径：FAQPage的mainEntity数组里，每个Question的acceptedAnswer.text字段，我们之
给Product schema的offers补了三个作用域字段，AI摘录价格终于不串店了
2026/10/24上周排查一个价格误读，AI把旗舰店价格和授权店价格混着摘，用户看到的价差能到 23%。 先定口径：AI 摘录价格时，到底读的是哪个 offers 节点？ 我拉了 200 个 SKU 的页面，用 JSON-LD 锚点逐个对： 只写 offers: {price, priceCurrency} 的，AI
给产品页加了个 JSON-LD 的 @id 锚点，AI 摘录准确率从 41% 拉到 79%
2026/10/24先定口径：我用同一批 60 条事实型问句，对客户 A 的 12 个产品页做两轮测试，每轮间隔 48 小时，相同 IP 段、相同提问模板，只统计 AI 答案里“产品参数与页面原文一致”的段落，算准确率。分母是 60×12=720 个参数位，不是答案条数。 第一轮基线 41.2%。问题不在页面速度，LC
JSON-LD里@type写成全路径后，富媒体抓取率从41%爬到78%
2026/10/23上周复盘了一个案例，产品详情页的富媒体结果抓取率卡在41%三周不动。用Rich Results Test跑了一遍，结构化数据本身没报错，但Search Console的「富媒体搜索结果」报告里，Product 类型的有效项只有一半。 拆开看，问题出在 @type 的写法上。我们之前图省事，实体类型直
AI把「防滑等级」答成「防滑」，我翻了国标才知道少写了个R
2026/10/23前两天帮一个做地砖的老客户看GEO效果，随手拿他们主推的防滑砖问了几家AI搜索：「这款砖防滑等级是多少？」结果三家AI齐刷刷答「防滑」，没一家带出具体等级。我当时就乐了——这不就是当年我做SEO的时候，详情页标题写「防滑地砖」、结果用户搜「R10防滑砖」死活搜不到的那个坑吗？ 客户自己也懵，说详情页
JSON-LD里@type写成简写，AI抓取时直接把价格字段截断了
2026/10/23上周排查自家商品页的GEO抓取异常，发现一个很隐蔽的坑：结构化数据里 @type 用了简写，导致AI在解析时把后面的 offers.price 字段直接截断。 现象 同一批商品页，用 Google Rich Results Test 检测全部通过，Schema 校验也没有报错。但把页面 URL 丢给
页面速度卡在LCP 2.4秒，我查了三天发现是JSON-LD字段顺序惹的祸
2026/10/22先说结论：JSON-LD 的字段顺序会影响解析耗时，进而拖 LCP。这个结论我一开始也不信，直到把 200 个页面的 Lighthouse 跑了一遍。 背景：我们站产品页的 LCP 一直在 2.4s 上下，Chrome UX Report 里「良好」比例只有 61%。页面本身不重，首屏图片 120K
JSON-LD 里 @id 和 url 谁先谁后，我实测抓取顺序差了 11 次
2026/10/22上个月我在调一个商品详情页的 JSON-LD，发现一个特别磨人的细节：@id 和 url 这两个字段的先后顺序，居然会影响 AI 抓取时对实体主键的识别。 先说场景。页面是标准的 Product schema，嵌套了 Offer 和 AggregateRating。最初我把 url 放在 @id 前
AI把「起订量」答成「库存量」，我拆了80条问句发现是单位没归一
2026/10/22这两天帮一个做五金的客户排查AI答错参数的事。他卖螺栓，客户在AI里问「最小起订量多少」，AI张口就答「5000」，其实那是库存量，起订量是500。 当年我做SEO的时候，这种坑见多了。产品页上「起订量」和「库存」两个字段挨着放，蜘蛛抓过去分不清，摘要里瞎拼。现在换成AI，毛病一模一样，只是换了个马
给产品页加JSON-LD后，AI抓错参数从17次降到6次，但字段顺序又踩了新坑
2026/10/22上周把一批产品页的 JSON-LD 从 Product 裸奔改成带 additionalProperty 的参数表结构，AI 答案里抓错规格的次数从 17 次降到 6 次（同一批 40 个问句重跑三遍取均值）。但降完我发现剩下的 6 次全卡在字段顺序上。 具体现象：参数表里 weight 和 net
给产品页加了段JSON-LD，AI抓取频次从每天3次到11次
2026/10/21上周把公司一款小家电的产品页重写了一版结构化数据，分享下实测过程。 背景：页面原来只有基础的 Product schema，name、image、offers 三个字段。AI 爬虫（日志里识别的是 GPTBot 和 ClaudeBot）抓取频次平均每天 3 次左右，抓完也不一定引用。 改动： 补全
JSON-LD里把FAQPage和QAPage混着写，AI抓取时到底认哪个？
2026/10/21最近在调一个客户站的结构化数据，遇到个挺具体的问题，想拉几个同行对一下口径。 背景是这样的：客户是卖工业配件的，产品页底下挂了 12 条 FAQ，之前一直用 FAQPage 类型，每条问答一对 Question / acceptedAnswer。上周我顺手把它改成 QAPage，想着语义更贴近「用户
给JSON-LD里每个实体固定@id后，AI拼答案的串台率从22%掉到3%
2026/10/20上周给一个做工业传感器的客户做GEO排查，发现个挺隐蔽的问题：AI在回答「XX型号和YY型号区别」时，经常把两个型号的参数张冠李戴，比如把A的防护等级安到B头上。 我先怀疑是参数页本身写乱了，逐行核对了一遍，原文没问题。然后抓了页面渲染后的DOM，发现每个产品卡片的JSON-LD都是独立的Produ
JSON-LD里@id和URL没对齐，AI把同一家店拆成两个实体，我对着日志核了一下午
2026/10/17上周巡检一个本地生活客户的站点，发现一个怪事：品牌名在AI回答里出现两次，一次带门店地址，一次不带，像是两家不同的店。我先查了收录，两边页面都正常抓取，不是索引问题。 于是我把页面源码拉下来，逐字比对JSON-LD。问题在@id和url两个字段：@id写的是https://example.com/s
独家实测：把FAQ里的「问句主语」从客户换成销售，AI引用率掉了26个点
2026/10/17独家消息，不绕弯子——这周我把自家品牌 FAQ 的「问句主语」做了个 A/B 拆解，结果有点反直觉。 先说背景。前三个月我们靠 FAQ 喂养把 AI 引用率从 12% 拉到 41%，但一直有个问题没想明白：同一批知识点，写成「你们家 XX 支持什么协议」和「XX 支持什么协议」，AI 抓取后的引用表
JSON-LD的@id和URL字段对不上，AI抓取直接当两个实体，我逐字比对才发现
2026/10/17上周排查一个客户案例，AI搜索里品牌实体始终没被合并，同一个公司出现两条独立摘要。我一开始怀疑是页面速度拖了抓取，拉了TTFB日志——均值才48ms，排除。 后来把页面JSON-LD抠出来逐字比对，问题来了：Organization 的 @id 写的是 https://example.com/#or
拆了三个GEO项目的前端，发现结构化数据漏了这块基本白做
2026/9/30上周帮朋友看他的独立站GEO效果，打开控制台我就皱眉了——页面加载3.8秒，LCP元素是张没做懒加载的banner大图。他问我为什么AI搜索不抓他的内容，我说你先别管AI，爬虫进来都嫌慢。 我自己经手过三个GEO项目，踩过的坑基本都在技术层。说几个具体的： 1. 结构化数据不是加个JSON-LD就完
实测：JSON-LD 和页面速度对 GEO 的影响，我跑了一组对比数据
2026/9/28最近用公司的一个小站做了组对照实验，想搞清楚结构化数据和页面速度到底哪个对 AI 搜索的抓取影响更大。 实验设置 两组页面，内容质量基本一致，都是 5 篇长文 A 组：完整 JSON-LD（Article + FAQ + BreadcrumbList），TTFB 约 800ms B 组：无结构化数据
拆了3个GEO排名靠前的页面，发现结构化数据都踩了同一个坑
2026/9/28最近在优化公司官网的GEO表现，顺手用爬虫抓了3个在AI回答里高频引用的竞品页面，想看看他们的结构化数据怎么做的。结果发现一个挺有意思的现象：三个页面都用了FAQPage schema，但有两个的mainEntity里嵌套的Question节点，没有把acceptedAnswer的text写成纯文本
给公司官网做了套结构化数据，AI搜索抓取率翻了3倍
2026/9/25上个月老板突然问：为什么我们在 ChatGPT 里搜不到？我一看，官网连最基本的 JSON-LD 都没加，纯 HTML 裸奔。 花了两个周末，把几个核心页面改造了一下： Organization 和 WebSite 标记：首页加了公司 logo、社交账号、站内搜索的结构化描述。 Product 和
GEO落地时，这3个结构化数据坑我踩了，你们注意
2026/9/24最近在给公司官网做GEO优化，主要精力放在结构化数据上。踩了几个坑，记录一下，希望能帮到也在折腾的兄弟。 坑1：以为JSON-LD随便加加就行 一开始用Schema.org的Article标记，结果发现AI抓取时经常忽略作者和发布日期。后来查了文档，发现得用@graph把多个实体串起来，比如Orga
实测给产品页加了JSON-LD，AI搜索抓取率翻了3倍，说几个细节
2026/9/19最近两个月在公司一个B2B产品站上做了组对照实验，主站A保持原样，子站B只改技术层，结果B的AI搜索展现量涨了2.8倍。不扯虚的，直接上细节。 实验设计 两个站内容同源同质，只隔一个子域名，排除内容差异干扰 观测周期8周，用GSC的AI Overviews展示数据加自建日志爬虫 变量只有一个：结构化
拆了20个企业站发现：GEO做不好八成是结构化数据写歪了
2026/9/16最近帮公司排查AI搜索表现，顺手把同行业20个企业官网的页面源码扒了一遍。结论有点反直觉：大部分人把GEO当成内容运营问题，其实第一道坎是技术层的结构化数据没写对。 先说我自己的排查流程，给同样做GEO的兄弟参考： 抓取：用Screaming Frog跑全站，导出所有页面的JSON-LD和Micro
给官网加了JSON-LD后，AI搜索抓取效率高了一截，说下具体操作
2026/9/15最近在折腾GEO，发现很多人还在纠结内容怎么写，但我觉得技术底子没打好，内容再好也白搭。分享一个我亲自验证过的点：结构化数据对AI搜索抓取的影响。 先交代背景。我们公司官网是个普通的企业站，之前一直没管过结构化数据。我大概从两个月前开始，陆续给几个核心页面加了JSON-LD格式的Schema标记，主
结构化数据到底怎么选？我实测了JSON-LD和微格式的差异
2026/9/9最近在调一个客户的GEO方案，发现很多人对结构化数据的选择很随意，导致AI搜索的识别率差异巨大。刚好我手头有两个案例，都是做智能家居的，一个用了JSON-LD，另一个用了微格式（Microdata），数据量差不多，但效果天差地别。 先说JSON-LD那个，部署后两周内，在Perplexity和Goo