Front-End Checklist 中的「创建专用 About 页面」SEO 规则：E-E-A-T 信任信号的落地与验证

Front-End Checklist 仓库把「网站是否拥有一个内容充实的专用 About（关于）页面」定义为一条独立的 SEO 审查规则（about-page），优先级为 medium、难度 intermediate、预计耗时 10 分钟。本文围绕 rules/about-page 规则文档 展开，讲清这条规则的审查要点、标准 HTML 实现示例、背后的 E-E-A-T 原理、例外情形与部署后的验证流程，并结合本仓库自身真实的 About 页面源码与页脚导航实现，展示一条规则从"检查清单条目"到"可运行页面"的完整落地路径。

规则定位与元信息

在仓库中，这条规则存在两种互补形态：

• 面向 AI Agent 的技能文件：SKILL.md 声明了技能的名称（about-page）、类别（seo）、优先级（medium）、难度（intermediate）、预计耗时（"10"）与来源（frontendchecklist.io），并给出给 AI 的执行指令 aiContext："Use when auditing metadata, crawlability, structured data, or indexability related to Create a dedicated About page. Verify the rendered HTML and HTTP response rather than relying only on source files."——即审查时要以渲染后的 HTML 与 HTTP 响应为准，而不是只看源码文件。
• 面向人阅读的规则正文：rules 正文 以 MDX 形式存储，frontmatter 中声明了 categories: [seo]、subcategory: content、priority: medium、difficulty: intermediate、estimatedTime: 10，并附带完整的 prompts（check / fix / explain / codeReview 四段式提示词）、sources（Google Search Central: Search Essentials 等权威来源）与 relatedRules。

两条形态的正文内容一致，核心判断只有一句话：Verify that the website has a dedicated About page that clearly identifies the people or organization responsible for the content.（确认网站存在一个能清楚指明"内容由谁负责"的专用 About 页面。）

规则的检查、修复与解释三段式

规则文档（rule.md 与 about-page.mdx）采用统一的 Quick Reference + Check/Fix/Explain 结构：

Quick Reference（快速要点）

• 提供一个专用页面，解释网站的目的（purpose）、历史（history）与使命（mission）
• 介绍内容背后的关键人物或组织，以建立信任
• 提供明确的"专业性证据"（evidence of expertise）与联系方式（contact information）

Check（检查）：验证网站是否拥有专用 About 页面，且页面清楚标识了内容的责任主体（人或组织）。

Fix（修复）：在 /about 路径下创建新页面，补充关于组织、使命以及内容专家的详细信息。

Explain（解释）：说明 About 页面如何贡献于 E-E-A-T（Experience、Expertise、Authoritativeness、Trustworthiness），以及它为何是关键 SEO 因素。

Code Review（代码审查）：在 Front-End Checklist 的规则体系里，每条规则还附带 codeReview 提示词——审查与 About 页面相关的元数据生成、渲染后 HTML、结构化数据与响应头，标记出违反该规则的精确路由或模板，并描述如何验证最终页面输出。这保证了规则不仅停留在内容层面，而是可以落到路由、模板与 metadata 代码上。

标准实现示例：让 About 页面可被发现

规则正文给出的标准代码示例强调一个前提：About 页面必须"容易被发现"（easily discoverable），通常通过主导航或页脚：

<footer>
  <nav aria-label="Footer Navigation">
    <ul>
      <li><a href="/about">About Us</a></li>
      <li><a href="/contact">Contact</a></li>
      <li><a href="/privacy-policy">Privacy Policy</a></li>
    </ul>
  </nav>
</footer>

示例中值得注意的工程细节：<nav> 使用 aria-label="Footer Navigation" 提供导航语义标签，使屏幕阅读器能区分页脚导航与其他导航区块——这与仓库中大量可访问性规则（如 landmark-regions、navigation-landmark）形成呼应。

本仓库自身的真实实现

Front-End Checklist 网站本身就提供了这条规则的实战参照。

页脚导航：footer.tsx 中定义了 PROJECT_LINKS 常量，通过 routeAbout() 路由助手函数生成 About 链接：

const PROJECT_LINKS = [
  { href: routeAbout(), label: 'About' },
  { href: routeMentions(), label: 'Community Mentions' },
  { href: GITHUB_REPO_URL, label: 'Source Code', external: true },
  { href: '/sitemap.xml', label: 'Sitemap' }
] as const

这里有一个与标准示例的关键差异：路由不是硬编码的 /about 字符串，而是来自 @repo/config 包的 routeAbout() 等路由助手函数（config 包），外部链接则带 target="_blank" 与 rel="noopener noreferrer"，并附 sr-only 的 "(opens in new tab)" 辅助文本。页脚每个栏目渲染为带 aria-labelledby 的 <nav>（见 footer.tsx），与标准示例中 aria-label 的语义化做法一脉相承，只是改用 aria-labelledby 指向栏目标题，避免重复的无障碍标签。

About 页面本身：about/page.tsx/about/page.tsx) 展示了 Next.js App Router 下的完整实现模式：

export const metadata = {
  ...pageMetadata.home,
  title: 'About the Creator | Front-End Checklist',
  description:
    'Learn more about David Dias, the creator of the Front-End Checklist, and his other projects.'
}

export default async function AboutPage() {
  'use cache'
  cachePublicContent()
  // ... 渲染页面标题、项目介绍与创作者项目区块
}

可以看到它同时满足了规则的多个检查点：页面位于可预测的 /about 路由；页面级 metadata 提供了独立的 title 与 description（复用 pageMetadata 公共元数据并覆盖标题，见 lib/seo 提供的 pageMetadata 助手）；页面内容介绍"这个网站为谁创建、解决什么问题"，并内嵌 UpcomingBook、CreatorProjects 等区块（见 components/about）来呈现内容背后的创作者——这正是规则要求的"介绍内容背后的关键人物"。

为什么重要：E-E-A-T 的四根支柱

规则文档的 "Why It Matters" 一节给出了四条理由，这也是该规则在 seo/content 分类下的理论根基：

1. E-E-A-T：直接支撑 Google《Quality Rater Guidelines》中 Trustworthiness（可信度）与 Authoritativeness（权威性）两根支柱；
2. 透明度（Transparency）：向用户表明"你是谁"，降低跳出率、建立长期品牌忠诚；
3. 实体识别（Entity Recognition）：帮助搜索引擎把网站与真实世界的实体（个人或组织）关联起来；
4. 合规（Compliance）：在许多行业中，标明内容创建者是法律或监管要求。

从 about-page.mdx 的 frontmatter 看，规则把 whyItMatters 概括为一句话："An About page is a primary trust signal for both users and search engines, directly impacting the website's E-E-A-T profile and overall credibility."——About 页面同时面向用户与搜索引擎，是首要的信任信号。

例外情形：不要把规则机械套用到每一页

规则文档专门列出三条 Exceptions（例外），用于防止审查工具误报：

• 工具型/合规型页面允许简短：必要的实用页面或合规页面可以故意写得简略，不应以"排名导向内容"的编辑深度标准来衡量它们；
• AI 辅助起草本身不是失败：应标记的是"无依据的声明、缺少编辑审核、原创性不足"的具体问题，而不是"使用了 AI"这一事实本身；
• 先解决收录，再谈质量：当一个页面同时存在信任信号问题与爬取/索引问题时，应先让页面"具备参与排名的资格"，再改进内容质量信号。

这些例外体现了仓库规则体系的一贯立场：规则服务于最终面向搜索的 HTML、元数据与爬取行为，而非孤立地评判单个文件。

判定标准（Standards）

规则文档的 Standards 一节要求以外部权威标准作为判定依据：

• 以所引用的参考文档作为最终面向搜索的 HTML、元数据与爬取行为的标准；
• 在认定规则"已满足"之前，先对照 Google Search Central: Search Essentials 检查实现；
• 在认定规则"已满足"之前，先对照 Google Search Central 文档检查实现。

about-page.mdx 的 frontmatter 将这些参考固化为结构化数据：sources 中收录了 "Google Search Central: Search Essentials"（authority: primary）与 "Google Search Central documentation"，resources 中收录了 Google Search Console 作为可用工具。这意味着该规则的证据链是"规则文档 → 权威来源声明 → 实现对照"，而不是经验性判断。

验证方法：自动化 + 人工双通道

规则的 Verification 一节把验证拆成自动化检查与人工检查两类，这也是 Front-End Checklist 多数规则共用的验证框架。

自动化检查（Automated Checks）

• 检查渲染后的 HTML 与 HTTP 响应头，确认预期的元数据或可爬取信号存在（例如 /about 返回 200、有 title/description、未被 noindex 屏蔽）；
• 在相关场景下，用 Google Search Console 或同类工具测试受影响 URL 的收录状态；
• 部署后对代表性页面集合重新爬取（re-crawl），确认信号在真实环境中生效。

人工检查（Manual Checks）

• 确认改动没有引入相互冲突的 canonical-url、robots 或结构化数据信号——例如 About 页面没有被误设 canonical 指向其他页面，或 robots 策略误伤。

在 Front-End Checklist 仓库自身中，这类验证有现成的落点：sitemap.ts 决定哪些路由进入站点地图、robots.ts 决定爬取策略，两者共同构成"About 页面可被收录"的基础设施；docs/generated/rules-catalog.md 则收录了 about-page 在内的完整规则目录，便于审查者按类别定位规则。

相关规则：About 页面不是孤立存在的

about-page.mdx 的 frontmatter 通过 relatedRules 声明了四条同属 seo/content 领域、通常被一起审查的规则：

相关规则	关联理由
contact-page	同属 seo/content，常与 About 页面一起审查（联系方式是规则 Quick Reference 的第三项）
editorial-policy	同属 seo/content，编辑政策与内容可信度互为佐证
author-byline	同属 seo/content，作者署名与 About 页面共同构成 E-E-A-T 证据链
affiliate-disclosure	同属 seo/content，利益披露是透明度的另一维度

这提示一个实操结论：审查 About 页面时，应把 /contact、作者信息、披露声明一并纳入同一轮检查，因为 E-E-A-T 的 Trustworthiness 维度依赖多个信号相互印证，单页达标并不等于整站达标。

小结

about-page 这条规则浓缩了 Front-End Checklist 规则体系的设计范式：

1. 结构化元数据（priority / difficulty / estimatedTime / sources / relatedRules）让规则可被工具与 Agent 机器消费；
2. Quick Reference + Check/Fix/Explain/Code Review 四段式让规则对人和 AI 都可执行；
3. 标准示例 + 例外 + 判定标准 + 双通道验证让规则可判定、可复核，避免机械误报；
4. 仓库自身即是参照实现：about 页面/about/page.tsx) 与 页脚导航 展示了路由助手函数、页面级 metadata、语义化 nav 等落地细节。

对开发者而言，落地这条规则的最小路径是：在 /about 创建页面 → 在主导航或页脚加入可发现的链接 → 补齐组织/人物/使命内容与独立 title/description → 确认 robots、sitemap、canonical 与结构化数据无冲突 → 部署后重新爬取验证信号生效。