主页 / server / 问题 / 1170223
Accepted
David Christian
Asked: 2025-01-16 23:49:59 +0800 CST

是否可以在 robots.txt 中匹配两个不同的禁止规则，一个通过通配符，另一个通过名称？

  • 772

我有一个 robots.txt 文件，如下所示：

    User-agent: *
    Disallow: /account/
    Disallow: /captcha/
    Disallow: /checkout/
    
    User-agent: DataForSeoBot
    Disallow: /p-

    User-agent: UptimeRobot
    Disallow: /p-

我的通配符禁止规则中有几十个文件和文件夹。然后我想另外阻止特定爬虫程序（如 DataForSeoBot）访问以 /p- 开头的 URL。在为 DataForSeo 添加特定规则之前，它在我的通配符规则中看到的是长长的 URL 列表。在我根据他们的机器人名称添加了额外的特定规则后，DataForSeoBot 现在看到的唯一禁止规则是 /p- 规则。他们是否错误地读取了 robots.txt 文件，还是我写错了？我希望我不必为每个我想禁止 /p- 的爬虫程序重复整个第一条规则，因为大约有十几个。我还尝试将特定的按名称规则移到通配符规则之前的顶部，但这没什么区别。

我正在测试使用他们网站上的功能来查看他们如何读取 robots.txt 文件。

DataForSeo robots.txt

web-crawler

1 个回答

  1. Best Answer

    标准模糊

    拟议标准 RFC 9309：机器人排除协议在第 2.2.1 节中指出：

    如果有多个组与用户代理匹配，则必须将匹配的组规则合并为一个组，并根据第 2.2.2 节进行解析。

    这定义了用户代理匹配规则*（所有用户代理）将针对所有用户代理进行组合，尽管存在user-agent更具体的匹配行。

    然而，我发现它有些模棱两可，因为它接下来的内容是：

    如果不存在匹配的组，则爬虫程序必须遵循具有“*”值的用户代理行（如果存在）的组。

    这表明 可能user-agent: *具有一些特殊含义，根本不属于“必须组合”的范围。如果 已经匹配所有用户代理，并且所有匹配的用户代理都必须组合，那么为什么这句话首先会出现在那里？此外，第 5.1 节*中的示例是以支持这种解释的方式编写的。

    在实现过程中也总是存在误解。例如，人们应该非常小心第 5.2 节中的最长匹配；它是匹配 URL 和 URL 本身的要求。组合匹配用户代理的要求则恰恰相反。

    实用的解决方案

    如果您想确保大多数实现都能按照您的意图实现，您可以比协议要求更明确，并再次列出每个匹配组的所有常见的不允许路径。

    User-agent: *
Disallow: /account/
Disallow: /captcha/
Disallow: /checkout/

User-agent: DataForSeoBot
Disallow: /p-
Disallow: /account/
Disallow: /captcha/
Disallow: /checkout/

User-agent: UptimeRobot
Disallow: /p-
Disallow: /account/
Disallow: /captcha/
Disallow: /checkout/
    • 0

相关问题