企业官网建设流程全解析

Front-End Checklist 深度解析 about-page 技能：用 SEO 规则建立网站信任信号的完整方法

【免费下载链接】Front-End-Checklist🗂 The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist

skills/about-page是 Front-End Checklist 中面向 SEO 审计的一条规则技能，核心目标是确保网站拥有一个内容充实的独立 About 页面，以支撑 E-E-A-T（经验、专业性、权威性、可信度）信任信号。本篇以 SKILL.md 及其 完整规则参考 为主体，结合其源规则文件与生成脚本，讲清这条规则的检查标准、修复方式、验证手段，以及它在本仓库中从 MDX 到可安装技能的完整生产线。

一、规则定位：frontmatter 元数据解读

每个技能目录由 frontmatter 声明其元数据，about-page技能的头部声明如下（见 SKILL.md）：

--- name: about-page description: "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." metadata: category: seo priority: medium difficulty: intermediate estimatedTime: "10" source: frontendchecklist.io ---

这些字段并非手写的孤立信息，而是从源规则 packages/content/rules/en/seo/about-page.mdx 的 frontmatter 自动派生而来。对照源文件可以看到完整的元数据定义：

源文件中的prompts与aiContext字段则分别成为 SKILL.md 的四个执行指令段落与 description（aiContext优先于description使用），这一点可以直接在生成脚本 scripts/generate/generate-skills.ts 的buildSkillMd函数中得到印证：脚本会读取fm.aiContext || fm.description，并强制 description 以 "Use when" 开头，不足 50 字符时自动追加标题补全——这是技能能被 agent 意图匹配系统正确路由的关键约定。

二、核心要求：Quick Reference 与信任信号四支柱

规则正文（同时出现在 references/rule.md 与源 MDX）开宗明义：

An About page provides essential context about the source of the information on your website. It helps search engines and users understand the expertise and authority behind the content.

快速参考清单（Quick Reference）给出三条硬性检查点：

• 包含一个专门页面，解释网站的目的、历史与使命（purpose, history, and mission）
• 介绍内容背后的关键人物或组织，建立信任
• 提供清晰的专家资质证据（evidence of expertise）和联系信息

规则进一步在 "Why It Matters" 一节给出四条为什么重要的依据：

• E-E-A-T：直接支撑 Google 质量评估指南中 Trustworthiness（可信度）与 Authoritativeness（权威性）两大支柱；
• Transparency：向用户表明"你是谁"，降低跳出率并建立长期品牌忠诚；
• Entity Recognition：帮助搜索引擎把网站与真实世界实体（个人或组织）关联起来；
• Compliance：对许多行业而言，标明内容创建者是法律或监管要求。

三、Check / Fix / Explain / Code Review：四段式审计工作流

SKILL.md 的主体是由源 MDXprompts字段派生的四段指令，定义了 agent 执行这条规则的标准动作：

Check —— 检查什么

Verify that the website has a dedicated About page that clearly identifies the people or organization responsible for the content.

检查重点是"是否"存在独立 About 页，且页面是否明确点出对内容负责的人或组织。注意 frontmatter 中aiContext的强调：应验证渲染后的 HTML 与 HTTP 响应，而不是只依赖源文件——因为静态源码里写好了路由不等于线上页面真实可达、可被索引。

Fix —— 怎么修

Create a new page at/aboutand add detailed information about your organization, mission, and the experts behind your content.

修复动作明确：在/about路径下新建页面，写入关于组织、使命与内容背后专家的详细信息。

Explain —— 向用户解释什么

Explain how an About page contributes to E-E-A-T (Experience, Expertise, Authoritativeness, and Trustworthiness) and why it's a critical SEO factor.

要求把修复的意义落到 E-E-A-T 框架上解释，而非泛泛谈 SEO。

Code Review —— 代码审查范围

Review metadata generation, rendered HTML, structured data, and response headers related to Create a dedicated About page. Flag exact routes or templates where search-facing output violates the rule, and describe how to verify the final page output.

代码审查边界覆盖四个层面：元数据生成、渲染 HTML、结构化数据与响应头，并明确要求指出违反规则的具体路由或模板、说明如何验证最终页面输出——这与本仓库全局审计技能的"保守立场"（宁可少报、只报有直接证据的问题）一脉相承，可参考 skills/frontend-checklist-global/SKILL.md 中的 Audit Stance 章节。

四、代码示例：让 About 页面可被发现

规则强调一个常被忽略的细节：About 页面本身存在还不够，它必须"易于被发现"，通常通过主导航或页脚链接实现。源 MDX 给出的标准 HTML 示例（见 about-page.mdx）：

<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"提供导航地标语义，列表结构与页脚中常见的 About / Contact / Privacy Policy 三件套并列。这实际上与可访问性规则中 landmark 导航的要求相互呼应——About 页链接的可发现性本身就是一条 HTML 结构检查。

五、Exceptions：判断边界，避免误报

规则文档专门列出三条例外情形，这对 agent 执行审查时的"尺度把握"非常重要：

1. 必要的工具页或合规页可以有意的简短——不应以排名导向内容的编辑深度标准来要求它们。换句话说，About 页的"充实"要求不应被套用到隐私政策等功能性页面头上；
2. AI 辅助撰写本身不构成失败——真正该被标记的是无依据的声明、缺失的编辑审查或低原创度输出；
3. 先可排名，再谈质量：当一个页面同时存在信任信号问题与抓取/索引问题时，应先把页面变成"可被排名"（eligible to rank），再改进内容质量信号。

六、Standards 与 Verification：如何确认规则已满足

判定标准

• 以参考来源作为最终面向搜索的 HTML、元数据与抓取行为的标准；
• 在认定规则满足之前，需对照 Google Search Central 的 Search Essentials 与 Google Search Central 文档逐项核对（对应源 MDXsources中role: search与role: implementation的两个一手来源）。

自动化检查（Automated Checks）

• 检查渲染后的 HTML 与 HTTP 头，确认预期的元数据或可抓取性信号存在；
• 在适用时用 Google Search Console 或同类工具测试受影响 URL；
• 部署后对代表性页面集合重新抓取（re-crawl）。

人工检查（Manual Checks）

• 确认改动没有引入相互冲突的 canonical-url、robots 或结构化数据信号——例如新建的/about页不应被 noindex、不应有指向别处的 canonical，也不应携带与页面内容矛盾的 JSON-LD。

七、仓库工程视角：这个技能是如何生成的

理解skills/about-page的生产机制，能解释为什么它的结构与全仓库 380 余条规则技能完全一致。关键调用链如下：

1. 唯一事实源：规则内容以 MDX 形式存放在 packages/content/rules/en/seo/about-page.mdx，skills/about-page/下两个文件全部由它派生；
2. 生成脚本：scripts/generate/generate-skills.ts 用 gray-matter 解析 frontmatter，buildSkillMd组装 SKILL.md（frontmatter + 标题 + Quick Reference + 四段 prompt + 指向 references 的指引），buildReferencesMd则把 MDX 正文经stripMdxToMarkdown去除 JSX 后生成references/rule.md（见 buildReferencesMd 实现）。脚本采用扁平目录skills/{skillName}/，以通过 skill-check 的name_matches_directory校验；若同一 slug 跨类别重名，会自动加类别前缀（findDuplicateSlugs 逻辑）；
3. 提交时自动再生成：lefthook.yml 配置了generate-skills钩子——凡packages/content/rules/en/**/*.mdx有改动，pre-commit 即执行pnpm tsx scripts/generate/generate-skills.ts {staged_files} && git add skills/增量重建，并同步触发validate-rule-structure、validate-evidence、score-rules等质量门禁；
4. 全量重建：在仓库根目录执行pnpm generate:skills可重生成全部技能（README.md 的贡献流程与 scripts/README.md 的脚本清单均有说明）。

因此，若你只读仓库、想追溯某条技能文本的出处，路径是固定的：skills/{slug}/SKILL.md→ 源 MDX frontmatter；skills/{slug}/references/rule.md→ 源 MDX 正文。

八、实际使用：安装与调用方式

在支持 agent skills 的工具中安装本技能（README.md 的 "Use with skills" 一节给出了标准用法）：

# 安装全部技能 npx skills add frontendchecklist/skills # 只安装 about-page 这一条规则技能 npx skills add frontendchecklist/skills --skill about-page

安装后，当 agent 面对"审计某个站点的元数据、可抓取性或索引性"类请求时，会因 description 的 "Use when auditing metadata, crawlability, structured data, or indexability..." 前缀被路由到本技能，并按 Check → Fix → Explain → Code Review 四段指令执行。执行要点重申一遍：以渲染后的页面为证据，而不是只看源码。

九、关联规则：信任信号审计的完整拼图

源 MDX 的relatedRules字段声明了四条同属seo/content区域、常一起审查的规则，它们与 about-page 共同构成"网站可信度"检查面：

• contact-page：独立的联系页面，与 About 页同为信任与可达性信号；
• editorial-policy：编辑政策声明，支撑内容生产流程的可信度；
• author-byline：作者署名，把内容责任落到具体的人；
• affiliate-disclosure：联盟营销披露，属于合规层面的透明度要求。

实践中建议按"先可达、再可信、后详尽"的顺序处理：先确认 About 页路由真实存在且未被 canonical/robots 信号排斥，再补齐组织信息、专家资质与联系方式，最后与其他信任信号规则一起统一审查，即可完整覆盖这条规则的验收标准。

【免费下载链接】Front-End-Checklist🗂 The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist