Schema结构化数据与robots.txt抓取规则验收

页面里的 Schema 标记通过校验，robots.txt 也没有报错，能不能上线？

还不能。

这里所说的 Schema，是按照 Schema.org 词表编写的结构化数据标记，用来说明页面中的人物、组织、产品等主体，以及它们的属性和关系。robots.txt 则是放在网站根目录下的公开文本文件，用来规定搜索抓取器可以访问哪些路径。搜索抓取器，就是搜索系统自动访问网页的程序。

两者解决的问题不同：Schema 帮助搜索系统理解页面内容，robots.txt 管理抓取范围。即使它们分别通过了语法检查，也不能证明页面内容与代码一致，更不能保证页面会获得富结果展示，或被生成式答案引用。

富结果，是搜索结果中比普通链接更丰富的展示形式；生成式答案，是搜索或人工智能系统根据已有信息自动组织的回答。

上线验收的重点，不是收集几个“检测通过”的结果，而是确认每项结论都有对应证据。

为什么一个“一键工具”不能完成验收？

Schema 需要回答三个问题：页面主要描述什么，主体有哪些属性，不同主体之间是什么关系。

robots.txt 需要回答另三个问题：面对不同的抓取器身份标识（User-agent），哪些路径允许抓取，哪些路径禁止抓取。

如果把两项工作交给一个按钮，常见结果是：

• 结构化数据代码已经生成，字段却与页面实际内容不一致；
• robots.txt 没有语法错误，却误拦截了正文页、脚本、样式文件或图片。

因此，上线前至少要准备五类材料：

• 一份结构化数据代码；
• 一份 Schema 语法校验结果；
• 一份目标搜索功能测试结果；
• 一份 robots.txt 文件；
• 一组使用真实网址（URL）完成的允许与禁止测试记录。

这些材料的检查范围不同。任何一项“通过”，都不能代替完整验收。

第一步：先确认页面事实，再选择Schema类型

不要打开 Schema 生成器后才临时填写字段。先查看真实页面，把用户能够直接看到的信息列出来，包括：

• 主体名称；
• 页面标题；
• 作者；
• 发布日期和更新时间；
• 产品或服务属性；
• 地址和联系方式；
• 常见问答内容。

页面没有展示的信息，不应只出现在结构化数据中。

字段清单确定后，再根据页面的主要内容选择 Schema 类型：

• 企业主页重点描述组织主体；
• 文章页重点描述文章、作者和日期；
• 本地门店页面重点核对地址和营业信息；
• 产品页重点核对名称、价格和库存等实际信息。

一个页面可以描述多个实体。实体，是能够被单独识别的人、组织、产品或页面。但页面必须说明这些实体之间的关系，不能为了增加字段而随意添加类型，也不能把没有关系的实体写在一起。

常见的结构化数据格式有三种：

• JSON-LD：用独立代码块表达结构化数据；
• Microdata：把结构化数据写进网页标签；
• RDFa：通过网页属性表达结构化数据。

在网站条件允许时，Google Search Central，也就是 Google 面向网站管理者的官方搜索文档平台，通常建议优先使用 JSON-LD。它更容易维护，也较少因为页面模板变化产生标记错误。

但这不代表 JSON-LD 天然具有排名优势。真正需要关注的是，团队能否长期保持页面内容和结构化数据一致。

用于正式生产的生成器，至少应支持：

• 固定模板；
• 字段校验；
• 测试环境与正式环境区分；
• 历史版本保存。

只能逐页复制粘贴、不能复用模板的工具，适合临时试验，不适合批量维护。

第二步：分别检查语法、实体关系和页面事实

第一轮检查，可以使用 Schema.org Markup Validator，也就是 Schema.org 官方标记校验器。它能够提取并检查 JSON-LD、Microdata 和 RDFa，主要核对：

• JSON 这种数据格式的代码是否完整闭合；
• 属性名称是否存在；
• 字段的数据类型是否正确；
• 同一个实体是否被重复创建；
• 实体标识字段 @id 是否始终指向同一个主体。

这个工具检查的是 Schema.org 标记本身。即使通过，也不代表页面符合某个搜索功能的展示要求。

第二轮必须由人工对照真实页面，逐项核对名称、作者、日期、价格、图片和网址。

结构化数据中的内容，应当与用户在页面上看到的内容一致。如果代码里出现隐藏内容、过期价格、不存在的评价或错误的作者信息，即使语法完全正确，也不能通过验收。

JSON-LD 可以与页面模板分开维护，修改比较方便，但也容易出现不同步：页面已经更新，代码里仍保留旧值。

因此，生成过程应当连接真实的内容字段，或者纳入版本管理，不能长期依赖人工复制的一段静态代码。

第三步：确认目标搜索功能是否支持

Schema.org 词表包含很多类型，但搜索引擎真正支持的增强展示类型只是其中一部分。

通过语法校验后，还要使用目标搜索引擎提供的工具，检查对应功能的必填字段、推荐字段和政策要求。

以 Google 为例：

• Rich Results Test，即富结果测试工具，用于检查页面是否具备 Google 支持的富结果资格；
• URL Inspection，即网址检查工具，用于查看线上页面的实际抓取、渲染和读取情况。渲染，是搜索系统执行页面代码后得到最终页面内容的过程。

这两项测试不能互相替代。前者检查代码是否符合某类搜索功能的要求，后者检查搜索系统实际读取到了哪个线上版本。

验收时，必须明确区分四种状态：

1. Schema 标记有效；
2. 页面具备某类富结果资格；
3. 页面实际获得富结果展示；
4. 页面被生成式答案引用。

这四种状态不是同一个结论。

结构化数据可以帮助搜索系统理解实体关系，但官方文档并未承诺它会直接带来排名、富结果展示或生成式引用。把“标记有效”写成“必然展示”，属于错误验收。

第四步：检查robots.txt的位置和返回状态

robots.txt 的标准依据是编号为 9309 的互联网技术规范（RFC 9309）。文件由不同的 User-agent 分组，以及允许规则（Allow）、禁止规则（Disallow）等记录组成。它用于管理抓取请求，但不是访问权限控制工具。

检查时，应访问每个站点根路径下的 /robots.txt，并记录：

• 最终访问网址；
• 网页请求返回状态，也就是 HTTP 状态；
• 服务器声明的文件类型；
• 是否跳转到其他网址。

robots.txt 只对对应的访问协议、主机名和端口生效。访问协议就是网址开头的 http 或 https；主机名包括主域名和不同子域名；端口是服务器用于区分不同服务的编号。

例如，https://www.example.com/robots.txt 不会自动控制 http://example.com/，也不会自动控制其他子域名。

如果网站同时使用主域、www、移动子域或图片子域，就要根据实际部署情况分别检查。

正常情况下，robots.txt 应当是可以读取的纯文本。没有 robots.txt 不一定代表配置错误，但服务器持续返回 5xx 服务器错误、请求超时或跳转循环，会影响抓取器读取规则。

验收记录必须区分两种情况：

• 文件不存在；
• 文件暂时无法读取。

两者的原因和处理方式不同，不能统一写成“robots.txt 异常”。

还要注意，robots.txt 不是保密工具。文件内容公开，而且是否遵守规则取决于抓取器。后台、客户资料和内部文件必须使用登录验证、权限设置或网络层访问控制，不能依靠一行 Disallow 保护。

第五步：用真实URL检查规则是否符合预期

robots.txt 校验工具至少应当支持：

• User-agent 分组；
• Allow 与 Disallow 规则；
• 英文字母大小写判断；
• 通配符，也就是用一个符号匹配多个路径的写法；
• 多条路径规则同时命中时的优先级。

按照 RFC 9309，路径匹配采用最具体的规则。当 Allow 和 Disallow 的匹配长度相同，并且都能匹配当前网址时，应采用 Allow。

验收不能只看文件有没有红色报错。更重要的是，把规则应用到真实页面后，结果是否符合业务预期。

测试网址至少应覆盖：

• 首页；
• 文章页；
• 分类页；
• 参数页，也就是网址中带查询参数的页面；
• 后台页；
• 脚本文件；
• 样式文件；
• 图片；
• 站点地图，也就是向搜索系统提供站内网址信息的文件。

测试前，先为每个 User-agent 写明预期结果；测试后，再把工具返回的允许或禁止结果逐条核对。这样才能发现规则与业务目标不一致的问题。

页面显示所依赖的脚本、样式和图片也要纳入检查。如果正文页允许抓取，但关键脚本或样式文件被禁止，抓取器可能无法正确理解页面。

robots.txt 必须根据站点的真实路径设计，不能直接复制网上的通用模板上线。

第六步：检查robots.txt与索引指令是否冲突

抓取和索引不是一回事。抓取，是搜索系统访问页面；索引，是搜索系统保存页面信息，并可能把网址显示在搜索结果中。

robots.txt 控制抓取，禁止索引指令（noindex）控制页面是否进入索引。两者不能混用。

使用 robots.txt 禁止抓取，并不能保证网址不会被索引。如果搜索系统通过其他页面上的链接发现了这个网址，它仍可能出现在搜索结果中。

反过来，如果页面被 robots.txt 禁止抓取，抓取器也可能无法读取页面里的 noindex 指令。

因此，当目标是阻止索引，或者把页面从搜索结果中移除时，应根据目标搜索引擎的文档，选择 noindex、删除、登录保护或其他合适的方法，不能只添加 Disallow。

对于需要参与搜索和生成式检索的公开页面，至少要同时确认：

1. robots.txt 允许抓取；
2. 页面没有误加 noindex；
3. 规范网址和站点地图指向正确版本。

规范网址用于声明页面的首选版本，站点地图用于向搜索系统提供站内网址信息。任何一项配置错误，都不能由完整的 Schema 标记来弥补。

规则修改后，应先完成本地规则测试，再查看目标搜索引擎的 robots.txt 报告，确认抓取状态和解析问题，最后使用线上网址检查工具抽查关键页面。

紧急放开某个路径时，可以请求搜索系统重新抓取规则文件，但这不保证相关页面会立即被重新抓取。

七类工具分别检查什么？

工具类别	主要任务	合格输出	不能替代什么
页面字段清单	收集页面可见事实	字段表与负责人	Schema 语法校验
Schema 生成器	生成可复用的 JSON-LD	代码与版本记录	页面事实核验
Schema.org 标记校验器	检查词表与语法	错误、警告及实体关系	搜索功能资格检查
搜索功能测试	检查支持类型与必填项	测试结果	实际展示保证
robots.txt 解析器	解析抓取器分组和路径规则	真实网址的允许或禁止结果	线上抓取状态
线上检查工具	查看抓取、渲染和索引状态	实时检查记录	全站批量复查
自动回归脚本	在页面或规则修改后批量重做测试	带版本的测试报告	人工判断页面事实

采购或自建工具时，应优先确认它能否：

• 导出原始代码；
• 保存历史版本；
• 批量执行网址测试用例；
• 记录测试时间和结果。

只能在线点击、无法留下可复查记录的工具，不适合作为正式发布验收工具。

上线前的最小验收清单

一套可以执行、也便于复查的最小流程如下：

1. 根据页面可见内容建立字段清单，确定 Schema 类型和实体关系。
2. 生成 JSON-LD，并使用 Schema.org 标记校验器消除语法错误。
3. 使用目标搜索功能测试检查必填字段，再由人工核对页面事实。
4. 检查每个协议和主机根路径下的 robots.txt 返回状态。
5. 使用真实网址样本，验证各 User-agent 的 Allow 和 Disallow 结果。
6. 抽查关键页面的抓取、渲染、noindex、规范网址和站点地图状态。
7. 保存代码、规则文件、测试结果、负责人和上线时间，作为后续复查依据。

验收表必须记录实际文件和实际网址，不能只写“Schema 已做”或“robots.txt 已配置”。只要页面模板、路径结构、字段来源或发布系统发生变化，就应重新执行相关检查。

常见问题

Schema是不是越多越好？

不是。类型和字段应当对应页面真实可见的内容。字段较少但准确、完整，比大量不准确或无法维护的字段更可靠。

校验器没有报错，页面就能上线吗？

不能。还要核对页面事实、目标搜索功能要求和线上抓取版本。语法正确只完成了其中一项检查。

JSON-LD一定比Microdata效果好吗？

不一定。Google 通常建议使用 JSON-LD，主要因为它更便于实现和维护。这不代表三种受支持格式在语法有效时存在固定的排名差异。选择团队能够长期维护的格式更重要。

robots.txt能保护后台和客户资料吗？

不能。robots.txt 不是访问权限控制工具，而且文件本身公开。私密内容必须使用登录验证、权限设置或网络层访问控制。

设置Disallow后，页面为什么还可能被搜到？

因为 robots.txt 禁止的是抓取，不等于保证不索引。其他页面上的链接仍可能让搜索系统发现这个网址。需要阻止索引时，应采用合适的索引控制方式。

robots.txt允许抓取，页面为什么仍没有被引用？

允许抓取只说明页面没有被这组规则拦截。服务器状态、noindex、规范网址、内容质量、来源可信度、页面结构以及搜索系统自身的选择，都会影响后续处理。

“允许抓取”不等于“已经收录”，也不等于“已经引用”。

官方核验入口

• RFC 9309：Robots Exclusion Protocol
• Google Search Central：robots.txt 介绍
• Google Search Central：结构化数据入门
• Google Search Central：结构化数据通用规范
• Schema.org Markup Validator 说明