信任徽章与认证：验证规则

信任徽章模块将认证、会员资格和担保以紧凑的形式呈现，提供足够文字和直接验证途径，供读者确认每一项声明。

示例渲染——担保

30 天退款保证 自原始购买之日起 30 个日历日内可申请退款。资格条件、排除条款和提交流程在所链接的担保条款中定义。 证据： 阅读完整担保条款 · 审查日期： 2026 年 8 月 27 日

此说明性渲染仅为展示约定，不代表 AmICited 作出商业承诺。生产环境中的徽章必须将「阅读完整担保条款」链接到适用政策，并使用其治理记录中的审查日期。

此元素为何重要

信任声明可以缩短复杂的判断过程。买家无法在一次访问中独立审计每一项安全控制措施、专业资格、行业会员资格或退款流程，因此知名的发证机构或精确的担保可以减少不确定性。徽章之所以有效，是因为它在心理上将证据压缩为决策点附近一个熟悉的信号。但这种压缩只有在底层声明经得起查验时才有用。一个带有「安全」「已批准」或「值得信赖」字样的装饰性盾牌，只会制造印象，却不提供相信的理由。

可验证性将读者的反应从被动安心转变为知情信心。具名的发证机构、凭证持有者、标识符、范围、状态和到期日期，回答了怀疑型访客会提出的问题。同样，担保也需要写明承诺的补救措施、资格期限、排除条款和完整条款。将这些细节隐藏在通用图标背后，是利用熟悉感而非赢得信任。发现过期或误用的徽章比看不到徽章更糟糕，因为它还会令人对发布者的其他声明产生质疑。

机器可提取性是指搜索系统、辅助软件、聚合工具和 AI 代理能够识别声明，而无需通过图片猜测。机器无法可靠地从一排 Logo 推断出「这些会员资格是有效的且适用于该法律实体」。实时文本和稳定字段让它们能够将凭证名称与其持有者、发证机构、范围、证据 URL 和有效期关联起来。这种结构也使自动过期检查成为可能。

遵循元素编写规则 按用途分类：如果某个模块的职责是声明认证、会员资格或担保，即使其设计看起来像 Logo 条、图标列表或卡片行，也应将其编码为信任徽章元素。有类型的用途优先于视觉表现。合作 Logo 轮播、客户 Logo 墙、媒体报道条、奖项列表和支付方式行执行不同的职责，不得将其重新标记为信任徽章。

何时使用

当声明可能改变理性读者对风险的判断，且证据可以被查核时，使用此元素。

• 认证： 用于经过评估后按照指定标准、计划或专业要求颁发的当前有效资质。记录持有者是谁以及涵盖哪些产品、网站、人员或活动。
• 会员资格： 用于在专业、行业、监管或社区组织中保持活跃参与，且该关系与页面相关时使用。会员资格是关联关系的证据，而不是质量或认可的自动证明。
• 担保： 用于发布者或销售方作出的承诺，如退款、维修、更换、正常运行时间信用或价格匹配。读者在承诺之前必须能够了解补救措施和资格规则。

仅在事实有助于回答当前问题时使用该模块。当范围与服务匹配时，安全认证适用于企业服务页面；行业会员资格可能适用于本地服务页面。即使真实有效，无关的证书也会增加干扰。

相近但错误的用法是最大的误用来源。不要将此元素用于星级评分、客户推荐、客户 Logo、媒体 Logo、支付图标、配送图标、可持续发展愿景、自创奖项或诸如「行业领先」等宽泛声明。不要将合规于法律最低标准当作荣誉。不要暗示会员资格意味着协会认可该会员，除非发证机构明确说明。不要使用发证机构的 Logo，如果其品牌规则只允许文字引用。

当无法进行验证时，该元素同样不适用。首先获取记录、发证机构许可（如需）以及负责的管理者。如果没有权威的验证途径，则移除该徽章。

放置位置

放置位置应遵循证据所支持的决策，因为距离会削弱上下文关联。将产品担保放在价格和核心条款之后、主要购买控件之前，以便读者在了解报价之后、采取行动之前看到补救措施。将服务认证放在范围或能力声明之后、证据或咨询控件之前。将组织会员资格放在公司、供应商、地点或团队页面的身份或资质部分。

每个决策区域使用一个规范模块。紧凑的购买卡片引用仅在链接到相同条款并保持同步时才可以接受。不要将相同的 Logo 分散在页头、正文、侧边栏、结账页面和页脚中；重复会使状态变更更难管理。

信任徽章模块不得放置在推荐语、星级评分、客户 Logo 墙、「媒体报道」条或未经支持的夸赞词旁边。这种组合会在视觉上混淆不同类型的证据，可能暗示发证机构认证了人气、结果或客户满意度。不得将其放置在广告或赞助单元内，否则徽章可能显得在验证推广内容。不得将其叠加在产品图片上或用作装饰背景，因为读者必须能够识别声明所涵盖的实体和范围。

将担保保持在相关操作附近，但要留有足够的视觉间隔，以免成为施压工具。旁边带一个小徽章的「立即购买——零风险」并不等同于呈现资格期限和条款。当结账页面需要紧凑提醒时，显示担保名称并链接到完整条款；不要在此处引入新措辞或扩大承诺范围。

结构

每个项目都有一个可见声明和一个验证记录。标注的结构如下：

1. 标记或图标： 可选，需经发证机构批准。它永远不能替代文字名称。
2. 名称： 准确的认证、会员资格或担保名称。
3. 类型标签： 标识读者看到的是三种证据类型中的哪一种。
4. 持有者或提供方： 声明所适用的法律实体、人员、地点、产品或卖方的名称。
5. 发证机构： 认证和会员资格需指明外部组织；担保则指明负责的提供方。
6. 范围： 说明凭证、会员资格或承诺所涵盖的内容，并在必要时说明排除的内容。
7. 状态和有效期： 说明有效状态，以及颁发日期、审查日期和到期日期（如适用）。
8. 验证控件： 链接到具体的发证机构记录、目录条目或完整的担保条款。
9. 无障碍名称： 以实时文本形式呈现声明，并为任何链接的标记提供明确的标签。

使用明确标识的演示凭证或经批准的当前记录。切勿为了视觉真实感而编造看起来合理的证书编号。

设计示例

认证卡片

当范围和有效期需要解释时，使用一张卡片。显示确切的标准或计划名称、持有者、证书标识符（若公开）、涵盖范围、到期日期，以及「验证认证」链接。保持发证机构标记在其批准的长宽比和最小尺寸内。

会员行

使用克制的一行展示一到四个有效会员资格。每个项目需要其组织名称、成员身份、适用时注明章节或级别，以及目录链接。不要将标记排列成看起来有声望但没有标签的 Logo 墙。

担保面板

当发布者作出承诺时，使用面板。先说明补救措施和时间窗口，然后总结资格条件和排除条款，再链接到完整条款。担保可以使用简单的发布者自有图标；但不得模仿监管机构的印章。

混合凭证组

仅当页面确实需要多种类型时，才使用混合组。在每个项目上保留明确的类型标签，并按与决策的相关性排序，而不是按 Logo 大小。切勿将担保放在外部发证机构标题下，也不要让会员资格看起来像认证。

紧凑和移动端处理

紧凑处理可以隐藏次要描述，但绝不能隐藏名称、持有者、状态、到期警告或验证控件。在移动端，按阅读顺序堆叠项目，并保持链接足够大，以便操作时不会误触相邻徽章。

参数

集合拥有其标题和治理日期；每个重复的 item 拥有其声明和证据。

仅在内部准备期间使用 under-review；不要将其作为令人安心的徽章发布。如果有效项目达到 expiresOn，渲染器或发布检查必须通过移除公开徽章或阻止发布来安全失效。绝不能默默地继续作为 active。

语法和代码示例

可移植指令存储了一个重复的项目约定。标题映射自第一个父标题；每个项目的第一个标题映射到其 name，其余项目正文映射到 scope 和支持文案。

可移植 Markdown 指令

:::trust-badges{variant=cards reviewedOn="2026-08-27"}
## Credentials and guarantees

::item{type=certification holder="Example Organization" issuer="Example Issuer" identifier="PUBLIC-ID" status=active expiresOn="2027-08-27" evidenceUrl="https://issuer.example/verify/PUBLIC-ID"}
### Example certification

Covers the named organization and the activities stated in the issuer's public record.
::
::item{type=guarantee holder="Example Seller" status=active evidenceUrl="https://seller.example/guarantee-terms"}
### 30-day money-back guarantee

Eligible first purchases may be refunded within 30 calendar days, subject to the linked terms.
::
:::

以上域名和实体明显是示例，并非可发布的证明。生产内容必须将其替换为经批准的、可解析的记录。

Hugo 短代码

{{< trust-badges variant="cards" reviewedOn="2026-08-27" >}}
  {{< trust-badge type="certification" holder="Example Organization" issuer="Example Issuer" identifier="PUBLIC-ID" status="active" expiresOn="2027-08-27" evidenceUrl="https://issuer.example/verify/PUBLIC-ID" >}}
  ## Example certification
  Covers the named organization and the activities stated in the issuer's public record.
  {{< /trust-badge >}}
{{< /trust-badges >}}

这是可移植的 Hugo 映射约定，而非在本地添加未注册短代码的许可。所有参数均已命名；位置参数和命名参数绝不能混用。

WordPress 区块和短代码

<!-- wp:amicited/trust-badges {"variant":"cards","reviewedOn":"2026-08-27"} -->
<!-- wp:amicited/trust-badge {"type":"certification","holder":"Example Organization","issuer":"Example Issuer","identifier":"PUBLIC-ID","status":"active","expiresOn":"2027-08-27","evidenceUrl":"https://issuer.example/verify/PUBLIC-ID"} -->
<h3>Example certification</h3>
<p>Covers the named organization and the activities stated in the issuer's public record.</p>
<!-- /wp:amicited/trust-badge -->
<!-- /wp:amicited/trust-badges -->

[trust_badges variant="cards" reviewed_on="2026-08-27"]
[trust_badge type="certification" holder="Example Organization" issuer="Example Issuer" identifier="PUBLIC-ID" status="active" expires_on="2027-08-27" evidence_url="https://issuer.example/verify/PUBLIC-ID"]Example certification — Covers the named organization and the activities stated in the issuer's public record.[/trust_badge]
[/trust_badges]

WordPress 可以存储驼峰式区块属性和蛇形式短代码属性，但适配器必须将两者映射到相同的规范字段和验证规则。

示例

良好：有范围、有日期、可验证

认证 [确切的认证名称] 持有者：[法律实体] · 颁发者：[发证机构] 范围：[记录中声明的特定产品、地点、活动或管理体系] 有效至：2026 年 12 月 31 日 · 证书编号：[公共标识符] 验证此认证

这样做的效果很好，因为可见文字区分了发证机构和持有者，将声明限定在实际范围内，提供了日期和标识符，并将验证作为主要操作。此处括号中的标签指定了生产字段；已发布的项目必须包含经批准的值，而不是括号。

不良：借用的权威而无证据

🛡️ 经认证安全 · 完全合规 · 100% 保障 受到全球专业人士信赖

这样做效果不佳，因为没有标准、发证机构、持有者、范围、记录、补救措施、日期或条款可供查验。「完全合规」没有明确边界，「100% 保障」未说明未兑现承诺时会怎样，盾牌借用了官方印章的视觉语言。全球知名度声明增加了第二个未经支持的断言。在每项声明都有证据和精确类型之前，移除该模块。

架构标记和无障碍性

信任徽章没有专用的通用 Schema.org 类型，可见标记也不会自动使页面符合富媒体搜索结果的条件。仅当存在适用于页面主体实体的适当属性且可见声明支持该属性时，才映射事实。不要将会员资格映射为奖项、将认证映射为评价、或将担保映射为综合评分。切勿因为徽章看起来像证据而添加 Review、Rating 或奖项数据。

结构化数据必须使用与可见元素相同的持有者、发证机构、范围、日期和证据 URL。如果结构化表示无法保留重要限制条件，则应省略该属性，而不是发布范围更广的机器声明。徽章的主要机器价值来自清晰的 HTML 和稳定的字段，而非强塞入不相关的架构。

将集合渲染为带标签的区块，将每个项目渲染为文章或列表项。将名称、类型、持有者、状态和验证链接保留在实时文本中。当相邻文本已指明发证机构时，发证机构 Logo 可以使用空的替代文本；在 alt 中重复名称会产生噪音。当 Logo 本身是唯一的链接控件时，其无障碍名称必须说明操作和主体，例如「验证示例组织在示例认证中的资格」，而不是「logo」或「了解更多」。

不要仅通过颜色传达 active、expiring 或无效状态。添加文本标签并按阅读顺序显示到期警告。保留键盘焦点、足够的对比度和舒适的链接目标。不要自动播放 Logo 行动画，也不要将验证详情隐藏在仅悬停的工具提示中。当徽章打开外部发证机构记录时，通过链接文本明确说明目标；不要求打开新标签页。

编写规则

模块听起来必须是有证据支撑的，而非庆祝性的。使用确切的官方名称，并区分发证机构所说的与发布者所承诺的。

• 在一个决策区域内使用 一到四个项目。超过四个需要优先排序或专门的资质板块，因为密集的 Logo 墙不再是可解释的证据。
• 将组标题控制在 2–6 个词，每个项目名称 2–12 个词，范围 8–40 个词，支持正文 15–60 个词。
• 以验证记录中完全一致的方式说明持有者的法律或公开身份。不要将母公司的资质悄悄转移给每个子公司、产品或地点。
• 外部资质指明发证机构，担保指明负责的提供方。绝不要将自我发布的承诺描述为「经认证」。
• 先说范围，再说好处。「涵盖伦敦办事处信息安全管理体系」是有用的；「世界级安全」则不是。
• 有到期日期时显示到期日期，并为整个组显示审查日期。即使不公开，也在治理数据中存储下一审查日期。
• 使用具体动词进行链接：「验证认证」「查看会员记录」或「阅读担保条款」。避免使用「了解更多」。
• 用一句话总结担保，不得省略会改变理性买家决策的限制条件。链接的条款保留完整的法律措辞，但徽章不能与其矛盾或夸大其词。
• 保留发证机构的大小写和批准的标记用法。除非其规则明确允许，否则不得重新着色、裁剪、重绘、组合或装饰官方标记。

绝不要在元素内放置排名、推荐语、客户数量、星级评分、「最佳」声明、无法验证的可持续性语言、促销折扣、紧迫感、优惠券代码或购买按钮。除非发证机构的证据支持确切的关系，绝不要写「政府批准」「官方合作伙伴」或「经认可」。绝不要在到期后为了视觉平衡而保留标记。

使用此元素的文章类型

postTypes 前置元数据定义了以下经批准的关联关系。收录意味着在存在相关证据时可以使用该元素，而非每种类型的页面都必须有徽章。

质量检查清单

• 每个项目被正确分类为认证、会员资格或担保。
• 确切的持有者或负责提供方已被指明并与证据匹配。
• 认证和会员资格项目指明了发证机构并使用发证机构的官方资质名称。
• 范围明确了涵盖的产品、实体、地点、人员、活动或系统，未超出记录范围。
• 每个项目都有直接、可解析的证据 URL，指向记录、目录条目或完整条款。
• 公共标识符和日期与权威证据逐字逐句匹配。
• 发布时，没有项目是过期、暂停、撤销、无法验证或标记为 under-review 的。
• 治理数据中存在下一审查的负责人和日期，安排在到期之前进行审查。
• 担保摘要准确披露了补救措施、期限、重要资格条件、排除条款和负责提供方。
• 官方标记已获许可、当前有效、未经裁剪、比例正确，并在发证机构规则范围内使用。
• 每个有意义的声明都可作为实时文本获取；图片不承载唯一的证据。
• 状态和到期信息无需颜色、悬停、动画或视觉位置即可理解。
• 验证链接具有特定的无障碍名称，且可通过键盘到达和激活。
• 模块放置在其支持的声明或决策旁边，旁边没有推荐语、评分、客户 Logo 墙、广告或未经支持的夸赞词。
• 可见 HTML 和任何结构化数据使用相同的名称、范围、日期和证据 URL。
• 页面中没有编造的奖项、暗示的认可、自创的认证或作为当前证据展示的历史徽章。

规范记录变更后，过期的徽章可能会在可重用卡片中缓存或复制。记录每个放置位置，并据此更新所有实例，将失败的验证视为发布缺陷。