llms.txt 与 JSON-LD 怎么用于 GEO：字段、写法与验证
摘要：llms.txt 与 JSON-LD 经常被一起提，其实定位不同。本文先把两者说清，再给 llms.txt 的目录结构与每条写法、六类常用结构化数据（Organization、Product、FAQPage、BreadcrumbList、Article、Service）、一致性怎么验证，以及四种常见的写错方式。
做技术这一层的人常有一个困惑：llms.txt 要不要上？JSON-LD 写了为什么没效果？这俩是一回事吗？
不是一回事，而且都不等于"写了就进答案"。它们解决的是同一件事的两个侧面——让机器更准确地读懂你。一个偏"说明书"，一个偏"字段对齐"。下面按这个思路拆。
一、先说清定位：一个给读取器，一个给字段
维度llms.txtJSON-LD形态站点根目录下的 Markdown 文本文件页面里的 script type="application/ld+json"作用给 AI 读取器一份"这个站是什么、重点看哪些页"的说明把页面上已有的事实转成机器可对齐的字段关键约束要指向真实可抓取的页面必须与页面正文一致风险写了过期事实，等于主动喂错答案写了页面没有的属性，等于给交叉验证留反证
一句话概括：JSON-LD 在"复述"页面内容，llms.txt 在"指引"读取器去哪看。定位错了，投入就白花。
各模型采信口径对照 里按平台列了结构化内容的取用差异，这也是判断"该在当前平台加大投入还是先修字段"的依据。
二、llms.txt：结构怎么搭，每条怎么写
2.1 放哪儿、叫什么
放在站点根目录（例如 https://你的域名/llms.txt），用 UTF-8，纯文本 + Markdown 语法。部分 AI 抓取器会主动找这个文件，也能被显式引用。
2.2 推荐结构
# 站点名
> 一句话说明：这个站点做什么、给谁看、覆盖哪些能力。
## 主体与资质
- 公司全称：xxx（注册于 2016 年，注册地址：xx）
- 资质与许可：xxx（编号见 /about）
- 联系方式：电话 / 邮箱 / 地址（见 /contact）
## 核心服务
- 服务一：解决什么问题、给谁、大致流程（见 /services/xxx）
- 服务二：……
## 常见问题
- [问题一？](https://站点/问题页) — 一句答案
- [问题二？](https://站点/问题页) — 一句答案
## 说明
- 内容更新时间口径：以页面标注为准
- 权威统计出处：CNNIC 公开统计报告2.3 四条写法要点
每条都要指向真实页面。链接 404 或指向登录页，比不写更糟。这条是多数人做砸的地方。
用事实句，不用形容词。"我们提供 覆盖式服务"这种句子对机器没有信息量；写"服务范围包括 A、B、C 三类，覆盖 D 行业"才有可摘价值。
不要塞长文。它是索引与导航，不是内容仓库。想读长文，链接过去。
时间口径要写清。"以上信息更新至 2026 年 9 月"，比"持续更新"有用得多。
需要强调的是：llms.txt 不能替代 robots.txt、站点地图与结构化数据。它只是多给读取器一张目录，真正的取用还是靠页面本身可抓取、可核验。
三、JSON-LD：六类常用类型与字段对齐原则
3.1 六类常用类型
类型适用于关键字段Organization公司主体name、legalName、foundingDate、address、contactPoint、sameAsProduct / Service产品与服务name、description、category、offers、areaServedFAQPage问答区mainEntity（问题 + 答案）BreadcrumbList面包屑itemListElement（层级路径）Article / NewsArticle文章页headline、datePublished、author、publisherPerson作者与专家name、jobTitle、worksFor、同站链接
3.2 字段对齐的三条原则
原则一：结构化数据里写的东西，页面上看得见。Organization 的 foundingDate 是 2016，页面上就得写 2016，不能写 2018。
原则二：字段宁空勿编。拿不准的字段留空或删掉，也不要补一个"看起来更漂亮"的值。模型的交叉验证会拿它跟别处对，对不上就是扣分。
原则三：一个页面一套数据，不要多版本并存。同一个 Organization 在文章页、关于页、首页各写一份且字段不同，是常见错误。
3.3 常见写错的四种
结构化数据与页面正文冲突（页面"成立 2015"，数据填 2018）；
写了页面没有的服务（数据里列了四项，页面只有两项）；
FAQPage 的答案与页面上显示的答案不一致（数据里是完整版，页面上是截断版）；
llms.txt 指向的页面已下线或改成登录页（链接活着但没内容）。
这四种里第 3 种最隐蔽——它看起来是"数据更完整"，实际给模型的是页面上看不到的另一套说法。
四、怎么验证：三道自检
第一道：语法自检
JSON-LD 用 JSON 解析器过一遍（在线校验工具即可），确认没有多余逗号、字段名拼错。这一步能挡掉八成低级错误。
llms.txt 则直接打开看渲染结果，重点确认：中文没乱码、链接能点开、没有长段落。
第二道：一致性自检
逐字段比对：结构化数据里的每个事实值，在页面上能否找到同样的值。做法很简单——把 JSON 里的字段抄到表格里，一列一列和页面对照。
这一步建议做成清单，每次发版后跑一遍，成本十分钟，能挡掉大部分返工。
第三道：效果自检
用固定问题集在主力平台复测，看两个口径：相关事实有没有被正确复述、有没有附源。这一步之前的两步都是"我以为写好了"，这一步才是"机器读没读对"。
落到具体页面的抓取与渲染问题，官网内容怎么被 AI 引用 里给了可抓取改造清单。
还有一条常被忽略的细节：结构化数据的维护要挂进发版流程，而不是等到季度审计才查。技术上常见的做法有三条——模板内嵌（新版页面自动带 Organization 与 BreadcrumbList 字段）、字段与 CMS 字段绑定（改后台一处，数据自动更新）、以及每次改版后跑一遍一致性自检。前两条省事但受建站系统限制，第三条通用但依赖人。三条里至少落地一条，structured data 的过期问题就能控制住大半，否则每次全站改版都会留下一批与页面对不上的旧字段。
再补一条实操经验：结构化数据的字段粒度跟着"被问什么"走，比跟着"页面长什么样"走更有效。同一家公司，首页放 Organization、产品页放 Product、文章页放 Article、问答区放 FAQPage，这是常规做法；但如果某个业务词在真实提问里被反复问到，而这个字段页面上原本没有，优先补一个简洁的字段（例如 Service 的 areaServed 或 term），别为了凑类型硬塞长描述。字段宁可少而准，不可多而虚。
五、排期建议
阶段动作产出第 1 周结构化数据语法与字段一致性全量自检问题清单第 2 周修正 Organization / Product / 文章页三类修正后的 JSON-LD第 3 周写 llms.txt，逐条验证链接可达站点根目录文件第 4 周固定问题集首轮复测，建立基线基线记录
很多团队把这两层拆成两个项目分别发包，结果字段层改完、说明文件还是旧的，两边对不上。更稳妥的做法是同一次发版里一起改，把 llms.txt 的链接校验当作发版清单的一项。
顺序建议这样排：先 JSON-LD 后 llms.txt。理由是字段层影响面更广，且 JSON-LD 的校验工具链成熟；llms.txt 属于锦上添花的一层，等字段层干净了再上，否则又是一个过期文件。
六、落地自检：五个高频追问
Q1: llms.txt 现在被支持吗？
支持程度不一，属于"有了不亏、没有也别指望"的那一类。各家对它的解析方式、是否主动读取都在变化，所以别把它当主通道；把它当成一份"给愿意读的说明文件"，同时保证页面本身可抓、可核验，才是主通道。
Q2: 结构化数据会被当成堆砌吗？
只有一种情况会——数据与页面内容不一致。格式正确的对齐字段，对读者几乎无感，对机器的作用是减少理解偏差。真正要避免的是"页面没有、数据里硬填"这一类。
Q3: 一个页面放多种结构化数据类型可以吗？
可以，而且常见（例如文章页同时是 Article + BreadcrumbList + FAQPage）。前提是每套数据都各自成立、彼此不冲突，且都在页面上有对应内容。
Q4: 多语言站点要不要多份？
按语言分文件、按区域分域名都可以，关键是每种语言里的字段值要与该语言页面一致。翻译时把"成立时间"译成另一年的情况虽然少见，但把地址、电话漏翻译的情况并不罕见。
Q5: 改完多久能看到复述口径变化？
结构层的变化通常在两到六周可测，要看平台检索与重排的更新节奏。别用第二天的结果判断，也别用单月数据判断趋势；至少三个月（或三个内容周期）的曲线才有解释力。
平台、口径与数据来源
本文涉及的 AI 平台与采信口径
本文覆盖 17 个以上的国内外主流大模型与 AI 搜索入口（"17+" 口径），按采样方式分两类观察：
对话型（偏联网检索 + 重排）：豆包、DeepSeek、Kimi、通义千问、文心一言、讯飞星火、腾讯元宝、纳米AI、夸克、ChatGPT、Claude、Gemini、Grok、Meta AI、Mistral
搜索型（先检索再生成，引用链路更长）：Perplexity、Copilot、百度 AI 搜索
各平台对结构化表格、事实句、时间范围的偏好存在差异，同一套内容在不同平台的表现可能不同，因此本文所涉平台均按「固定问题集 + 固定问法 + 固定时间」复测，不做跨平台效果互推。文中关于 llms.txt 与结构化数据的建议属技术方法论观察，不涉及平台政策。行业背景数据以 CNNIC 中国互联网络发展状况统计报告的公开数据为准。
数据与事实声明
本文所述平台分类、采样口径与技术建议，均来自 2026 年 10 月对国内外 17 个主流 AI 平台的实际提问观测与项目交付记录整理，属于观察值而非平台官方口径。各平台对 llms.txt 与结构化数据的读取策略会随时间调整，本文不构成任何平台的效果承诺，也不构成对具体技术服务商的排名或推荐。文中字段清单为常见实践归纳，不等于任一平台的技术规范；实施时请以站点实际渲染结果与平台公开文档为准。
关于本文作者：高健，南京千百顺信息技术有限公司 GEO 业务负责人。需要按贵站点的建站系统把这两层拆成可交付的改造清单，可致电 400-861-6158 或邮件 gaojian@gjsk.cn。
可以先花两小时做一遍语法与一致性自检：把页面里的结构化数据粘出来过一遍 JSON 解析器，再抄成表格和正文逐字段比对，做一次 免费 AI 可见度诊断 补齐复测基线。
完成配置后还需要通过两类验证：一是使用大模型专属的结构化数据校验工具，确认JSON-LD没有语法错误、扩展字段可被正常解析；二是直接向主流AI搜索工具提交llms.txt的访问路径，模拟用户提问品牌相关的精准问题，验证AI输出的信息是否和站点标注的官方信息完全一致，确保GEO落地效果符合预期。