很多新站长一上来就 User-agent: * Disallow: / 然后又加 noindex——这是最常见的”自相矛盾”。
一句话区别
robots.txt控制”能不能抓取”——爬虫连页面都不打开<meta name="robots" content="noindex">控制”能不能收录”——爬虫读了，但不放进搜索结果
对比表
| 场景 | 用 robots.txt | 用 noindex |
|---|---|---|
| 不想让 Google 看见的私密 / 后台目录 | ✅ Disallow | ❌ |
| 文章 / 内容页”先不收录” | ❌ | ✅ |
| 重复的过滤 / 分页页 | ❌（仍想抓取分析） | ✅ |
| 站内搜索结果页 | ✅ | 也可 |
| 隔离敏感参数 URL | ✅ | 配合 nofollow |
最危险的混用
如果一个页面既被 robots.txt 禁止抓取，又有 noindex：Google 永远看不到 noindex。 结果：URL 仍可能基于外链等信号被索引（标题为空、描述为空），而你以为屏蔽了。
正确做法：要 noindex 一个页面，必须允许它被抓取。robots.txt 不要 Disallow 它。
适用场景
- 你想”先上线但不收录” → noindex
- 你想”页面对所有用户隐藏” → 需要服务端鉴权，不是 robots.txt
- 你想”减小爬虫预算消耗” → robots.txt
后续相关
决策前的检查清单
- 如果错误是在某次改动后立刻出现，先回滚或隔离那次改动，不要同时试一堆无关修复。
- 如果只在生产环境出现，对比环境变量、build 产物、缓存、权限和平台设置。
- 如果只影响某个账号或浏览器，优先查权限、cookie、插件、额度和地区可用性。
- 如果有两个修复方向，先选最容易验证、最容易撤销的那个。
什么时候可以先停下来
当你无法复现、日志和 UI 互相矛盾、涉及账单或账号安全、或者每个修复都需要你没有的生产权限时，就该停止盲试并升级处理。向平台支持或同事求助前，把完整错误、时间点、项目 ID、复现步骤、截图和最近改动整理好。清楚的升级说明，通常比再猜一小时更快解决问题。
诊断流程
- 先复现一次问题，并写下准确路径。复现不了时，先收集证据，不要急着改设置。
- 判断影响范围：一个用户还是所有用户，一个浏览器还是全部浏览器，只在本地还是只在线上，新内容还是旧内容也受影响。
- 优先查最近一次改动。大多数排查不是寻找神秘根因，而是找出哪次改动制造了不一致。
- 把系统切成两半测：输入 vs 输出、本地 vs 线上、账号 vs 项目、源文件 vs 生成文件、prompt vs 模型。确认哪一半还在失败。
- 先做最小且可撤销的修复。不要同时改 DNS、权限、账单、部署和代码。
- 用原复现路径和一个相邻路径验证，再记录最终是哪一步修好的。
最小复现模板
问题：
- [完整错误或异常表现]
发生位置：
- URL / 工具 / 项目：
- 账号：
- 环境：local / preview / production
- 浏览器 / 设备：
复现步骤：
1.
2.
3.
预期结果：
-
实际结果：
-
最近改动：
- 代码：
- 配置：
- DNS / 权限 / 账单：
- Prompt / 模型 / 上传文件：
证据：
- 截图：
- Console error：
- 服务端或平台日志：这些”假修复”别做
- 只清缓存，却不确认底层文件、权限、路由或设置是否正确。
- 明明是环境变量、凭证、额度或平台配置问题，却反复重装依赖。
- 一次改好几个无关设置，最后不知道到底是哪一步起作用。
- 从另一个框架或平台复制修复方法，却不确认路由、build 输出或鉴权模型是否相同。
- 没看 status page 和近期反馈，就把平台临时故障当成自己的 bug。