Front-End-Checklist 的 word-count 规则全解析：用“内容深度“而非字数量化识别并修复关键页面的瘦内容

本文聚焦开源仓库 Front-End-Checklist 中的word-count规则（英文名Avoid thin content on key pages）。该规则以seo分类下的一条 MDX 规则文件为源头，并自动生成为一个可安装的 Agent Skill。读完本文，你将掌握：为什么字数不是衡量"瘦内容（thin content）"的可靠指标、如何按仓库给出的检查流程审计关键页面的内容深度、以及如何用扩写、合并、noindex三种策略修复低质页面，并理解该规则在仓库中从 MDX 到 SKILL 的完整落地链路。

规则定位：一份文档、两种载体

在 Front-End-Checklist 仓库中，word-count 规则并非孤立的单文件，而是以"规则内容源 + 可执行技能"的双载体形态存在：

• 规则内容源（MDX）：位于 packages/content/rules/en/seo/word-count.mdx，是规则的权威定义。其 frontmatter 声明了title: Avoid thin content on key pages、category: seo、subcategory: content、priority: medium、difficulty: beginner、estimatedTime: 10，即这是一个中优先级、适合初学者的内容审计规则，预计耗时约 10 分钟。
• Agent Skill：由规则自动生成的技能目录位于 skills/word-count/，包含两个文件：
  • SKILL.md：面向 Agent 的"速查指令卡"，frontmatter 中带有name、description、metadata（category/priority/difficulty/estimatedTime/source），正文由 Quick Reference、Check、Fix、Explain、Code Review 五段可执行提示词构成；
  • references/rule.md：SKILL.md 正文末尾指向的完整实现细节文档，即 MDX 正文剥离 MDX 语法后的纯 Markdown 版本，包含代码示例、内容深度对照表、正反例与验证清单。

这两个载体内容同源：SKILL.md 用于快速触发，references/rule.md 用于完整执行。规则发布页为https://frontendchecklist.io/en/rules/seo/word-count（即source字段标注的官方站点，实际渲染源正是上述 MDX）。

核心判据：字数从来不是唯一的指标

规则开篇就给出了四条"速查要点（Quick Reference）"，这也是全文最容易被误读的地方——word-count 规则并非在设定字数门槛，而是在纠偏"只看字数"的思维：

1. 瘦内容不由字数单独定义——一个 200 词的页面如果完整回答了查询意图，就不算瘦内容；
2. 页面如果独有内容极少（低于约 200 词）且未满足用户意图，则有被判定为低质量内容的风险；
3. Google 的 Helpful Content（实用内容）指南强调深度、准确性和有用性优先于原始字数；
4. 相比套用固定字数标准，更应将目标查询的内容深度与前排竞争对手对比。

这四条要点同时出现在 word-count.mdx 的tldr字段和 SKILL.md 的 Quick Reference 中，是该规则被搜索引擎与 Agent 检索时最重要的摘要信息。

为什么这么说？仓库中的姊妹规则 quality.mdx 也给出了呼应性的"瘦内容红旗清单"：信息型页面字数低于 300 词、内容可套用到任何商家（如"We deliver quality service"）、由变量替换生成的模板文本、单一来源的复制改写、多个近义页面——可见"瘦"的本质是缺乏独有价值，字数只是最易观察的代理指标。

Check：如何审计一个关键页面的内容深度

规则为 Agent 和人工审计者定义了标准检查动作（见 SKILL.md 的check提示词与 rule.md）：

1. 统计可见正文单词数：只统计用户可见的 body 文本，排除导航（navigation）、页头（headers）、页脚（footers）；
2. 标记低于 200 词独有正文内容的页面：这是规则给出的经验触发线；
3. 信息型查询的页面与搜索结果前 3 名做深度对比：比较主题覆盖度，而不是单纯比字数；
4. 识别样板文本（boilerplate）与内容稀薄的 CMS 模板页：例如套用同一模板、仅替换少量变量的页面。

references/rule.md中还给出了一个四步"代码示例"流程，可以理解为一次完整的诊断会话：

1. Identify pages ranking on page 2–4 for target keywords 2. Compare your word count and topic coverage to top 3 results 3. Check if your page answers the implied questions in the query 4. Look for boilerplate, duplicate, or auto-generated sections

即：先找出在目标关键词上排在 2–4 页的页面 → 与前 3 名对比字数和主题覆盖 → 检查页面是否回答了查询中的隐含问题 → 排查样板化、重复或自动生成区块。

Fix：三种修复策略与扩写模式

根据 SKILL.md 的fix提示词和 rule.md，修复手段按优先级分三类：

策略一：扩写（Expand）

围绕用户真正在找的话题扩充内容，规则明确给出的扩写素材包括：

• FAQ（常见问题）
• 示例（examples）
• 对比（comparisons）
• 分步教程（how-to steps）
• 数据（data）

references/rule.md提供了一个可直接套用的产品页扩写模式：

<!-- Expanded product page --> <h1>Blue Widget Pro</h1> <p>The Blue Widget Pro is engineered for [specific use case]...</p> <h2>Key Features</h2> <ul> <li>Feature 1: explains the benefit, not just the spec</li> <li>Feature 2: ...</li> </ul> <h2>Who It's For</h2> <p>Ideal for [specific audience] who need [specific outcome]...</p> <h2>Frequently Asked Questions</h2> <!-- FAQ schema-marked questions and answers -->

注意其中的关键写作手法：讲功能要讲"收益"而不是"规格"，并为 FAQ 搭配 FAQPage 结构化数据（schema-marked）——这与仓库中 faq.mdx 等结构化数据规则是配套使用的。

策略二：合并（Consolidate）

如果某个瘦内容页面无法有意义地扩写，规则给出的处置顺序是：

1. 301 重定向到同一主题更全面的页面；
2. 合并（merge）多个相关瘦页面为一篇更强的页面；
3. noindex：如果页面承担功能性用途但本就不打算参与排名，则对其添加noindex，避免它在搜索结果中竞争。

策略三：删除

无法扩写、也无合并价值的页面直接移除，避免稀释站点整体质量信号。

Google 官方语境下的四种 Thin Content 模式

references/rule.md明确引用了 Google 的 spam policies（垃圾内容政策），其中将以下四类定义为典型的瘦内容模式，供审计时对照：

规则同时强调：这些模式与"一篇写得很好的 150 词页面"有本质区别——后者完整回答了具体问题，不应被判为瘦内容。这也是为何本条规则必须结合搜索意图和有用性来判定，而不能只套固定最低字数。

内容深度参考表：分页面类型的指导线

references/rule.md给出了按页面类型划分的内容深度参考，这是实践中最常被直接查阅的表格：

表格末尾的备注同样重要：这些是指导线而非规则——一个 100 词的页面若能完整回答一个简单问题，就不算瘦内容。这也再次印证"以用户意图和竞争内容为准"的核心判定逻辑。

反例与正例：一眼识别瘦内容写法

references/rule.md提供了两组 HTML 对照，是规则最有教学价值的部分：

❌ 瘦内容反例——只有厂商描述的产品页（仅 14 词）、只有商品网格而无任何正文的分类页（0 词正文）：

<!-- Product page with only the manufacturer description --> <h1>Blue Widget Pro</h1> <p>The Blue Widget Pro is available in blue. SKU: BWP-001. Buy now.</p> <!-- 14 words — provides no value beyond what a product listing would show --> <!-- Category page with no content, just a grid of products --> <h1>Shoes</h1> <div class="product-grid"><!-- 48 products listed --></div> <!-- 0 words of body content — Google may not index this page prominently -->

✅ 扩写正例——即上文"Fix"小节中的产品页结构。两例对比可以看出本质差异：反例只回答了"What is it / where to buy"，正例则回答了"What problem does it solve / who is it for / what do customers ask"这些隐含查询问题。

Exceptions：规则允许的例外

规则明确列出三类不应被"一刀切"处理的情况（见 rule.md 与 word-count.mdx）：

• 必要的工具页/合规页可以有意保持简短，不应以排名型内容的编辑深度标准去评判；
• AI 辅助起草本身不是问题——应标记的是无依据的主张、缺少人工编辑审校、或低原创度的输出（这与 ai-content.mdx 的 Exceptions 完全一致）；
• 当页面同时存在信任信号问题和抓取/收录问题时，应先让页面具备排名资格，再改进内容质量信号——即优先级是"可被收录"优先于"内容够深"。

Explain 与 Code Review：面向 Agent 与代码评审的执行指令

SKILL.md 中的两段提示词定义了规则在"解释"与"代码评审"两个场景下的用法：

Explain（解释）——需要向他人说明：Google 质量系统中"瘦内容"的含义、为什么字数单独不足以作为有效指标、以及如何结合用户意图和竞争内容评估内容深度（SKILL.md）。

Code Review（代码评审）——审查与"关键页面瘦内容"相关的元数据生成、渲染后 HTML、结构化数据、响应头，标记搜索对外输出违反本规则的具体路由（routes）或模板（templates），并说明如何验证最终页面输出（SKILL.md）。这条指令提示了工程化落地的关键：瘦内容问题往往不只在文案，而在模板与路由层面——一个内容为空的 CMS 模板会让所有套用它的页面集体变瘦。

Standards 与 Verification：如何判定规则已满足

references/rule.md的收尾部分给出了"验收标准"：

Standards（标准）：

• 以这些参考资料作为最终搜索对外 HTML、元数据与抓取行为的验收标准；
• 以 Google 的Creating helpful, reliable, people-first content指南核验实现；
• 以 Google 的Thin content spam policy（瘦内容垃圾政策）核验实现。

Verification（验证）：

• 自动化检查：检查渲染后的 HTML 与 HTTP 响应头，确认预期的元数据或可抓取性信号存在；用 Google Search Console 或同类工具测试受影响 URL；部署后对代表性页面集重新抓取。
• 人工检查：确认改动没有产生互相冲突的 canonical-url、robots 或结构化数据信号——这条与仓库中 canonical-url.mdx、robots-meta.mdx 等规则形成了验证闭环：修复瘦内容时若动了noindex或结构化数据，必须同步核对这些信号的一致性。

与相邻规则的协同：seo/content 内容家族

word-count.mdx的 frontmatter 通过relatedRules显式声明了协同规则（word-count.mdx），全部位于seo/content内容域，推荐一并审查：

• quality：内容质量是 Google 的首要排名差异化因素，瘦内容（低字数、通用文案）是排名流失的首要原因之一，两者常被一起评审；
• ai-content：审查 AI 生成内容的准确性、独有价值与人性化表达，防止站点变成"同一批 AI 提示词下的复制品"；
• ymyl-detection：YMYL（Your Money or Your Life）领域的错误建议可能造成实际伤害，AI 幻觉事实必须人工核验；
• disclaimers：声明类内容同属内容域，常与内容质量信号一并检查。

此外 quality.mdx 反向引用了 word-count，形成双向关联。在实际审计中，建议把"瘦内容判定"作为质量审计的第一道筛子：先识别哪些页面值得深查，再用 E-E-A-T 框架评估深度与信任信号。

从 MDX 到 SKILL：这条规则在仓库中的生成链路

理解这条规则在仓库中的"生产机制"，能帮助读者更好地使用它。根据 scripts/generate/generate-skills.ts 的文档注释，技能由规则 MDX 的 frontmatter 自动生成：

• 输入目录为packages/content/rules/en，输出目录为skills/；
• 每条规则生成一个skills/{category}/{slug}/目录，内含SKILL.md（name、description、prompts 作为指令）与references/rule.md（MDX 正文转纯 Markdown）；
• word-count 的生成物正好落在skills/word-count/，与skills/word-count/SKILL.md的 frontmatter（category: seo、source: frontendchecklist.io）一致；
• 生成脚本将prompts.check / fix / explain / codeReview直接映射为 SKILL.md 正文的四个执行段落，这正是本文前面引用的"Check/Fix/Explain/Code Review"结构的来源。

技能可安装使用（脚本注释中给出的两种方式）：

# 安装全部技能 npx skills add frontendchecklist/skills # 只安装 word-count 技能 npx skills add frontendchecklist/skills --skill word-count

仓库内还可通过pnpm generate:skills（全部规则）或指定具体 MDX 文件路径来重新生成技能（后者由 lefthook 在变更时触发）。也就是说：修改 word-count.mdx 并重新生成，即可同步刷新 SKILL 与参考文档——内容源始终唯一，Agent 技能与人工文档保持同源一致。

结语

Front-End-Checklist 的 word-count 规则表面上是"字数检查"，内核却是一套以用户意图为中心的内容质量审计方法论：用 ~200 词作为触发线识别候选页面，用与前 3 名排名的主题覆盖对比做深度判断，用扩写/合并/noindex 三种策略分类处置，最后通过渲染 HTML、响应头与结构化数据的一致性验证收尾。它同时以 MDX 规则、Agent Skill 两种形态交付，既适合人工对照 rule.md 执行审计，也可直接作为 AI 辅助工具触发"检查 → 修复 → 解释 → 代码评审"的完整工作流。理解并落地这条规则，等于为站点搭建了一道"低质内容防火墙"——尤其在 AI 辅助写作普及、模板化内容泛滥的当下，判断标准始终应该回到那句话：页面是否提供了相对于用户搜索意图的独有价值。