Front-End-Checklist 实战指南：检测并修复 robots.txt、noindex 与 canonical 之间的索引信号冲突

Front-End-Checklist 实战指南：检测并修复 robots.txt、noindex 与 canonical 之间的索引信号冲突

【免费下载链接】Front-End-Checklist🗂 The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist

本指南以仓库 skills/indexability-conflicts/references/rule.md 为骨架，结合 packages/crawler 的源码实现与 packages/content/rules/en/seo 下同主题规则，系统讲解「索引信号冲突（indexability conflicts）」的成因、危害、审计方法与修复方案。读完你可以在自己的站点上独立完成 robots.txt、meta robots、X-Robots-Tag头与 canonical 标签的一致性审计，并借助本仓库的规则体系（如 indexability-conflicts.mdx）将检查固化为可复用的自动化流程。

一、背景：四个信号各司其职，冲突必然制造歧义

索引（indexability）信号并不只有一种。在一个现代网站上，至少存在四类信号各自控制抓取与收录流程的不同环节：

Google 的 robots-meta 官方文档（检查重要页面是否被意外屏蔽）形成递进关系——先确认页面是否可被收录，再排查多个信号之间是否彼此矛盾。

二、常见冲突类型速查表

原文档给出的四类典型冲突及其后果，是审计时的第一张对照表：

三、代码示例：错误与正确写法对照

3.1 ❌ 错误：robots.txt 屏蔽了一个带 noindex 的页面

# robots.txt User-agent: * Disallow: /private/ # 屏蔽抓取

<!-- /private/page.html —— 因为被 robots.txt 屏蔽，永远不会被读取 --> <meta name="robots" content="noindex">

这是最危险的组合：爬虫被Disallow挡在门外，永远读不到页面里的noindex标签。结果就是 Google 通过 sitemap 或外链知道这个 URL 存在，却既无法确认也无法否认它应当被排除，页面陷入「抓取歧义」的悬空状态。

3.2 ✅ 正确：只使用 noindex（移除 robots.txt 屏蔽）

# robots.txt —— 不再对 /private/ 使用 Disallow User-agent: * Disallow: /admin/ # 只屏蔽真正不允许被抓取的路径

<!-- /private/page.html —— 爬虫可以读取 noindex 指令 --> <meta name="robots" content="noindex, follow">

3.3 ❌ 错误：canonical 指向一个 noindex 页面

<!-- /product?color=red —— 声明 canonical 的页面 --> <link rel="canonical" href="/product"> <!-- /product —— canonical 指向的目标页面居然是 noindex！ --> <meta name="robots" content="noindex">

这等于同时告诉 Google「这是首选 URL」和「不要收录它」，是一句自相矛盾的话。

3.4 ✅ 正确：canonical 指向可收录的页面

<!-- /product?color=red --> <link rel="canonical" href="/product"> <!-- /product —— 可收录，无 noindex --> <!-- （meta robots 缺失，或显式设置为 "index, follow"） -->

3.5 ✅ 排除页面的统一信号方案

对于确实要从搜索结果中排除的页面，选择一种信号即可：

<!-- 选项 A：只用 noindex（推荐——让 Google 能读取标签） --> <meta name="robots" content="noindex, follow"> <!-- 选项 B：只用 robots.txt 屏蔽（页面必须完全不被抓取时使用） --> <!-- 适用于敏感数据或抓取成本极高的页面 -->

四、为什么这很重要

• 屏蔽 + noindex = 无法解决的死局：robots.txt 屏蔽 URL 后，页面上的noindex永远不会被读取。Google 知道 URL 存在，但既不能确认也不能否认它应被排除。
• canonical 指向 noindex：告诉 Google「这是首选 URL」的同时又说「别收录它」，语义自相矛盾，canonical 可能被直接忽略。
• 浪费抓取预算（crawl budget）：互相矛盾的信号会让 Google 反复重新抓取页面以尝试消除歧义。这也是为什么在检查页面级指令（meta/header）时必须同时对照 robots.txt 规范 的原因。

五、如何审计：从 robots.txt 到 Search Console 的四步流程

原文档给出了一套可直接照做的审计流程：

1. 解析 robots.txt：提取所有Disallow模式（注意区分User-agent分组与通配符语义）。
2. 抓取全站并匹配：对每个 URL，判断其路径是否命中某条Disallow规则。
3. 模拟命中页面的可读性：对命中的 URL 尝试抓取（模拟屏蔽发生前的状态），检查 HTML 中的noindex与响应头中的X-Robots-Tag。
4. 用 Search Console 交叉验证：在 Coverage（覆盖率）报告中找出同时处于「被 robots.txt 屏蔽」和「收到 noindex 信号」的 URL。

补充一个可落地的细节：审计脚本中的第 2 步「判断 URL 是否命中 Disallow 规则」本质是 robots 协议的路径匹配（前缀匹配、$结尾符、*通配符），在实现时建议直接复用成熟的 robots 解析库，避免自己实现时漏掉协议边界情况。

六、修复指南：按信号意图归一的决策树

结合 SKILL.md 的 Fix 流程 与 indexability-conflicts.mdx 的 prompts.fix 字段，修复策略完全取决于你的产品意图：

场景一：页面同时被 robots.txt 屏蔽且带noindex

• 若你想让页面从索引中排除：移除 robots.txt 规则，保留noindex，让爬虫能读到标签；
• 若你想彻底阻止抓取：移除noindex（反正不会被读取），保留 robots.txt 屏蔽。

场景二：canonical 指向 noindex 页面

• canonical 的目标必须是可收录的页面；
• 将 canonical 改为指向可收录 URL，或移除目标页的noindex。

场景三：meta robots 中同时出现index与noindex（来自不同标签或来源）

• Google 遵循最严格的指令，noindex生效；
• 收敛为单一明确的意图表达。

场景四：meta 与 HTTP 响应头信号互相矛盾

• 例如 meta 是noindex而X-Robots-Tag是index，按最严格者处理；
• 修正服务端配置（Nginx、Apache、CDN 规则或vercel.json的 headers），与页面级标签保持一致。

修复后验证：对每个受影响的页面，使用 Google Search Console 的 URL Inspection（网址检查）工具逐一确认最终收录状态。

七、例外情况：不是所有冲突都必须修复

原文档明确指出以下场景属于合理例外，审计时应区分「设计如此」与「真实缺陷」：

• 有意使用不同信号：Staging 环境、工具页、登录页、账户页、站内搜索页等本就不参与排名的页面，可能有意使用不同的抓取/收录信号。例如仓库 robots-meta-conflict 规则 就认可Disallow: /用于完全屏蔽 staging 环境的做法。
• 迁移过渡期的噪音：临时迁移状态会产生阶段性的杂散信号，应标记线上生产环境的 URL 模式，而非一次性过渡产物。
• 修复优先级：当重定向、canonical、robots 指令或收录信号互相冲突时，优先修复最强的最终信号，而不是把每个下游症状都当作独立 blocker 上报。

八、验收标准与验证手段

标准依据（以 Google Search Central 文档为准绳）：

• 对照Robots meta tag, contenteditable="false">【免费下载链接】Front-End-Checklist🗂 The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist