网址已被 robots.txt 屏蔽：何时合理，何时让您付出代价

“网址已被 robots.txt 屏蔽”表示由于您的 robots.txt 文件中有一条规则禁止抓取，Google 没有抓取该 URL，而且该 URL 不在索引中。在大多数网站上，这一状态是正确的：后台管理区、购物车、站内搜索和带参数的 URL 都是有意屏蔽的。只有当规则误伤了您希望出现在搜索中的网页时，它才会让您付出代价，而您要做的，就是从有意屏蔽的网页中把这些网页找出来。

2022 年之前，Search Console 的 "Index Coverage" 报告用 2 个标签表示这一状态：对于您提交的 sitemap 中列出的 URL，使用 "Submitted URL blocked by robots.txt"；其余的则使用 "Blocked by robots.txt"。在德语中，Google 的帮助文档目前将这一状态列为 "URL wird von der robots.txt-Datei blockiert"，旧标签为 "Durch robots.txt-Datei blockiert"。如果您的报告显示的是“已编入索引，尽管遭到 robots.txt 屏蔽”，说明该 URL 虽被屏蔽却仍在索引中，这一状态另有专门的指南。

Google 对这一状态的解释

Google 的“网页索引编制”报告文档（2026 年 10 月核对）把“网址已被 robots.txt 屏蔽”列在“未编入索引”下，并说明该网页被您网站的 robots.txt 文件屏蔽了。同一文档在介绍整个“未编入索引”组时还指出，这些网页未编入索引，“但不一定是因为出现了错误”。

这种屏蔽对您的决策有 2 个影响：

• 屏蔽阻止的是抓取，而不是编入索引。 Google 的文档补充说，屏蔽并不能保证该网页不进入索引。如果 Google 在不加载网页的情况下获得了有关它的信息（例如来自其他网页的链接），它仍有很小的可能被编入索引，并转入“已编入索引，尽管遭到 robots.txt 屏蔽”。
• Google 永远看不到该网页。 看不到标题、内容、网页上的链接、canonical 或 noindex。只要规则还在，网页对自己的任何说明都是不可见的。

这是问题吗？把有意屏蔽与意外屏蔽区分开

先使用“网页索引编制”报告顶部的筛选器，把它从“所有已知网页”切换为“所有已提交的网页”。在“所有已提交的网页”下出现的被屏蔽 URL，都列在您提交的 sitemap 中：您一边请求 Google 将它们编入索引，一边又用 robots.txt 禁止抓取。无论这条规则的本意是什么，这种矛盾几乎总是一个错误。

在提交给 SEOReport 审计、且我们于 2026 年 5 月至 10 月间抓取了其 sitemap 页面的 29 个外部网站中，有 2 个（7%）在 sitemap 中列出了被其自身 robots.txt 禁止抓取的 URL。这并不是最常见的 sitemap 问题，但它屏蔽的恰恰是网站已经声明为重要的网页。

意外屏蔽的常见模式，附修改前后对比

下面每种模式中的规则都按字面意思生效了，结果屏蔽的范围却超出了预期。

1. 随版本一起上线的预发布环境文件。 开发环境的网站被完全屏蔽，而这个文件随其余构建产物一起进入了正式环境。

# Before: copied from staging
User-agent: *
Disallow: /

# After: block only what should never be crawled
User-agent: *
Disallow: /cart/
Disallow: /account/

Sitemap: https://www.example.com/sitemap.xml

2. 前缀过短。 Google 从 URL 路径的开头开始匹配规则，因此 Disallow: /search 会屏蔽 /search?q=shoes，同时也会屏蔽 /search-engine-basics/ 这篇真实的文章。

# Before
Disallow: /search

# After: block only the search results
Disallow: /search/
Disallow: /search?

3. 误伤着陆页的通配符。 * 匹配任意字符序列，而且 Google 的匹配范围包括查询字符串。Disallow: /*? 会屏蔽所有带参数的 URL，包括 /shoes/?page=2 这样的分页分类页，而您可能希望这些网页被抓取，好让其中的产品被发现。

# Before
Disallow: /*?

# After: keep pagination crawlable, block the rest
Disallow: /*?
Allow: /*?page=

文件扩展名也有同样的陷阱。如果网站的网页都以 .php 结尾，Disallow: /*.php 就会屏蔽整个产品目录。

4. 被遗忘的 Googlebot 分组。 Google 的 robots.txt 规范指出，爬虫只遵守点名它的最具体的分组，而且具体分组与 * 分组不会合并。一个多年前为网站迁移而写的 User-agent: Googlebot 分组，会一直对 Googlebot 生效；团队却只修改 * 分组，怎么也解释不了为什么会被屏蔽。

# Before: Googlebot reads only its own group
User-agent: Googlebot
Disallow: /blog/

User-agent: *
Disallow: /cart/

解决办法是删除旧分组，或者把当前规则复制进去。同一条规则也解释了 AI 爬虫策略常见的一个副作用：为特定爬虫添加具名分组的网站，必须在每个具名分组中重复所有通用规则。我们的 robots.txt 与 AI 爬虫决策表提供了让搜索规则与 AI 规则互不干扰的模板。

5. 被屏蔽的渲染资源。 Disallow: /assets/ 或 Disallow: /static/ 会屏蔽您的网页所加载的 CSS 和 JavaScript。Google 的 robots.txt 简介指出，您可以屏蔽不重要的资源，但不能屏蔽那些一旦缺失就会让 Google 更难理解网页的资源。这类被屏蔽的文件很少会以网页的形式出现在“网页索引编制”报告中，因此请从网页这一侧去找：在网址检查工具中运行实际网址测试，打开“查看已测试的网页”，再点击“更多信息”，查看 Google 加载了哪些网页资源。也要检查静态资源所在的主机：robots.txt 按主机、协议和端口分别生效，因此从 cdn.example.com 提供的文件，遵守的是该主机自己的 robots.txt。对于在浏览器中渲染的网站，负责生成网页内容的脚本一旦被屏蔽，影响最大，我们的 JavaScript 渲染指南对此有详细介绍。

如何用一个 URL 测试 robots.txt 规则

预测 Google 的判定并不需要任何工具。按照 Google 的规范，只需 4 步。

flowchart TD
    A["要测试的 URL"] --> B["打开同一主机、同一协议下的 robots.txt"]
    B --> C{"有针对 Googlebot 的分组吗？"}
    C -->|有| D["只使用该分组"]
    C -->|没有| E["使用 * 分组"]
    D --> F["列出所有与该路径匹配的 Allow 和 Disallow"]
    E --> F
    F --> G{"有匹配的规则吗？"}
    G -->|没有| H["允许抓取"]
    G -->|有| I["规则路径最长者优先"]
    I --> J{"Allow 和 Disallow 一样长吗？"}
    J -->|是| H
    J -->|否| K["采用最长的那条规则"]

1. 确定文件。 在与该 URL 完全相同的主机和协议下打开 /robots.txt。https://www.example.com/robots.txt 管不到 https://shop.example.com/。
2. 确定分组。 使用与 Googlebot 匹配的最具体的 User-agent 分组。User-agent 名称不区分大小写。
3. 找出匹配的规则。 如果某条规则的路径与 URL 路径及查询字符串的开头部分相符，该规则即为匹配。* 匹配任意字符，$ 表示 URL 的结尾，而路径区分大小写：/Shop/ 不匹配 /shop/。
4. 确定胜出的规则。 路径最长的规则胜出。如果 Allow 和 Disallow 长度相同，Google 采用限制较少的那条，也就是 Allow。

下面把这一方法应用于模式 3 中修改后的文件，并额外加上 Disallow: /search：

如果想核实 Google 自己的判定，而不是您的判断，请对该 URL 运行网址检查。在抓取详情中，“是否允许抓取？”会显示是否有 robots.txt 规则屏蔽了 Google，而实际网址测试使用的是 Google 当前能获取到的文件。Google 还把其 robots.txt 解析器作为开源库发布，开发者可以在新文件上线前，用它测试草稿文件。

先修正规则，再验证

修改文件，让您希望被抓取的网页不再被匹配。可以缩小宽泛的 Disallow，为例外情况添加一条更长的 Allow，或者删除遗留的分组。然后：

1. 获取线上文件，确认服务器返回的是您修改后的版本，而不是缓存副本或构建时的旧副本：curl -s https://www.example.com/robots.txt。
2. 在 Search Console 的 robots.txt 报告中请求重新抓取 robots.txt。 Google 通常会将该文件缓存最多 24 小时，而该报告的帮助文档正是把“解除对重要 URL 的屏蔽”列为请求重新抓取的理由之一。报告会显示 Google 上次获取该文件的时间以及任何错误或警告；含有错误的行会被忽略。
3. 在网址检查工具中，对 2 或 3 个受影响的 URL 运行实际网址测试。 “是否允许抓取？”现在应显示为“是”。对最重要的网页使用“请求编入索引”；Google 的帮助文档指出，编入索引可能需要一到两周。
4. 规则修正后，在“网页索引编制”报告中针对该问题点击“验证修复”。 Google 的文档指出，验证通常最多需要约 2 周，也可能久得多。

Google 关于重新抓取的帮助文档指出，抓取可能需要几天到几周不等，因此数量会逐步下降。之后仍留在报告中的 URL，应当都是您有意屏蔽的。

在解除对一个已被隐藏数月的网页的屏蔽之前，先像爬虫一样检查它：它的状态码、robots meta 标记和 canonical。一个谁都抓取不到的网页，可能带着被遗忘的 noindex，这会让它直接转入此网址带有“noindex”标记这一状态。我们的可索引性冲突分析介绍了这些信号如何相互作用。

Search Console 会告诉您哪些 URL 被屏蔽了。完整的 SEOReport 诊断会把您 sitemap 中列出的网页与 robots.txt 规则进行比对，列出那些您一边请搜索引擎去找、一边又禁止它们抓取的网页。它还会标记全站性的禁止抓取以及缺失的 robots.txt。它读取的是针对所有爬虫编写的规则，因此仅针对 Googlebot 的分组，仍需在网址检查工具中确认。

常见问题

大量被屏蔽的 URL 会损害我的网站吗？

不会，至少它本身不会。成千上万个被屏蔽的参数 URL 或搜索 URL，说明 robots.txt 正在发挥作用。请统计 sitemap 中列出的被屏蔽 URL，以及您希望获得排名却被屏蔽的网页；只有这些才会让您付出代价。

如果我的 robots.txt 不存在或返回错误，会怎样？

根据 Google 的规范，404 或其他 4xx 响应（429 除外）会被视为没有 robots.txt，因此不会屏蔽任何内容。5xx 错误则不同：Google 会在最初 12 小时内停止抓取该网站，之后最多 30 天内使用它所持有的最后一份有效副本。Google 对该文件的超时和 DNS 错误也采取同样的处理方式，因此一个超时的 robots.txt，可能会让一个完全没有屏蔽规则的网站暂停被抓取。

被屏蔽的 URL 应该从 sitemap 中移除吗？

应该。sitemap 列出的是您希望编入索引的 URL，因此不应包含任何被 robots.txt 屏蔽的 URL。把有意屏蔽的 URL 从 sitemap 中移除，对意外屏蔽的则解除屏蔽。我们的 XML sitemap 指南介绍了该文件中还应包含哪些内容。

我可以用 robots.txt 把网页从 Google 中移除吗？

不可以。robots.txt 控制的是抓取，而如果其他网页链接到一个被屏蔽的 URL，Google 仍然可以将其编入索引。要让网页不出现在搜索中，请允许 Google 抓取它，并添加 noindex。robots.txt 与抓取权限指南说明了各个工具分别负责什么。

子域名或 HTTP 上的 robots.txt 会影响我的主站吗？

不会。主机、协议和端口的每一种组合都有自己的文件，而且 Google 不会读取放在子目录中的 robots.txt 文件。staging.example.com 上的屏蔽文件无法屏蔽 www.example.com，但您的静态资源主机或 CDN 主机上的 robots.txt，确实决定着 Google 能否获取您的网页所加载的文件。