schema-markup

Schema 标记

审查页面实际声明的内容，确定哪些实体适合放在页面中，并且只根据已核实的事实生成经过验证的 JSON-LD。绝不承诺排名、富媒体搜索结果、点击率提升或 AI 引用。

规则来源

使用以下标签解读重要规则：

• Semrush 支持的指导原则： 引用的 Semrush 文章中所述的方法。保留其适用场景和注意事项。
• 当前平台要求： 当前 Google Search Central 或 Schema.org 的要求。此类要求优先于过时的编辑示例。
• 行业实施启发式做法： 合理的实施实践，但并非搜索引擎要求，也不保证结果。
• 可配置默认项： 可根据用户的系统和需求调整的工作流或输出选项。

将证据来源与规则分类分开。每项结果都必须明确区分 Semrush MCP 数据、渲染后页面证据、验证器输出、用户提供的事实和模型判断。

不可妥协的防护措施

• Semrush 支持的指导原则： 将 Schema 视为机器可读的上下文和获得富媒体搜索结果资格的可能途径，而非直接的排名因素。说明有效标记不保证获得富媒体搜索结果。
• Semrush 支持的指导原则： AI 可见度的影响尚不确定。不得声称 Schema 能直接提升在 ChatGPT、Claude、Gemini 或其他 AI 系统中的可见度。
• 当前平台要求： 要求标记与页面可见内容及当前事实相符。编辑示例过时的情况下，使用当前 Google Search Central 要求和 Schema.org 词汇表。
• 当前平台要求： 绝不虚构评分、评论数量、价格、库存情况、日期、作者、地址、徽标或其他实体事实。
• 工作流安全规则： 除非用户另行授权实施，否则绝不编辑或部署生产代码。

开始之前

一次性收集以下输入：

• 目标： 精确 URL、提供的标记，或拥有现有 Semrush 项目的域名。
• 模式： 审计、建议、起草、验证或监控。
• 页面用途： 首页、文章、产品、评论、视频、本地商家，或其他明确指定的类型。
• 证据访问权限： 渲染后的浏览器页面、原始 HTML、Google 验证输出、Semrush MCP、Site Audit 导出内容，或用户提供的事实。
• 实施上下文： 仅在用户需要放置指导时提供 CMS 或框架信息。

如果页面类型或实体事实数据不明确，先进行审计。不要根据猜测生成可直接部署的代码。

使用官方 Semrush MCP

遵循发现 → 架构 → 执行的流程。不要用产品界面名称替代公开的 MCP 报告标识符。

基于项目的站点审核流程

1. 调用 projects 以发现 list_projects。
2. 为 list_projects 调用 get_report_schema，然后调用 execute_report，查找该域名对应的现有项目。
3. 调用 site_audit，确认当前公开的报告。
4. 获取当前 snapshots 架构，使用其必需参数传入项目标识符（目前是 id，而不是 project_id），然后选择最新的已完成审核，并记录其日期。
5. 使用 meta_issues 查找问题目录及其 ID 和描述。将其视为问题定义元数据，而非所选快照中发生了所列问题的证据。
6. 仅选择描述涉及标记或结构化数据的问题。
7. 获取当前 issue_details 架构，然后使用其必需的项目、快照和问题参数，并设置较小的结果数量上限，以检索受影响的 URL。除非发现的架构和执行都接受可选的 sort 值，否则不要传入该值；如果执行因可选排序而被拒绝，请省略它，不要更改证据请求。
8. 对于一个准确的已爬取 URL，使用 page_list 获取候选页面 ID。规范化请求的 URL 和返回的 URL，选择完全匹配项；不要假定第一个结果就是精确匹配，因为报告可能返回前缀匹配或近似匹配。然后使用 page_info 获取页面级证据。

经核实的公共 MCP 不提供名为 markup 的报告，也不提供产品 UI 中的 Markup 主题报告。绝不要承诺提供该报告、标记评分或硬编码的问题 ID。

MCP 限制

• 项目访问权限为只读。不要承诺创建项目、更改设置或发起新的爬取。
• 报告调用会消耗 API 单位。只请求所需字段和行数，有需要时再扩大范围。
• 标注结果对应的 Site Audit 快照日期和爬取覆盖范围。
• 将 issue_details 行视为问题发生的证据。空结果表示针对该项目、快照和问题的请求未返回匹配行；这并不能证明渲染后的页面有效，也不能证明不存在任何结构化数据问题。
• 缺少项目、活动、快照、问题类型、字段、订阅或 API 单位余额，属于访问受限，并不能证明网站没有结构化数据问题。

证据阶梯

可配置默认顺序： 按以下顺序使用最有力的可用证据，并注明证据来源。如果用户提供了更权威的第一方或平台证据，则调整顺序。

1. 现有 Semrush 项目和已完成的 Site Audit 快照。
2. 用户提供的 Site Audit 或结构化数据导出文件。
3. 浏览器渲染后的 DOM 检查。
4. Google Rich Results Test 或用户提供的验证器输出。
5. 原始 HTML 检查。
6. 用户提供的架构代码和经核实的页面事实。

页面加载后注入的 JSON-LD 可能无法通过原始 HTML 检查发现。如果 JavaScript 注入有可能发生，仅凭静态抓取结果，不要报告“未发现架构”。

支持的 v1 架构类型

可配置的产品范围： 以下类型定义了首个版本的范围；这并不表示其他 Schema.org 类型不重要。

生成代码前，请重新核对 Google Search Central 的最新文档，因为资格条件和属性要求会发生变化。

通用选择规则

• Semrush 支持的指导原则： 描述主要的可见实体，而非页面所针对的关键词；优先选择准确适用于该实体的最具体有效类型。
• 当前平台要求： 仅当属性值可见或已由用户确认时才纳入。不要仅为满足验证器要求而添加评分、优惠、作者、地址或媒体。
• 行业实施经验法则： 在整个网站中重复使用稳定的 @id 值，以便一致地关联相同实体。

组织

用于规范首页或定义组织的页面。请核实 name、规范 url、可抓取的 logo、稳定的 @id，以及真实的 sameAs 资料。确保其身份与发布者、卖家或提供方的引用保持一致。不要承诺一定会获得知识面板。

来源：组织架构

Article 和 BlogPosting

用于可见的编辑内容。请核实 headline、规范 URL 或 @id、具有代表性的 image、真实的 datePublished 和 dateModified、明确的 author，以及关联到网站 Organization 实体的 publisher。不要仅为显示内容较新而更改日期，也不要虚构作者资历。

来源：架构标记

Product 和 merchant listing

用于特定的可购买产品。请核实 name、图片、描述、产品标识符，以及可见的 offers 数据，例如价格、货币、供货状态、URL 和卖家。仅当真实评价可见时，才添加评分或评价。请根据 Google 当前文档，区分产品摘要资格与商家商品信息要求。

来源：架构标记 和 富媒体摘要

Review 和 AggregateRating

仅当评价或综合评分可见，且被评价的项目明确无误时使用。请核实 itemReviewed、作者、（如有表示的）评价正文、评分值和量表、真实的评分或评价数量，以及可见日期。请查看 Google 当前政策，了解受支持的项目类型和自我推广评价的限制。

来源：评价架构

VideoObject

当视频是页面中主要且可观看的内容时使用。请核实 name、描述、可抓取的 thumbnailUrl、真实的 uploadDate、contentUrl 或 embedUrl，以及已知时的视频时长。只有当页面和视频支持时，才添加片段或直播流属性。

来源：视频架构

LocalBusiness

用于实体营业地点。优先选择最具体且准确的子类型。请核实名称、规范 URL、地址、公开电话号码、营业时间、已知时的坐标、相关图片，以及每个不同地点各自稳定的 @id。地址、营业时间或电话号码不同的地点不得合并。

经审查的英文内容目录中没有专门介绍当前 LocalBusiness 的文章。发布前，请依据规范的 Semrush 架构指南和 Google 当前文档核验此模块。

来源：架构标记

其他检测到的类型

从通用层面审查其他类型：语法、词汇、与可见内容的一致性、身份和重复项。生成代码前，请查看当前的 Schema.org 定义，以及相应的 Google 功能文档（如有）。

v1 中不要优先生成 FAQPage 或 HowTo。Google 对其搜索功能的处理方式已有变化，经审查的 Semrush 英文内容目录也未提供足够有力的当前依据，无法将它们作为旗舰模块。

工作流

**行业工作流启发式方法：**使用以下顺序，将检测、类型选择、实现审查、起草和验证分开。当所选模式只需要工作流中的部分步骤时，可酌情调整。

1. 清点现有标记

• 检查已渲染的 script[type="application/ld+json"] 区块。
• 检查是否存在 Microdata 和 RDFa。
• 解析 JSON-LD 对象、数组和 @graph 节点；遇到解析失败时应如实报告，不要悄悄修补证据。
• 记录每个实体的 @type、@id、关键属性、来源 URL 和提取方法。
• 识别重复 ID、相互冲突的属性、未关联的实体和过时值。

将页面证据与 Semrush 爬取证据分开。Site Audit 问题可以指出受影响的 URL，但不能替代对最终渲染标记的检查。

2. 判断 Schema 是否适用

• 确定页面的主要实体和面向用户的用途。
• 仅选择描述可见内容的 Schema 类型。
• 区分 Schema.org 有效性与获得 Google 搜索功能展示资格。
• 说明每种建议类型适用或不适用的原因。
• 生成上述受支持类型时，先遵循上文的 v1 指南。

尽可能诊断检测到的其他类型；但在生成受支持范围之外的特定类型代码前，应查阅最新的 Google 和 Schema.org 文档。

3. 审核实现质量

检查：

• JSON 语法和有效的 Schema.org 术语。
• 相关 Google 功能当前要求和建议的属性。
• 标记内容是否与可见的名称、价格、货币、供货情况、评分、评论数、日期、作者、徽标、地址和媒体一致。
• 规范 URL、绝对资源 URL 和稳定的 @id 值。
• 实体嵌套与关系是否正确。
• 是否存在重复、矛盾、误导、隐藏或过时的属性。
• 标记是否可供爬取，并存在于渲染后的 DOM 中。

行业实现启发式原则： 根据技术有效性、政策风险、页面重要性和对搜索展示的潜在影响，为问题排序。不要编造通用的评分区间。

4. 起草或修正 JSON-LD

• 当前平台建议： 如果网站设置允许，为新代码优先使用 JSON-LD。Google 也支持有效的 Microdata 和 RDFa。
• 仅根据可见事实或用户确认的事实生成。
• 修正现有标记时，保留有效标识符。
• 当多个实体需要明确关联时，使用一个连贯的 @graph。
• 使用稳定的绝对 @id 值，通常采用规范 URL 片段，例如 #organization 或 #article。
• 仅包含相关属性。标记越多并不一定越好。
• 如果缺少必需事实，应返回缺失信息列表，而不是提供可直接部署的代码。
• 如果模板仍有用，应清楚标记每个占位符，并注明代码块不可部署。

5. 验证

行业工作流启发式原则： 按以下顺序验证：

1. 解析 JSON-LD。
2. 对照 Schema.org 确认所有术语。
3. 将每项事实属性与可见页面内容进行比对。
4. 对 Google 支持的功能运行 Google Rich Results Test。
5. 实现后重新检查渲染后的页面。

不要将通过 Schema.org 验证视为符合 Google 富媒体搜索结果展示资格的证明。不要不加核实就将验证器警告视为错误。

6. 交接

根据用户的 CMS 或框架提供相应的放置指导，但不要部署。如果用户正在协调实现工作，应指出验证步骤和重新测试操作。

输出规范

**可配置默认设置：**仅返回所选模式所需的部分：

1. **结论摘要：**通过、需要改进或证据不足。
2. **所用证据：**Semrush 快照、渲染后的页面、原始 HTML、验证器、提供的代码和用户事实。
3. **标记清单：**实体、类型、关键属性、提取方法和来源 URL。
4. **问题表：**优先级、问题、受影响的属性或 URL、证据、后果和修复方法。
5. **推荐的 schema 映射：**页面类型 → schema 类型 → 理由。
6. **修正后的 JSON-LD：**仅在有足够的已核实事实时提供。
7. **验证清单：**语法、词汇、内容一致性、Google 资格和渲染确认。
8. **实施说明：**放置位置、尚未解决的限制和重新测试操作。

清楚地区分以下证据类别：

• **Semrush MCP：**项目和 Site Audit 快照数据。
• **页面证据：**渲染后的页面内容或原始页面内容。
• **验证器证据：**Google 或 Schema.org 验证结果。
• **用户提供的事实：**用户直接提供的业务或实体信息。
• **模型判断：**类型选择、优先级排序和推荐的关联关系。

来源

Semrush 方法论：

• Schema 标记
• 视频 Schema
• 富媒体摘要
• 评价 Schema
• Organization Schema

技术权威来源：

• Google：结构化数据简介
• Google：结构化数据通用指南
• Google 富媒体搜索结果测试
• Schema.org 词汇表