来源与参考文献：引用规则

来源区块是页面末尾的有序记录，使页面上的事实性声明可追溯，方便读者和问答引擎验证和引用。

此实时示例展示了最基本完整的条目：带链接的标题、发布者、发布日期和访问日期。URL 隐藏在标题后面，而不是以长原始字符串形式出现。在将该区块适配到其他发布系统时，应用共享的元素编写规则 。

为什么这个元素很重要

读者并非对所有的声明都一视同仁。医疗建议、财务比较或性能数字所承担的风险远高于简单的能力声明。一份完整的参考文献显示了谁发布了证据、证据何时有效、以及它是否支持该声明。它还为编辑者在事实发生变化时提供了维护线索。

在末尾丢出十个可信链接并不能证明每个句子对应哪个来源。行内引用建立了局部的连接关系；结尾清单则保留了完整的记录。两者结合，让持怀疑态度的读者无需猜测就能从声明追溯到证据。

机器可提取性意味着软件可以识别页面设计之外的有界记录。一致的字段暴露了标题、发布者、URL、发布日期和访问日期。一个检索系统——即根据查询选择文档或段落的软件——然后可以比较日期、发布者和声明。

在问答引擎的结果中，多个候选页面可能做出相似的陈述。那些引用原始材料并标注证据日期的页面，完成了检索系统否则需要推断的部分验证工作。这并不能保证被选中，但它创建了一条可审计的证据链。

这一原则与该网站的E-E-A-T 与实体基础 保持一致：可见的来源出处支持信任度，而一致的发布者和标题字段有助于识别证据背后的实体。

何时使用

每当信息性或证据导向的页面依赖于读者可以合理验证的外部事实时，就应使用来源区块。这包括源自标准、统计数据、研究发现、法律、政策、市场主张、产品比较、历史声明、引用以及基于已发表证据的推荐。健康、金融、法律、保险、安全以及任何其他受监管或高后果领域明确要求使用。

即使声明已包含行内链接，但如果文章包含多个来源，也应使用该区块；该区块创建了一个可审查的清单。在案例研究中，将内部测量结果与外部基准分别标注，以免第一方数据被误认为是独立研究。

不要为那些没有外部可验证声明的观点添加该区块以作装饰。导航、推荐阅读、相关内容以及未使用的参考文献条目不属于该区块。来源是支持页面的证据；“延伸阅读"仅仅是拓展主题。

边缘情况需要明确的规则：

• 单一事实性声明： 行内引用即可。除非领域受监管，否则单一条目的结尾区块是可选的。
• 工具列表： 供应商首页是目的地，而非证据。仅当文档支持具体声明时才包含。
• 引用： 行内引用并包含完整的结尾记录。
• 常识： 不要引用目标读者不会质疑的事实，例如"一周有七天”。引用精确的解释、测量、政策或有争议的边界。
• 第一方产品文案： 对于可测试的功能，链接到官方文档。不要通过引用公司自己的营销页面来制造独立性的假象以证明优越性。

放置位置

来源区块是 FAQ 之后最后的编辑区块。只有站点级装饰、法律声明或模板级别的转化控件可以放在它之后。这个位置表明该清单支持已完成文章，并为审阅者提供了一个可预测的审计位置。

不要将唯一的清单放在侧边栏中：侧边栏可能在移动端布局、打印、RSS 订阅、阅读模式或提取文本中消失。将该区块远离相关内容卡片、表单和不相关的行动号召，以保持证据边界清晰。

行内引用保留在声明所在的位置。结尾区块不会将证据从它所支持的句子中移走；它只是完善了记录。如果 FAQ 回答引入了新的事实性声明，在该回答中引用该声明，并在结尾区块中重复该来源。如果 FAQ 仅重述已支持的内容，则复用现有来源，而不是添加重复条目。

结构

如果资源被替换，渲染后的图例仍保留在页面中：

1. 区块标题： 使用"来源"，除非出版标准要求使用"参考文献"。
2. 条目编号： 为每条记录提供一个跨语音、打印和提取的稳定标识符。
3. 标题和 URL： 精确标题作为描述性链接文本，指向所引用的版本。
4. 发布者： 对材料负责的组织。
5. 发布日期： 来源发布或实质性更新的时间。
6. 访问日期： 作者验证来源和声明的时间。
7. 区块边界： 一个有序列表；标题和列表承载语义。

不要将此图例嵌入到截图中。图片记录外观；编号图例定义了内容契约。

设计示例

变体改变了密度和可用元数据，但未改变五字段条目契约。

标准网络来源： 引用标准、文档、报告和网页的文章的默认样式。每个标题都有链接；发布者和两个日期保持为可见文本。

混合来源类型： DOI 是研究的持久标识符。对论文使用 DOI；对报告和文档使用规范 URL。在添加卷号、期号或版本详细信息时，保持通用字段顺序。

长标题： 自然换行到多行。除非两个不同文档变得无法区分，否则切勿截断标题。

移动端： 条目保持单一有序列表，无需水平滚动。长 URL 隐藏在标题后面，元数据在其下方换行，无需缩小文本。

参数

参数契约将作者提供的证据与渲染器的行为分开。下面的"来源"指组件获取值的地方。

所有五个条目字段均为必填。有标题而无发布者隐藏了责任方；有发布者而无 URL 则无法核查。两个日期显示了材料声称有效的时间以及验证的时间。如果不存在发布日期或更新日期，请填写 n.d.。对于时效性声明，替换无日期的证据或删除该声明。

语法和代码示例

每种表示法都承载相同的字段和顺序。组件可以转换源数据，但不得从脆弱的页面标记推断发布者或日期。

可移植 Markdown 指令

:::sources{heading="Sources"}
1. [citation — Schema.org Property](https://schema.org/citation) — Schema.org。发布于 2026-03-19。访问于 2026-08-27。
2. [Understanding SC 2.4.4: Link Purpose (In Context)](https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-in-context.html) — W3C Web Accessibility Initiative。更新于 2026-05-18。访问于 2026-08-27。
:::

Hugo 短代码

{{< sources heading="Sources" >}}
1. [citation — Schema.org Property](https://schema.org/citation) — Schema.org。发布于 2026-03-19。访问于 2026-08-27。
2. [Understanding SC 2.4.4: Link Purpose (In Context)](https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-in-context.html) — W3C Web Accessibility Initiative。更新于 2026-05-18。访问于 2026-08-27。
{{< /sources >}}

这是一个可移植的契约，并非声称此短代码已存在。在渲染器实现它之前，请使用原生标题和有序 Markdown 列表。

WordPress 区块或短代码

[sources heading="Sources"]
[source title="citation — Schema.org Property" publisher="Schema.org" url="https://schema.org/citation" publication_date="2026-03-19" accessed_date="2026-08-27"]
[source title="Understanding SC 2.4.4: Link Purpose (In Context)" publisher="W3C Web Accessibility Initiative" url="https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-in-context.html" publication_date="2026-05-18" accessed_date="2026-08-27"]
[/sources]

WordPress 区块可以暴露表单控件，但它必须渲染一个标题和原生有序列表，并在导出的内容中保留日期。

示例

优秀范例：完整、可归属且有日期

来源

1. “Understanding Success Criterion 2.4.4: Link Purpose (In Context)。” W3C Web Accessibility Initiative。更新于 2026 年 5 月 18 日。访问于 2026 年 8 月 27 日。
2. “citation — Schema.org Property。” Schema.org。发布于 2026 年 3 月 19 日。访问于 2026 年 8 月 27 日。

这是有效的，因为审阅者可以识别每个文档、发布者、来源日期、验证日期和目的地。条目按首次出现顺序排列，便于将行内编号与结尾记录进行核对。

糟糕范例：一堆域名

参考文献

• Google
• 某个无障碍博客
• schema.org
• https://example.com/article?id=18492

这样不行，因为没有条目标识文档或日期。“Google"是一个组织，不是证据。“某个无障碍博客"隐藏了发布者和质量等级。原始 URL 缺乏可用的标题，也没有条目映射到声明。修复方法是：为每个声明选择证据，添加行内引用，并记录所有必填字段。

行内引用与结尾来源列表

当读者需要知道哪个来源支持某个声明时，在声明位置引用；当页面依赖该来源时，包含完整的结尾记录。大多数证据导向的页面两者都需要。

对于数字、引用、研究发现、法律、政策、有争议的断言、安全说明、时效性产品事实或依赖来源的结论，行内引用是必须的。将其放在句子中或紧随其后。一个引用不能支持一段不相关的声明。

对于多个来源、强制要求的清单或受监管的主题，结尾列表是必须的。重复引用的内容获得一个条目；实质性不同的版本获得单独条目。

来源质量等级

质量是指对声明的适合度，而非名气。使用能够直接支持该语句的最高适当等级：

等级不能挽救不匹配的声明。监管机构的备案页面不能支持临床声明，论文不能证明研究之后发布的功能。供应商定价页面可以证明其当前价格，但不能证明它提供最佳价值。

当来源冲突时，说明解释差异的范围或日期，优先采用控管性的一手记录，并缩小声明范围。如果无法解决，说明证据存在冲突。

链接处理与来源丢失

默认情况下，外部链接在当前标签页中打开。使用 HTTPS 和规范或持久 URL；移除跟踪参数、会话标识符和重定向包装器。链接标题，而非"点击此处”。不要对普通编辑引用添加 nofollow；仅对具有此类关系的链接保留关系值。

如果产品有意在新标签页中打开外部来源，则输出 target="_blank" rel="noopener"，并通过可见文本或通过程序关联的描述警告用户。noopener 防止打开的页面获得对原始窗口的引用。仅当网站隐私政策要求隐藏引荐者信息时，才添加 noreferrer；这不是普遍的编辑引用要求。

在发布前和定期审查期间检查每个来源。死链接是指不再解析到被引用材料的 URL。当链接失效时：

1. 寻找发布者控制的替代内容、规范重定向、较新版本、DOI 或官方存档。
2. 确认替代内容支持相同的声明；一个可用的首页不能替代缺失的报告。
3. 更新 URL、如果版本发生变化则更新发布日期、访问日期，以及受新来源影响的任何声明。
4. 如果只有可靠的存档保存了确切的文档，链接到该存档并标注为已存档。
5. 如果无法找回证据，替换来源并重新评估声明。当没有合适的证据保留时，删除或限定声明。

切勿将旧的引用指向做出不同声明的替代内容。

模式标记与无障碍

来源区块不会创建独立的 Schema.org 实体。它仍然是包含它的 Article、TechArticle、Report 或其他有效 CreativeWork 的一部分。Schema.org 的 citation 属性可以承载作为文本或另一个 CreativeWork 的参考文献。当生成结构化数据时，将每个真实的编辑参考文献映射到 citation；不要将导航、联盟营销目的地或仅相关阅读标记为引用。

可见内容与结构化数据必须一致。JSON-LD（JavaScript 对象表示法的链接数据）不得引入不存在的来源或省略可见的限定条件。它绝不能取代可见列表或行内链接。

对于无障碍，使用标题后跟 <ol> 和 <li>。有序条目提供稳定的条目数和标识符。使用来源标题作为链接文本；将发布者和日期保留在同一条目中。切勿仅使用颜色、favicon 或标志作为唯一标识。

避免在原生列表上使用 role="list"，避免使用默认隐藏证据的交互式折叠面板，以及避免为简单的一维引用序列使用表格。如果链接在新标签页中打开，警告必须在视觉上和辅助技术上均可访问。键盘焦点必须保持可见，长标题必须换行而不被裁剪或导致水平页面滚动。

编写规则

使用精确的标题和可识别的发布者名称。保持以下顺序：标题、发布者、发布日期或更新日期、访问日期。仅在需要标识作品或满足出版标准时添加作者、版本、页码、DOI 或版本信息。

按首次出现顺序排列条目，除非所需样式另有规定。对相同的记录去重，但当差异影响声明时，将不同版本或修订版分开。

每个条目必须支持一个声明，每个重要的外部声明必须映射到证据。标题必须与目的地匹配。访问日期记录的是目的地及其支持内容被检查的时间，而非 CMS 保存页面的时间。

不要在区块内放置行动号召、联盟标签、相关文章、未用作证据的推荐书籍、作者简介、方法论说明、促销描述、星级评分或关于某个来源是否"很棒"的评论。在相关声明旁边或在方法部分解释来源的局限性。保持结尾区块为证据清单。

没有任意上限。一份报告可能需要数十条记录。超过二十个条目时，使用稳定的参考编号并测试窄屏换行；切勿将一篇文章的证据拆散到无关的侧边栏中。

使用此元素的内容类型

postTypes 前置元数据创建了与以下九种证据导向的页面类型的机器可读关联。下方表格增加了要求的放置位置和强度。

产品、类别和用例页面在做出事实性声明时仍需引用，但当页面主要为交易性且仅依赖第一方能力信息时，结尾列表为有条件使用。在所有内容类型中，健康、金融、法律和其他受监管内容无论篇幅长短都需要完整的来源区块。

质量检查清单

• 每个外部可验证的重要声明都有适当的来源。
• 需要精确归属的声明在声明位置有行内引用。
• 每个行内引用明确对应一个完整的结尾条目。
• 每个结尾条目至少支持页面上实际做出的一个声明。
• 每个条目包括标题、发布者、规范 URL、发布日期或 n.d.，以及精确的访问日期。
• 发布日期并非根据版权页脚、搜索片段或 URL 模式推断。
• 访问日期记录的是真实的验证时间，而非批量 CMS 迁移日期。
• 来源质量与声明匹配；供应商材料未用于证明优越性。
• 在可用且可用的前提下，一手或控管性官方材料取代二手报道。
• 研究声明保留了影响解释的人群、方法、日期和局限性。
• 冲突的证据已披露、限定范围或解决，而非默默省略。
• 标题是具有描述性的链接文本，并与目的地匹配。
• 外部 URL 使用 HTTPS，省略跟踪参数，并解析到被引用的版本。
• 链接在当前标签页中打开，除非文档化产品规则另有规定。
• 任何新标签页链接都使用 noopener 并警告用户将打开新标签页。
• 死链接或重定向链接已修复，未在不知情的情况下更改支持的声明。
• 该区块是主文档流中的标题加有序列表。
• 该区块是 FAQ 之后的最终编辑部分，不与相关内容或行动号召混合。
• 可见引用与任何 Schema.org citation 值一致。
• 该区块在窄屏上保持可读性、键盘无障碍且无水平页面滚动。

常见问题

是否每篇文章都需要来源区块？

对于依赖外部事实的信息性或证据导向的内容，应使用来源区块。仅包含第一方能力声明的简短产品页面可能不需要结尾区块，但每个事实性声明仍需适当的来源。健康、金融、法律和其他受监管内容始终需要来源区块。

来源区块能否替代行内引用？

不能。当读者需要知道哪个来源支持某个具体陈述时，应在该声明处放置行内引用。结尾区块提供完整的参考文献记录和页面级别的证据清单；它不会让远距离的声明与来源关系变得明显。

如果来源没有发布日期怎么办？

将发布日期记录为 n.d. 并包含精确的访问日期。不要虚构日期或省略该字段。对于时效性声明，请寻找有日期的替代来源或删除该声明，因为无日期的页面无法确定信息何时有效。

供应商材料可以出现在来源区块中吗？

可以，适用于供应商控制的声明，例如其记录在案的功能、价格、发布说明或合同条款。供应商材料不得用作其产品是最佳、最安全、最快或最有效选项的独立证据。

外部来源链接应该在新标签页中打开吗？

默认情况下，普通链接应在当前标签页中打开，以便读者控制导航。如果产品有意在新标签页中打开，请使用 target="_blank" 和 rel="noopener"，并提供可见或通过程序关联的方式提示将打开新标签页。

来源

1. “citation — Schema.org Property。” Schema.org。发布于 2026 年 3 月 19 日。访问于 2026 年 8 月 27 日。
2. “Understanding Success Criterion 2.4.4: Link Purpose (In Context)。” W3C Web Accessibility Initiative。更新于 2026 年 5 月 18 日。访问于 2026 年 8 月 27 日。
3. “Technique G201: Giving Users Advanced Warning When Opening a New Window。” W3C Web Accessibility Initiative。更新于 2026 年 5 月 18 日。访问于 2026 年 8 月 27 日。