【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址https://gitcode.com/gh_mirrors/fr/Front-End-Checklist点击查看免费下载本文聚焦开源仓库 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、metadatacategory/priority/difficulty/estimatedTime/source正文由 Quick Reference、Check、Fix、Explain、Code Review 五段可执行提示词构成references/rule.mdSKILL.md 正文末尾指向的完整实现细节文档即 MDX 正文剥离 MDX 语法后的纯 Markdown 版本包含代码示例、内容深度对照表、正反例与验证清单。这两个载体内容同源SKILL.md 用于快速触发references/rule.md 用于完整执行。规则发布页为https://frontendchecklist.io/en/rules/seo/word-count即source字段标注的官方站点实际渲染源正是上述 MDX。核心判据字数从来不是唯一的指标规则开篇就给出了四条速查要点Quick Reference这也是全文最容易被误读的地方——word-count 规则并非在设定字数门槛而是在纠偏只看字数的思维瘦内容不由字数单独定义——一个 200 词的页面如果完整回答了查询意图就不算瘦内容页面如果独有内容极少低于约 200 词且未满足用户意图则有被判定为低质量内容的风险Google 的 Helpful Content实用内容指南强调深度、准确性和有用性优先于原始字数相比套用固定字数标准更应将目标查询的内容深度与前排竞争对手对比。这四条要点同时出现在 word-count.mdx 的tldr字段和 SKILL.md 的 Quick Reference 中是该规则被搜索引擎与 Agent 检索时最重要的摘要信息。为什么这么说仓库中的姊妹规则 quality.mdx 也给出了呼应性的瘦内容红旗清单信息型页面字数低于 300 词、内容可套用到任何商家如We deliver quality service、由变量替换生成的模板文本、单一来源的复制改写、多个近义页面——可见瘦的本质是缺乏独有价值字数只是最易观察的代理指标。Check如何审计一个关键页面的内容深度规则为 Agent 和人工审计者定义了标准检查动作见 SKILL.md 的check提示词与 rule.md统计可见正文单词数只统计用户可见的 body 文本排除导航navigation、页头headers、页脚footers标记低于 200 词独有正文内容的页面这是规则给出的经验触发线信息型查询的页面与搜索结果前 3 名做深度对比比较主题覆盖度而不是单纯比字数识别样板文本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数据datareferences/rule.md提供了一个可直接套用的产品页扩写模式!-- Expanded product page -- h1Blue Widget Pro/h1 pThe Blue Widget Pro is engineered for [specific use case].../p h2Key Features/h2 ul liFeature 1: explains the benefit, not just the spec/li liFeature 2: .../li /ul h2Who Its For/h2 pIdeal for [specific audience] who need [specific outcome].../p h2Frequently Asked Questions/h2 !-- FAQ schema-marked questions and answers --注意其中的关键写作手法讲功能要讲收益而不是规格并为 FAQ 搭配 FAQPage 结构化数据schema-marked——这与仓库中 faq.mdx 等结构化数据规则是配套使用的。策略二合并Consolidate如果某个瘦内容页面无法有意义地扩写规则给出的处置顺序是301 重定向到同一主题更全面的页面合并merge多个相关瘦页面为一篇更强的页面noindex如果页面承担功能性用途但本就不打算参与排名则对其添加noindex避免它在搜索结果中竞争。策略三删除无法扩写、也无合并价值的页面直接移除避免稀释站点整体质量信号。Google 官方语境下的四种 Thin Content 模式references/rule.md明确引用了 Google 的 spam policies垃圾内容政策其中将以下四类定义为典型的瘦内容模式供审计时对照模式说明自动生成内容Automatically generated content通过抓取或模板填充产出、无编辑价值的文本无增值的联盟页Affiliate pages with no added value仅复制厂商描述的产品列表页门页Doorway pages仅为某个关键词排名而创建、不为服务用户抓取内容Scraped content从其他站点复制且未做转化或增值规则同时强调这些模式与一篇写得很好的 150 词页面有本质区别——后者完整回答了具体问题不应被判为瘦内容。这也是为何本条规则必须结合搜索意图和有用性来判定而不能只套固定最低字数。内容深度参考表分页面类型的指导线references/rule.md给出了按页面类型划分的内容深度参考这是实践中最常被直接查阅的表格Page TypeMinimum Useful ContentTargetHomepage首页100–300 词清晰的价值主张、关键 CTAProduct page产品页200–400 词独有描述、规格、评论Category page分类页200–400 词独有导语、可筛选导航Blog post信息型博客500–1,500 词取决于查询复杂度Long-form guide长文指南1,500 词全面主题覆盖FAQ answerFAQ 回答50–200 词准确、完整的回答表格末尾的备注同样重要这些是指导线而非规则——一个 100 词的页面若能完整回答一个简单问题就不算瘦内容。这也再次印证以用户意图和竞争内容为准的核心判定逻辑。反例与正例一眼识别瘦内容写法references/rule.md提供了两组 HTML 对照是规则最有教学价值的部分❌ 瘦内容反例——只有厂商描述的产品页仅 14 词、只有商品网格而无任何正文的分类页0 词正文!-- Product page with only the manufacturer description -- h1Blue Widget Pro/h1 pThe 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 -- h1Shoes/h1 div classproduct-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-detectionYMYLYour 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.mdname、description、prompts 作为指令与references/rule.mdMDX 正文转纯 Markdownword-count 的生成物正好落在skills/word-count/与skills/word-count/SKILL.md的 frontmattercategory: 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 辅助写作普及、模板化内容泛滥的当下判断标准始终应该回到那句话页面是否提供了相对于用户搜索意图的独有价值。赞分享【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址https://gitcode.com/gh_mirrors/fr/Front-End-Checklist点击查看免费下载相关推荐Front-End-Checklist SEO 规则实战用 Word Count 规则识别与修复关键页面的薄内容Front End Checklist SEO 规则实战用 Word Count 规则识别与修复关键页面的薄内容 本文以 Front End ChecklisFront-End-Checklist 规则实战用全小写 URL 消除重复内容、合并 PageRank 的完整指南Front End Checklist 规则实战用全小写 URL 消除重复内容、合并 PageRank 的完整指南 本篇技术指南基于 Front End ChFront-End Checklist 关键词堆砌Keyword Stuffing检测与修复指南识别过度优化信号、密度阈值与内容质量治理Front End Checklist 关键词堆砌Keyword Stuffing检测与修复指南识别过度优化信号、密度阈值与内容质量治理 本指南基于开源仓上一篇终极Kedro插件开发指南从零构建自定义数据集与钩子下一篇7个实用Kedro单元测试技巧从节点逻辑验证到数据断言完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考