Robots.txt 与 noindex 上线前 QA 检查清单

Robots.txt 和 noindex 错误是很安静的上线风险。一行规则可以让测试站不被搜索收录，也可以保护私密 URL，但同样可能误挡本该被索引的产品页、服务页和文章页。真正麻烦的是，抓取控制规则通常分散在多个系统里。

这份清单适合 Shopify 店铺、WordPress 网站、Headless 架构和网站改版上线。只要 URL 结构、筛选、预览环境或旧页面会变化，就应该在上线前跑一遍；SEO 插件、主题、middleware、CDN 规则或 CMS 模板改变索引行为时，也要重新检查。

先列出所有会告诉搜索引擎该抓取什么、该索引什么的位置。不要只看可见的 robots.txt 文件。索引行为可能来自页面模板、SEO 插件、HTTP headers、路由处理、CDN 规则、应用扩展、密码保护和 CMS 字段。

每个控制位置都建一行记录。写清负责人、规则配置位置、影响的 URL pattern、部署方式，以及团队如何回滚。如果一个规则没有负责人，就把它当成上线风险。

• Robots.txt 规则：disallow、allow、sitemap 引用、平台默认规则和自定义覆盖。
• 页面级规则：meta robots noindex、nofollow、max-snippet、max-image-preview 和模板默认值。
• Header 规则：PDF、图片、Feed、API route、预览 route 和生成文件上的 X-Robots-Tag。
• 路由规则：redirect、rewrite、canonical URL、hreflang、sitemap 条目和状态码。
• 平台设置：Shopify 主题文件和应用输出、WordPress 阅读设置和 SEO 插件、Headless middleware，以及 CDN edge 逻辑。

改规则前，先按意图给 URL 分组。一次改版通常会有应该被索引的产品页或服务页、能访问但不该排名的工具页、应该 canonical 的重复状态，以及应该重定向或返回明确状态码的旧 URL。

有用的产出是一张简单决策表。每组 URL 都应该只有一个主规则：index、noindex、disallow、redirect、canonicalize、404 或 410。如果一组 URL 需要两个规则，要写清哪个规则优先，以及怎么测试。

• Index：首页、服务页、产品页、集合页、文章、案例页，以及有搜索价值的市场落地页。
• Noindex：账户页、购物车状态、站内搜索结果、薄内容筛选页、活动预览页和重复工具页。
• Disallow：私密后台路径、仅测试环境使用的资源、内部脚本，以及不应该被搜索机器人请求的抓取陷阱。
• Redirect：移动页面、合并内容、改名 handle、有替代页的旧活动 URL 和历史 CMS 路由。
• 404 或 410：没有有用替代页面的删除内容、过期一次性页面，以及应该彻底消失的测试 URL。

大多数抓取控制问题来自没人记得的默认设置。Shopify、WordPress 和 Headless 栈都有不同位置可能输出 robots 或 noindex。先检查默认行为，再只在默认规则不够时添加自定义规则。

每个平台至少测试一个正式页面、一个草稿或预览页面、一个搜索或筛选页面、一个媒体或文件 URL，以及一个旧 URL。这个样本通常能看出规则到底来自平台、主题、插件、middleware 还是托管层。

• Shopify：检查 robots.txt.liquid、集合筛选 URL、搜索 URL、产品 handle、应用注入标签和市场专属路径。
• WordPress：检查 Reading 设置、SEO 插件索引规则、自定义文章类型归档、媒体附件页、作者归档、标签归档和测试站插件。
• Headless：检查 robots route、sitemap 生成、metadata 组件、middleware、preview mode、cache headers 和 CDN edge functions。
• 多语言网站：确认本地化 route、hreflang 目标、canonical 目标和市场专属 sitemap 没有被宽泛规则误挡。

Robots.txt、noindex 和 canonical 不是同一种工具。一个被 robots.txt disallow 的页面可能无法被抓取，所以搜索引擎可能看不到它的 noindex。一个 noindex 页面如果还在 sitemap 里，会发出冲突信号。canonical 目标如果重定向或 noindex，也会破坏信号归并路径。

上线前做一张小型交互矩阵。每个高风险 URL pattern 都记录 robots.txt 结果、状态码、meta robots、X-Robots-Tag header、canonical 目标、sitemap 是否包含，以及预期搜索表现。

• 不要因为页面应该 noindex 就直接 disallow；搜索引擎需要访问页面，才能看到 noindex 指令。
• 除非迁移期间有明确临时原因，否则把 noindex URL 从 XML sitemap 中移除。
• Canonical 目标应该返回 200、允许索引，并出现在正确的本地化或 canonical sitemap 中。
• 重定向表上线后，把已重定向 URL 从 sitemap 和内部链接中移除。
• 筛选 URL 和参数 URL 要把 canonical、noindex 和 robots 规则放在一起检查，不要拆成三次评审。

在 staging 和 production 使用同一组 QA 样本，差异才容易发现。每个重要分组选 10 到 20 个优先 URL：首页、服务或产品页、分类页、博客文章、站内搜索、筛选 URL、本地化路径、媒体文件、旧重定向 URL，以及一个故意删除的 URL。

样本里要有干净 URL，也要有麻烦 URL。加入一个带参数的 URL、一个旧站曾经出现过的大写 URL、一个 trailing-slash 变体、一个分页或筛选 URL、一个预览 URL，以及一个来自 Analytics 或 Search Console 的历史 URL。

• 逐个比较 robots.txt、状态码、meta robots、canonical、sitemap 是否包含、hreflang 和渲染标题。
• 单独检查 staging 保护，确保测试环境不会被索引，但这条阻挡规则没有复制到 production。
• 确认 production 没有带着发布冻结、预览插件或环境变量留下的临时 noindex。
• 测试 redirect map 里的旧 URL，不要只点新导航链接。

不要只相信 CMS 预览或页面源码。JavaScript、Server Components、插件、middleware 和 CDN 规则，都可能改变爬虫最终收到的内容。优先模板要同时测试最终 HTTP 响应和渲染后的 DOM。

对于文件和非 HTML route，要直接检查 headers。PDF、图片、Feed、JSON endpoint 和生成的 XML 文件，可能带有页面源码里永远看不到的 X-Robots-Tag。改版如果发布受限文件、下载资料、商品 Feed 或历史资源，这一点尤其重要。

• 确认 HTML source 和 rendered DOM 都包含预期的 robots 与 canonical 值。
• 检查 PDF、图片、Feed、API response、XML 文件和预览 route 上的 X-Robots-Tag header。
• 确认状态码符合预期：正式可索引页面是 200，永久重定向是 301 或 308，删除页面是 404 或 410。
• CDN cache 清理后再测一次，因为旧 robots.txt、sitemap 或 header 响应可能比部署存活更久。

抓取控制变化应该像一次发布，而不是一次设置调整。上线前保存当前 robots.txt、sitemap 输出、关键模板 metadata、SEO 插件规则、middleware 规则和 CDN 规则。然后明确谁可以确认最终 production 抓取行为。

回滚不一定意味着回退整个网站。有时最安全的修复是恢复 robots.txt、移除某个 noindex 字段、禁用一条 CDN header 规则、重新生成 sitemap，或回退单个 metadata 组件。

• 上线前：导出 robots.txt、sitemap URL、索引规则设置、metadata 模板、redirect 规则和优先 URL QA 结果。
• 上线中：发布规则、清理 cache、重新生成 sitemap、爬取优先样本，并手动测试 20 个高价值 URL。
• 回滚触发：首页 noindex、核心模板被阻挡、staging 被索引、sitemap 缺少正式 URL，或重要页面出现 redirect chain。
• 回滚后：记录失败规则、负责人、受影响 URL、修复方式和预防步骤，再进入下一次发布。

前 24 到 48 小时先看明显错误：robots.txt 是否可访问、sitemap 是否能抓取、首页和优先模板是否可索引、redirect 状态是否正确，以及 staging 是否意外暴露。之后继续看 Search Console 覆盖率、抓取统计、已索引页面、404、excluded by noindex 报告，以及可用的服务器日志。

监控窗口至少保留 14 天。搜索引擎不会立刻重新访问所有 URL，延迟的 cache、sitemap 或 redirect 问题，可能要等第一轮抓取后才出现。每个问题都记录 URL、规则来源、预期行为、实际行为、负责人和预防说明。