Front-End-Checklist 的 all-noindex-pages 技能系统化审计全站 noindex 指令的完整方法【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist本文基于 all-noindex-pages 技能定义 及其 参考规则文档讲解如何审计一个站点中所有noindex指令的分布与合理性识别哪些页面使用了 meta 标签或 HTTP 头携带noindex验证关键页面商品、文章没有被意外屏蔽并确认noindex确实只施加在薄内容、后台和工具类页面上。读完本文你能掌握一套可落地的 noindex 审计流程、noindex与 robots.txtdisallow的本质区别以及结合渲染后 HTML 与响应头进行验证的实操手段。技能定位一条 medium 优先级的 SEO 技术规则在 Front-End-Checklist 仓库中all-noindex-pages以「技能Skill」的形式组织供人类审计者和 AI Agent 共同使用。其 SKILL.md 的 frontmatter 声明了它的关键属性category:seoSEO 类别priority:medium中等优先级difficulty:intermediate中等难度estimatedTime:10预计耗时 10 分钟source:frontendchecklist.io规则页面为 frontendchecklist.io 上的en/rules/seo/all-noindex-pages它的核心判断依据来自 规则内容定义文件一个错误的noindex标签可以把重要页面彻底移出搜索结果而正确使用它则有助于管理抓取预算crawl budget并避免重复内容问题。也就是说这条规则不是要求「全站不得出现 noindex」而是要求「每一个 noindex 都必须是有意为之」。快速参考清单审计 noindex 的三件事SKILL.md 给出的 Quick Reference 是整套审计动作的浓缩也是本条规则的操作骨架找出所有使用noindex指令的页面——包括 meta 标签和 HTTP 头如X-Robots-Tag两种载体验证关键页面没有被意外屏蔽——商品页、文章页等高价值页面不应出现在 noindex 清单里确认noindex正确施加在应该屏蔽的页面上——薄内容thin content、后台管理、工具类页面。对应的 Check 提示词是Verify that thenoindexdirective is only applied to pages that should not appear in search results.验证noindex指令只施加在不应出现在搜索结果中的页面上。Fix 提示词则是从应该被索引和排名的页面上移除meta namerobots contentnoindex。正确的 noindex 代码模式references/rule.md 与 规则定义文件 给出的标准代码示例区分了两种常见场景head !-- 用于「感谢页」或站内搜索结果这类工具页面 -- meta namerobots contentnoindex, follow !-- 用于希望被彻底忽略的页面 -- meta namerobots contentnoindex, nofollow /head两者的语义差别在于follow与nofollownoindex, follow页面本身不进索引但允许爬虫沿页面上的链接继续向外抓取链接权重link equity可以正常传递。适合「感谢页」「内部搜索结果」等不希望被收录、但仍希望站点链接结构被发现的页面noindex, nofollow页面不索引且不允许沿其链接继续抓取适合需要被彻底隔离的页面。需要注意的是noindex, follow组合虽然在本条规则中被明确推荐为工具页的标准写法但在代码审查时仍值得逐处确认它是有意配置——Front-End-Checklist 的 MCP 包中就有针对该模式的启发式检测review-code.ts 会用正则匹配meta namerobots content...标签一旦发现同一标签中同时出现noindex和follow就会提示「verify this is intentional; noindex prevents indexing while follow allows link crawling」。这段逻辑虽然挂在robots-meta-conflict/schema-noindex-conflict规则下运行但体现的正是本条规则「每个 noindex 都值得逐页确认意图」的审计思想。为什么 noindex 审计很重要references/rule.md 的「Why It Matters」一节从四个维度说明了价值可见性Visibility防止高价值页面被 Google 和 Bing 意外排除抓取预算Crawl Budget帮助搜索引擎把有限的抓取资源集中到最重要的页面上反索引De-indexing可以不用删除页面就把过时或敏感页面从搜索结果中移除策略性控制Strategic Control允许你管理哪些内容版本例如带筛选条件的列表页可以被索引。深入辨析noindex 与 robots.txt 的 disallow 不是一回事SKILL.md 的 Explain 环节明确要求解释 robots.txt 中noindex与disallow的区别以及何时该用哪一个。这一点在仓库的关联规则 robots-meta-conflict.mdx 中有完整的展开也是 noindex 审计中最容易踩的坑。核心机制是如果某个 URL 被 robots.txt 的Disallow规则屏蔽爬虫根本不会抓取该页面因此永远不会读到页面里的noindexmeta 标签。于是出现一个反直觉的悖论——你以为「屏蔽 noindex」是双重保险实际上 Google 可能仅凭外部反链的锚文本就把这个 URL 展示在搜索结果里。该规则文档给出的速查表清晰地列出了各场景下两种信号的正确组合目标robots.txtmeta robots允许抓取与索引无 Disallowindex, follow默认反索引页面、保留链接权重无 Disallownoindex, follow阻止抓取不保证反索引Disallow: /path/无意义——不会被读取屏蔽私密工具内容Disallow: /path/不需要落到实操上要反索引一个页面确保 robots.txt 中没有该路径的 Disallow 规则保留meta namerobots contentnoindex, follow。Googlebot 会抓取页面、读到 noindex再将其移出搜索结果要彻底隔离一个环境如 staging在 staging 域名的 robots.txt 中Disallow: /即可此时页面内的 noindex 标签无关紧要典型的错误组合robots.txt 写了Disallow: /old-page/页面里又放了meta namerobots contentnoindex——这个 noindex 永远不会被处理页面反而可能因为反链信号被索引。代码审查Code Review要点SKILL.md 的 Code Review 环节给出了明确的审查范围审查与「审计所有 noindex 页面」相关的元数据生成逻辑、渲染后 HTML、结构化数据和响应头。指出搜索结果输出违反规则的精确路由或模板并说明如何验证最终页面输出。这提示审计不能停留在源码层面——由于noindex可能在构建管线、中间件或边缘函数中动态注入SKILL.md 的 AI 上下文也强调Verify the rendered HTML and HTTP response rather than relying only on source files.要验证渲染后的 HTML 与 HTTP 响应而不是只看源文件。具体审查时可以按以下顺序排查元数据生成层检查 Next.js 的metadata/robots配置、模板中的 meta 标签确认哪些路由会输出noindex响应头层抓取实际响应检查X-Robots-Tag头是否携带noindex交叉比对把 noindex 清单与 sitemap 对照——noindex-in-sitemap 规则 指出把已 noindex 的 URL 写进 XML sitemap 会向爬虫发送矛盾信号浪费抓取预算sitemap 应只列出规范 URL、可索引、200 状态的地址冲突信号检查 canonical、重定向与 robots 指令之间是否存在矛盾这属于 indexability-conflicts 规则 的关注范围。例外情况这些 noindex 可能是合理的references/rule.md 与 all-noindex-pages.mdx 的 Exceptions 一节明确列出三类不应简单判定为问题的例外Staging、工具页、登录页、账户页或站内搜索页如果本就不打算参与排名可以有意识地使用不同的抓取或索引信号临时迁移状态可能产生嘈杂的中间信号——审计时应标记生产环境中的 URL 模式而不是一次性的过渡性产物当重定向、canonical、robots 指令或可索引性信号相互冲突时应优先修复最强的最终信号而不是把每个下游症状都当成独立的阻断项报告出来。第三条尤其重要noindex 问题经常是更上游配置错误的「症状」审计的产出应该指向根因信号。验证流程自动化检查与人工检查规则的 Verification 一节把验证手段分为两类这也是审计完成后应执行的收尾动作自动化检查Automated Checks检查渲染后的 HTML 和 HTTP 头确认预期的元数据或可抓取性信号确实存在在适用时用 Google Search Console 或等效工具测试受影响的 URL部署后重新爬取一组代表性页面确认变更生效。人工检查Manual Checks确认这次变更没有制造出新的canonical URL、robots 指令或结构化数据之间的冲突信号。标准依据与相关规则按照 all-noindex-pages.mdx 的 frontmatter本规则在判定为「满足」之前应以 Google Search Central 的 Search Essentials 指南与 Google Search Central 文档为标准来核对最终面向搜索的 HTML、元数据与抓取行为实际验证中推荐借助 Google Search Console 这类工具。在仓库的规则体系中all-noindex-pages与以下规则同属seo/technical领域、常被一起审查见 all-noindex-pages.mdx 的 relatedRulesindexability-conflicts——可索引性信号冲突的总排查规则robots-meta-conflict——robots.txt Disallow 与 noindex meta 并存、导致 noindex 永远不被读取的悖论indexability——页面可索引性的基础规则schema-noindex-conflict——结构化数据与 noindex 信号之间的矛盾。小结all-noindex-pages技能的价值不在于发现「有没有 noindex」而在于建立一张全站 noindex 清单并逐页回答「这个 noindex 是不是有意为之」。正确的姿势是工具页、感谢页使用noindex, follow让链接继续传递需要反索引的页面保持可抓取、只靠 meta 标签或响应头发出 noindexstaging 环境则直接在 robots.txt 层面整体屏蔽。审计时始终记住两点验证对象是渲染后的 HTML 与 HTTP 响应而非源码以及冲突信号出现时先修根因再谈症状。【免费下载链接】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），仅供参考