Schema、语义 HTML、llms.txt：哪些信息应该怎样提供？

先确认买家缺少哪条信息

一家软件公司已经有官网，外包清单却要求增加几十种 Schema、一个很长的 llms.txt，再给每一段加“AI 友好”标题。这些文件可以有用途，但不能替代对业务信息的判断。如果买家仍然找不到部署方式、价格条件和当前版本，多一份机器可读副本只是把同一空白复制出去。

比较稳妥的实施顺序是：先确保公开正文能准确回答买家问题，再用合适的 HTML 表达结构，然后添加确实适用的结构化数据，最后为有明确使用场景的代理提供简明文档入口。四层可以互相补充，但解决的是不同任务。正文面向真实读者；语义结构表达段落、表格和交互的角色；结构化数据描述实体与属性；文档入口帮助某些工具找到适合读取的资料。

本文采用一个虚构的团队知识库套餐说明怎样验收一致性。价格、席位和部署信息均为教学数据，没有指向任何真实产品，也没有运行外部 AI 测试。目标是让你能够判断一项技术建议是否补上真实信息缺口，而不是看到校验工具的绿色标记就认为品牌会被推荐。

语义 HTML 是信息组织，不是关键词装饰

标题应描述其下内容，列表应表达同级项目，表格应把每个值连接到对应行列。比如“团队套餐每月九十九元，含五个席位”需要把计费周期、币种和包含数量放在同一个可读范围内。“价格九十九”单独放在大字号卡片上，底部小字才说按年付费，很容易让截取出来的信息失去条件。

语义标签不会自动证明事实正确。把普通段落改成标题，不能把营销口号变成产品证据；把一排视觉卡片写成表格，也不一定适合阅读。应按照内容关系选择结构，而不是为了某种猜测的爬虫喜好。HTML 的 section、article、heading 等含义可查 WHATWG HTML 标准，实施时仍需要检查页面的实际阅读顺序。

一个实用检查是关闭视觉样式，查看正文顺序是否仍然成立。产品名之后是否紧接适用版本？“不支持离线部署”的限制是否仍归属于正确套餐？按钮只有“了解更多”时，屏幕阅读器或代理看到多个相同名称，是否能够辨认目标？可访问名称、真实链接与明确表单标签能帮助真实使用者完成任务，也为自动读取提供更清楚的结构。

JSON-LD 应当复述同一事实

Schema.org 是描述实体与属性的词汇，JSON-LD 是一种表达方式。文章可以描述作者与出版信息，产品可以描述对应型号与报价，组织可以描述名称与联系方式。选择类型应依据页面实际内容，而不是哪个名称听起来更容易获得曝光。不能在普通介绍页里捏造评分、价格、办公室或资质，以便填满模板。

Google 的结构化数据通用规范要求标记与页面主要可见内容相符，且明确通过语法检查不保证展示。这里至少有三道不同的验收：JSON 是否能解析；字段是否符合相应类型和展示要求；标记是否准确代表公开事实。第一道通过，后两道仍可能失败。

对于教学套餐，正文写“每月九十九元，人民币，含五席位”，结构化表示就不能保留上个季度的七十九元。代码片段可以用来说明字段一致性，但发布时应按当前适用类型检查必填项；本文不提供可直接复制到任意 SaaS 的完整富媒体资格模板。尤其服务、订阅、试用和商品变体的业务含义不同，不能用一个价格数字隐去计费限制。

llms.txt 当前提案实际解决什么

截至二〇二六年九月十一日核验，官方 llms.txt 提案展示第二版，修改日期为八月十日。它建议用简洁的 Markdown 背景与链接帮助代理进入适合读取的详细文档；可以放在站点根路径，也可以放在文档子路径，作用范围对应路径，多个入口适用时选择更具体者。把“只能放根目录”写成永远不变的规则，已经不准确。

其价值可以用软件文档来理解：代理准备调用某个库，不必先读取整个网站，而是通过小型目录找到当前安装、接口、迁移和限制说明。入口应提供必要背景和明确链接，详细资料放在相应页面。它不是访问授权，不覆盖 robots.txt，也不是一张向全体模型提交品牌信息的注册表。

“某平台公开自己的 llms.txt”与“该平台的所有搜索产品会读取所有网站的 llms.txt”是两种完全不同的事实。前者可能只是帮助开发者代理浏览它的文档。采用情况必须按具体工具、版本与行为核验。如果暂时没有目标使用系统，可以把这项工作列为低成本的文档便利改进，而不能据此承诺收录、引用或流量。

Google 的范围需要单独说明

Google 当前生成式 AI 搜索优化指南明确说明，Google Search 不依赖这些特殊 AI 文本文件，忽略 llms.txt；也没有必须增加的特殊 Schema 或通用分块字数要求。这一说明适用于 Google Search 的相关生成式功能，不能反向推导所有编码代理都不会使用文档入口。

因此，如果任务目标是改善 Google 搜索相关页面，优先排查页面是否能访问、正文是否完整、索引资格和内部导航是否正确。如果任务是让某个已确认支持文档入口的工具更容易找到 API 说明，可以维护 llms.txt，并用真实读取任务验收。两项工作可以并行存在，但应分别写目标、证据与成功条件。

平台展示能力也会更新。本文不把 FAQ 富媒体结果或某种特殊展示列为购买承诺。准备实施 Article、Product 或其他类型时，应在发布当天查看该类型的官方支持说明，而不是凭过去教程决定。即使展示功能存在，网站是否满足条件与最终是否展示仍是两层问题。

用一个信息源生成多种表达

最容易造成错误的是三套独立手工内容：营销人员改 HTML，工程人员维护 JSON-LD，另一个脚本生成 Markdown。价格或权限一变，三份内容只更新两份。更可靠的方式是确定业务事实的主来源，让能结构化管理的字段从同一数据对象生成；不能自动生成的解释性段落，则纳入同一发布清单。

教学对象包括六个字段：价格九十九、币种人民币、月付周期、五个席位、CSV 导出、中国服务区。我们构造三个表示：HTML 六项都正确；Schema 的价格仍是七十九；Markdown 的席位仍是三个。十八个字段位置里有十六项一致，但这是一个很差的产品发布结果，因为两项错误正是客户决定是否购买的重要条件。

truth = 当前已经批准发布的业务事实
for representation in [HTML, JSON_LD, Markdown]:
    for field in required_business_fields:
        if normalize(representation[field]) != normalize(truth[field]):
            record_mismatch(representation, field)
一致性覆盖 = 正确字段位置数 / 已检查字段位置数

这里 normalize 只处理允许的格式差异，例如价格“99.00”与数值九十九，不能把月付和年付当成同义词，也不能把“最多五人”改成“至少五人”。覆盖率十六除以十八约为百分之八十八点九，只适合显示检查范围；上线门槛应要求关键字段没有冲突，而不是达到某个平均分就算通过。这个例子已经由随文脚本实际执行，输出保留了价格与席位两个错误位置。

验收要走到真实读取任务

第一步检查路由和状态：正文页、图片、Markdown 与入口链接是否返回预期内容，而不是错误页也返回成功状态。第二步检查初始 HTML 与渲染后内容，确认目标系统能访问的路径上确实有主要事实。浏览器能看到内容，并不代表所有自动访问方式都一样；具体抓取与渲染问题可进一步按 P02 的层级排查。

第三步检查结构化信息解析，记录解析结果和版本；第四步人工核对事实关系，包括型号、套餐、单位、日期与例外。最后设计一个实际任务，例如“找到当前团队套餐包含席位与导出格式，并给出处”。如果工具只读取了旧资料，应记录其入口、返回地址和观察时间，不能仅凭最终答错就猜测它采用了哪种隐藏算法。

这里需要区分作者控制的测试和平台搜索测试。把 llms.txt 明确交给工具，测试的是该入口是否足以完成任务；它不测试工具会不会自行发现入口。不给目标网址的选型问题，测试的是自然发现。两种结果应分别报告，否则一个受提示的文档读取演示很容易被包装成未经提示的品牌推荐。

内容维护比文件数量更重要

每份表达都应有负责维护的角色。产品经理确认功能与限制，内容人员确认读者能否理解，工程人员保证数据输出和路由，复核人员检查不同表示是否一致。价格、许可、部署方式与联系方式变更应触发发布检查。没有维护机制的自动生成文件，可能在未来成为传播过期事实的第二来源。

旧版本文档不必一律删除。开发者可能仍需维护旧系统，买家也可能需要理解迁移。应清楚标注版本和当前入口，并让新版页面说明与旧版的关系；不能把旧版当前仍然真实的描述偷偷改成新版事实。规范 URL、版本页和多语言页各有角色，不应把所有页面都指向一个首页来假装消除歧义。

有些事实本来就是条件化的：不同地区税费不同，企业套餐需要确认范围，某个导出功能只支持特定权限。保持条件化表达比填一个看似完整的固定值更可靠。结构化字段无法准确表达时，应保留自然语言解释与咨询入口，不要为了机器解析便利而抹平交易条件。

把预算放到可验证的缺口

可以按四类问题安排工作。客户看不懂关键限制，先改正文；正文清楚但标题表格关系混乱，修语义结构；同一事实在标记中不同，修生成与同步；某个确认使用文档入口的代理无法快速找到接口，再维护 llms.txt。若四类问题都没有证据，继续批量添加字段未必是最有价值的投入。

成本评估也要包括长期维护。一次增加五十种标记看起来很丰富，但每次产品更新都可能出现新的冲突。相反，一张清楚的套餐表、一个当前版本入口和一条公开更正记录，往往更容易被团队持续维护。这里讨论的是信息工程的质量，不是关于所有平台排名权重的经验公式。

交付时要求服务方展示具体差异：哪个字段以前错误，现在与哪个批准事实一致；哪个链接以前无法访问，现在返回什么；哪个任务以前缺少信息，现在能找到哪些证据。不要用“已完成 AI 优化配置”一句话代替验收，也不要要求服务方保证它无法控制的展示结果。

从一个页面开始完成闭环

多语言副本如何避免产生第二套产品事实

如果同一个套餐有中文和英文页面，翻译应保持相同商业边界，但表达可以适应读者语言。英文页面不能因旧文案残留而写成无限席位，中文页面也不能漏掉服务地区。每次业务变更，应列出受影响语言与文档路径，而不只是更新主语言首页。未完成翻译的版本可以保留清楚的状态，不能靠自动替换日期伪装已经完成审校。

产品名称和技术术语需要词汇表。一个页面称为团队空间，另一个称为组织，有时只是同义表达，有时代表不同权限层级。发布人员应向产品团队确认关系，给出必要解释，再让结构化字段和文档入口采用一致标识。为了关键词覆盖而不断给同一功能换名字，会增加实体与权限关系的歧义。

维护入口也需要检查退出与更正

功能下线、套餐合并和公司改名都应有明确处理方式。旧入口可以解释变更并引导当前资料；已经不适用的价格不能继续作为现行报价暴露。若历史文档仍有保留价值，注明它适用于旧版本，并提供迁移说明。这样既照顾维护旧系统的读者，也避免新买家把历史能力当作当前承诺。

更正记录应说明改了哪条事实，不能只写笼统的“内容优化”。例如，席位从三人调整为五人是套餐更新，旧文档误写成三人则是内容错误；两者给客户的解释不同。明确区分这种来源，能够让人工复核和自动一致性检查针对正确目标工作，也便于后续诊断判断某次回答究竟引用了哪一时期的资料。

读者可以先选择最常被客户询问的产品页，列出六至十条决定购买的事实，再把正文、标记和文档副本并排核对。对每一条写出负责人与来源日期。本文 part-b-run-examples.py 的 P11 部分提供了一个不联网的起点，P11-result.json 显示三种表达的差异；它没有模拟搜索排名或验证真实爬虫。

下一步用人的阅读任务检查可理解性，再根据目标工具安排实际读取测试。若目标是 AI 代理准备咨询信息，还应检查按钮、表单和确认状态，这属于代理与决策信息的范围。信息可读取不等于系统被允许提交订单，更不等于客户已经决定购买。

NiubiGEO 的诊断可以将回答错误与页面事实并排核查，由人工确认需要修改的表达，再安排可比较的复测。成果应是一份更准确、可维护、可追溯的信息资产，以及清楚的测试记录。Schema、HTML 与 llms.txt 各尽其用，才值得进入这个工作流程。