为每个页面编写 meta descriptionFront-End-Checklist 的 SEO 元描述审计与 Next.js 实战指南【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklistmeta description元描述是搜索结果中标题下方的那段短摘要也是你免费的广告文案。本指南以 Front-End-Checklist 仓库中的 meta-description 技能 及其完整规则文档为核心结合仓库内的规则内容packages/content/rules/en/seo/meta-description.mdx与 Next.js 站点源码apps/web/app/(site)/rules/[category]/[slug]/page.tsx系统讲解元描述的存在性、唯一性与长度校验从 120–160 字符的最佳实践到 Next.jsgenerateMetadata的动态生成再到如何用自动化与人工手段验证落地效果帮助你建立可复用的 SEO 元数据审计与编写流程。规则定位它检查什么在 Front-End-Checklist 的规则体系中meta-description属于seo分类、meta-tags子分类优先级为high难度beginner预估耗时10 分钟。它的作用对象是每一页应当获得自然搜索流量的页面——既用于审计已有页面的元数据也用于为新页面生成描述见 SKILL.md 的 frontmatter 定义。规则的核心检查动作Check非常简单却覆盖三个独立维度存在性head中是否存在meta namedescription标签唯一性该描述是否与其他页面重复长度字符数是否落在 120–160 的推荐区间。任何缺失、重复或长度越界的页面都会被标记。与之配套的 Code Review 清单更进一步要求逐条验证五点元素存在content属性非空长度在 70–160 字符之间审核口径比编写口径更宽松content内部不含 HTML 标签描述唯一不与其它页面相同。从源码结构看这一技能文件同时服务于两个用途一是供人工审计时按 Check / Fix / Explain / Code Review 四段式快速执行二是被仓库中 packages/mcp/src/tools/check-rule.ts 等 MCP 工具消费——技能文档中prompts字段check/fix/explain/codeReview直接对应 Agent 调用时的指令模板使得 LLM 可以按同样的口径审计任意目标页面。为什么值得写它不是排名信号却是你的广告文案规则文档反复强调一个容易被误解的事实meta description 不是直接的排名信号但它直接决定用户在搜索结果中是否点击你的页面。一段精心撰写的描述能提升点击率CTR而点击行为的改善会间接作用于排名表现。可以用一个比喻来理解标题title负责吸引注意描述description负责促成点击。两者共同构成完整的 SERP 展示单元这也是该规则在 meta-description.mdx 中与meta-title、duplicate-description、nosnippet、h1互相关联的原因duplicate-description跨页面重复描述会削弱 SERP 差异化Google 可能干脆弃用你的描述、自动抓取页面文本生成摘要meta-title标题与描述共同构成完整的搜索展示nosnippet该指令会阻止 Google 展示任何描述属于一刀切的取舍h1两者同属seo/meta-tags区域通常一起评审。此外还有一条重要的现实约束Google 可能覆盖override你写的描述。当页面描述与用户查询不匹配、描述缺失或重复时搜索引擎会从页面内容中自行截取摘要。因此写好描述的完整定义是写出让 Google 没有理由替换你的描述。长度指南120–160 字符是最优区间参考文档给出了明确的长度对照表见 references/rule.md长度结果 70 字符太短——浪费展示机会120–160 字符桌面端 SERP 的理想区间 160 字符被截断末尾显示 …需要说明的是Google 实际上以像素而非字符数来衡量摘要宽度桌面端最大约 920px因此精确的字符上限会随字体、设备和搜索环境浮动。120–160 是一个经验安全区它既给了你足够空间写清价值主张又大概率不会在桌面端被截断。编写方法论四步写出有效描述参考文档给出四条核心写作原则叠加 duplicate-description.mdx 的补充可以归纳为以下可执行清单回答用户意图这个页面解决什么问题描述要回应搜索者当下的疑问自然融入 CTA使用 Learn how to…、Discover…、Shop our… 等动词开头把描述写成行动号召避免关键词堆砌为真实用户而写而不是为机器人拼凑关键词与页面内容匹配描述不匹配页面时Google 会用页面正文替换它逐页唯一每个 URL 的描述都应概括该页面的具体内容而不是复用站点标语或首页描述这是 duplicate-description 规则的检查重点见 packages/content/rules/en/seo/duplicate-description.mdx。正反示例正面示例——唯一、约 145 字符、清晰传达价值!-- ✅ Good: Unique, 145 characters, describes value clearly -- head meta namedescription contentLearn to bake sourdough bread at home with our step-by-step guide. Covers starter, shaping, scoring, and baking in a Dutch oven. / /head反面示例——缺失或全局复用!-- ❌ Bad: Missing description -- head titleSourdough Bread Recipe | BakeCo/title !-- no meta description -- /head !-- ❌ Bad: Identical description on every page -- head meta namedescription contentBakeCo – the best baking website. / /head反面示例——属性缺失或塞入 HTML 标签!-- ❌ Bad: Content attribute missing -- meta namedescription / !-- ❌ Bad: HTML tags inside description -- meta namedescription contentbBest/b sourdough recipes / !-- ✅ Good: Plain text, clear value -- meta namedescription contentMaster sourdough at home. Our guide walks you through every stage, from building a starter to your first perfect loaf. /content属性中禁止 HTML 标签的原因很实际搜索引擎按纯文本解析摘要标签不仅不会生效还可能破坏整段描述的渲染。动态生成的实践对模板驱动的站点最稳妥的写法是逐路由动态生成描述而不是手写每个页面。参考文档给出的 Next.js 示例展示了两种互补用法// app/blog/[slug]/page.tsx export async function generateMetadata({ params }): PromiseMetadata { const post await getPost(params.slug) return { description: post.excerpt.slice(0, 155), } }// app/layout.tsx — site-wide fallback export const metadata: Metadata { description: BakeCo – Step-by-step artisan bread recipes for home bakers., }这两种方式的定位不同layout.tsx中的metadata提供站点级兜底没有更具体描述时的默认值generateMetadata则按路由提供页面级覆盖。优先级关系是页面级覆盖布局级因此两者配合既能保证每页都有描述又能实现每页描述都唯一。Front-End-Checklist 站点自身的落地实现仓库的 Web 应用apps/web就是一个活生生的 Next.js 元数据实践样本。以规则详情页为例apps/web/app/(site)/rules/[category]/[slug]/page.tsxexport async function generateMetadata({ params }: PageProps): PromiseMetadata { const { slug } await params const lang SITE_LANGUAGE const rule allRules.find(item item.slug slug item.language lang) if (!rule) { return { title: Rule Not Found } } return generateRuleMetadata({ title: rule.title, description: rule.description || Best practices for ${rule.title} in frontend development., slug: rule.slug, primaryCategory: rule.primaryCategory, priority: rule.priority, difficulty: rule.difficulty }) }这段代码体现了三条值得借鉴的设计数据驱动描述直接取自内容集合中每条规则的 frontmatterrule.description规则撰写者在 meta-description.mdx 的 YAML 头中维护描述页面层无需二次编辑兜底策略当某条规则缺少描述字段时用模板字符串Best practices for ${rule.title} in frontend development.兜底保证每个 URL 都有描述输出集中封装具体元数据的拼接含 canonical、OG 标签等集中在 apps/web/lib/seo-metadata.ts 的generateRuleMetadata/generateChecklistMetadata/generateGuideMetadata等函数中并在 apps/web/lib/seo.tsx 统一导出站点所有页面共用一套元数据生成逻辑。同样的模式也出现在清单详情页apps/web/app/(site)/checklists/[slug]/page.tsxgenerateMetadata从allChecklists中取当前清单的description交给generateChecklistMetadata同时通过JsonLd输出结构化数据。整个站点在apps/web/app/layout.tsx中设置baseMetadata作为站点级默认值形成根布局兜底 各路由覆盖的完整层级——这与参考文档给出的layout.tsxpage.tsx两层模式完全一致。边界与例外什么情况下可以放过规则文档references/rule.md明确列出了三类豁免场景审计时避免误报工具类页面或主动 noindex 的页面当丰富的搜索展示本身不是目标时可以保留极简元数据模板驱动的页面单看源码可能显得重复但在下结论前应确认渲染后的生产输出确实重复而不是模板变量在编译期被填充成了唯一值有意重定向或排除索引的页面先解决爬取决策是否可索引再谈元数据打磨否则优先级是倒置的。验证与回归如何确认规则落地参考文档提供了自动化与人工两层验证手段自动化检查查看页面源代码搜索namedescription用 Google Search Console 的 Enhancements增强功能报告排查缺失或重复的描述用 Google 的 Rich Results Test 验证元数据可被正常读取站点级审计可用爬虫工具抓取全站收集所有meta namedescription content...值按内容分组任何一组包含多个 URL 即为违规见 duplicate-description.mdx。人工检查用 SERP 模拟器预览确认描述不会被截断、首屏文案是否吸引人。审计后回归重新抓取代表性页面确认部署后缺失/重复问题已解决同时确认改动没有与 canonical、robots、结构化数据产生冲突信号见 duplicate-description.mdx。与相邻规则的联动meta description 不是孤立标签审计时通常与以下规则一起评审详见 meta-description.mdx相邻规则联动原因duplicate-description跨页重复描述削弱 SERP 差异化需要逐页唯一化meta-title标题 描述共同构成完整 SERP 展示单元nosnippetnosnippet指令会彻底阻止 Google 展示描述h1同属seo/meta-tags区域常一起评审一条实用的审计顺序是先确认页面可被索引robots、canonical、重定向再检查标题唯一性最后打磨描述——避免在注定不被收录的页面上浪费时间优化摘要。快速上手10 分钟完成一次元描述审计结合技能文件的结构SKILL.md一次完整的审计可以这样执行Check打开页面head确认meta namedescription存在且唯一字符数在 120–160 之间对每个缺失、重复或长度异常的目标页面做标记Fix在head中添加或更新meta namedescription content...写一段准确概括页面内容、包含自然行动号召或价值主张的 120–160 字符唯一摘要Next.js/React 场景下通过 SEO 组件的动态descriptionprop 注入而不是写死字符串Explain向利益相关者说明——描述出现在搜索结果标题下方的短段落中虽非排名因素但有效的描述提升点击率进而间接有利于排名Code Review按五点清单存在、非空、70–160 字符、无 HTML 标签、唯一在代码评审环节把关。至此你已经掌握了从规则理解、编写方法、框架落地到验证回归的完整闭环。无论是人工审计还是借助仓库中的 MCP 工具让 Agent 代劳这套流程都能确保每一页以最佳形态出现在搜索结果中。【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考