页面级元数据（页面类型、关联产品、最近更新、字数）让您能够以更宏观、更具战略性的视角来看待您的内容。
它能帮助您回答以下问题：
- 作为作者：
- 我是否在内容策略中遗漏了某些显而易见的东西？
- 我现在应该更新哪些页面？
- X 教程与所有教程相比如何？它的流量是否高于基准线？
- 作为经理：
- 我们是对特定产品领域或特定内容类型投资过度还是投资不足？
- 该系列产品的流量与另一系列相比如何？
- 我该如何向我的利益相关者传达更广泛的趋势？
如果没有某种程度的汇总报告，您就无法回答这些问题，而汇总报告只能通过元数据获得。
在 Cloudflare，我们跟踪有关不同页面的以下信息：
| 属性 | 描述 | 示例 |
|---|---|---|
| Description（描述） | 填充 <meta name="description"> 标签的 1-2 句摘要。所有带 pcx_content_type 的页面都是必填的。 |
请参阅 frontmatter 指南。 |
| Product（产品） | 页面的顶级子文件夹。 | dns、bots |
| Product Group（产品组） | 每个产品所属的主要领域。 | Application Performance、Developer Platform |
| Content type（内容类型） | 页面的主要目的，对应于我们列出的 内容类型。 | how-to、faq |
| Last modified（最近修改） | 此页面最近一次更新是在多少天前？ | 63 |
| Last reviewed（最近评审）（可选） | 此页面最近一次评审是在多少天前？ | 100 |
在所有这些属性中，我们的 Last reviewed 元数据有一些细微的差别。Last reviewed 与 Last modified 不同，因为评审比更新更为彻底。评审意味着页面的所有内容都已通过准确性验证。
由于需要付出这种额外的工作，我们仅对与用户旅程特别相关且需要额外维护级别的内容类型跟踪 Last reviewed。目前，这些内容类型是 教程。
我们在两个不同级别设置这些值：文件夹级别和页面级别。
我们在文件夹级别设置两个值，Product 和 Product Group。我们采用这种方法是因为我们可以假定这些值适用于该文件夹内的每个页面。
例如，以下是来自我们的 DNS 文件夹 ↗ 的内容。
name: DNS
product:
title: DNS
url: /dns/
group: Application performance
meta:
title: Cloudflare DNS docs
description: Cloudflare DNS provides the fastest, most resilient, and simplest
managed DNS platform to meet your needs.
author: "@cloudflare"
resources:
community: https://community.cloudflare.com/tags/c/reliability/7/none
dashboard_link: https://dash.cloudflare.com/?to=/:account/:zone/dns
learning_center: https://www.cloudflare.com/learning/dns/what-is-dns/我们主要通过 页面的 frontmatter 设置页面级属性。
例如，以下是为我们的 构建 Slack 机器人教程 设置的值。
---
updated: 2024-06-05
difficulty: Beginner
pcx_content_type: tutorial
title: Build a Slackbot
tags:
- Hono
languages:
- TypeScript
---然而，last_modified 值是从文件的 git 历史记录中自动提取的。
在页面级别，必填的 products frontmatter 列出了相关的 Cloudflare 产品，这与文件夹级别的 Product 属性是分开的。
我们选择将所有这些值渲染为每个页面的特定 meta 属性。
例如，以下是 AI Crawl Control - 快速入门页面 上的 meta 属性和值。
<meta name="pcx_content_group" content="Core platform" >
<meta name="pcx_product" content="AI Crawl Control" >
<meta name="pcx_content_type" content="get-started" >
<meta name="pcx_last_modified" content="7" >我们使用 Head.astro ↗ 文件的自定义替代来渲染这些值。如果设置了特定值，我们会将它们作为 meta 标签添加到页面上。
if (product.data.product.title) {
["pcx_product", "algolia_product_filter"].map((name) => {
metaTags.push({
name,
content: product.data.product.title,
});
});
}通过这种方式结构化我们的内容，我们获得了两个主要益处。
首先，任何爬取我们页面的人都可以轻松消耗我们的元数据。我们最初将这些值用于我们的 Algolia 搜索配置和内部报告，但此后已扩展为与为 AI 系统消耗我们内容的其他团队共享这些数据。
此外，该决定意味着我们的 GitHub 仓库始终是真实信源。我们不必要在其他地方保持电子表格或映射关系更新，真实信源始终存在于我们的仓库中，因此，与维护多个真实信源相比，这极大地提高了准确性。
description frontmatter 字段填充了 HTML 头部中的 <meta name="description"> 标签。这是 AI 可检索性中唯一最重要的元数据字段。搜索引擎、AI 爬虫和 llms.txt frontmatter 块在决定是否引用页面时会消耗此值。
每个带有 pcx_content_type 的页面都必须包含 description。一个优秀的描述会指明产品名称、说明该页面如何帮助读者，并且在从页面中提取出来时可以作为独立的答案片段。
有关编写指导和示例，请参阅 编写描述。
有关我们如何向 AI 系统提供内容的更多信息，请参阅 AI 可消耗性。
使用这种元数据很难完全避免错误，特别是由于我们依赖在单个文件的 frontmatter 中自由输入文本。
我们在 Astro 网站中大量使用了 Zod schemas ↗，它们定义在 src/schemas/ ↗ 中。
这些允许我们为使用 IDEs 进行本地开发的贡献者提供 Intellisense 指南 ↗。
