Front-End Checklist 深度解析 about-page 技能:用 SEO 规则建立网站信任信号的完整方法
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 自动派生而来。对照源文件可以看到完整的元数据定义:
| 字段 | 值 | 含义 |
|---|---|---|
title |
Create a dedicated About page | 规则标题 |
categories / subcategory |
seo / content | 归属 SEO 大类下的内容子类 |
priority |
medium | 中等优先级,非阻断性问题 |
difficulty |
intermediate | 实施难度为中级 |
estimatedTime |
10(分钟) | 预计修复耗时 |
sources |
Google Search Central: Search Essentials、Google Search Central documentation | 规则依据的两个一手权威来源(均以 authority: primary 标注) |
resources |
Google Search Console | 可用于验证的工具 |
relatedRules |
contact-page、editorial-policy、author-byline、affiliate-disclosure | 常一起审查的关联规则 |
源文件中的 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 的主体是由源 MDX prompts 字段派生的四段指令,定义了 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 执行审查时的"尺度把握"非常重要:
- 必要的工具页或合规页可以有意的简短——不应以排名导向内容的编辑深度标准来要求它们。换句话说,About 页的"充实"要求不应被套用到隐私政策等功能性页面头上;
- AI 辅助撰写本身不构成失败——真正该被标记的是无依据的声明、缺失的编辑审查或低原创度输出;
- 先可排名,再谈质量:当一个页面同时存在信任信号问题与抓取/索引问题时,应先把页面变成"可被排名"(eligible to rank),再改进内容质量信号。
六、Standards 与 Verification:如何确认规则已满足
判定标准
- 以参考来源作为最终面向搜索的 HTML、元数据与抓取行为的标准;
- 在认定规则满足之前,需对照 Google Search Central 的 Search Essentials 与 Google Search Central 文档逐项核对(对应源 MDX
sources中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 余条规则技能完全一致。关键调用链如下:
- 唯一事实源:规则内容以 MDX 形式存放在 packages/content/rules/en/seo/about-page.mdx,
skills/about-page/下两个文件全部由它派生; - 生成脚本: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 逻辑); - 提交时自动再生成: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等质量门禁; - 全量重建:在仓库根目录执行
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 信号排斥,再补齐组织信息、专家资质与联系方式,最后与其他信任信号规则一起统一审查,即可完整覆盖这条规则的验收标准。
atomcodeClaude Code 的开源替代方案。连接任意大模型,编辑代码,运行命令,自动验证 — 全自动执行。用 Rust 构建,极致性能。 | An open-source alternative to Claude Code. Connect any LLM, edit code, run commands, and verify changes — autonomously. Built in Rust for speed. Get StartedRust0622
Hy4-previewHy4 preview 是由腾讯混元团队研发的新一代混合专家(MoE)旗舰模型。模型总参数量 770B,每个 token 激活 49B,主干共包含78层,第一层采用标准 FFN,其余 77 层均为 MoE 结构,每层包含 256 个路由专家与 1 个共享专家,每个 token 激活 top-8 路由专家及共享专家。主干之外原生内置 1 层 MTP(总参数量 10B,激活 0.7B)以支持投机解码。Python00
GLM-5.3GLM-5.3 与 GLM-5.2 使用相同的基座模型——所有提升均来自后训练。与 GLM-5.2 相比,它在复杂编程和长程任务上的表现显著提升。Jinja00
GLM-5.3-FlashGLM-5.3-Flash (320B-A18B),是GLM-5系列的首个原生多模态模型。320B总参数,能力超过GLM-5.2Jinja00
Spark-X2.5-4BSpark-X2.5-4B 旨在让强大的 AI 更实用、更高效、更易获得。在广泛日常任务中表现强劲,涵盖对话、写作、翻译、推理、编码、工具调用以及智能体工作流,并在同等规模的开源模型中取得领先成绩。Spark-X2.5 将面向效率的架构与最高 1M tokens 的原生上下文窗口相结合,并支持 200 多种语言。Python00
Spark-X2.5-1.7BSpark-X2.5-1.7B 旨在让强大的 AI 更加实用、高效且易于获取。这些模型在广泛的日常任务中表现出色,涵盖对话、写作、翻译、推理、编程、工具调用和智能体工作流,并在同等规模的开源模型中取得领先结果。Spark-X2.5 将面向效率的架构与最高 1M tokens 的原生上下文窗口相结合,并支持 200 多种语言。Python00