我们扫描了 30 个大型网站的 AI 可见度

我们发现了什么

30 个首页里没有一个拿到 A。最高的是 salesforce.com，83 分，只有 2 个站点达到 B。在 21 个正常返回页面的站点里，平均分是 62 分（满分 100）——按这个量表是 D。

第二个发现更尖锐。30 个域名里有 9 个在站点根目录不接纳 GPTBot、ClaudeBot、PerplexityBot、OAI-SearchBot 或 Google-Extended 中的至少一个——其中 7 个在 robots.txt 里写明，另有 2 个在服务器上就拒绝了请求，robots.txt 甚至还没被读到。样本里的每一家新闻出版商都在这一组里：6 个中有 6 个。出版行业并不是无意间滑向屏蔽 AI 爬虫的——它是主动选择的。

第三个发现和那些卖 AI 的公司有关。OpenAI 自己的首页得分是 13，Anthropic 的是 62，两者都低于样本平均值，而 OpenAI 的例子更尖锐：在同一次运行里，对 openai.com 的爬虫形式请求被以 HTTP 403 拒绝，而同一个 URL 的浏览器形式请求却被正常返回。两者都没有声明 Organization 实体。得分最高的站点是那些向开发者出售基础设施的站点，而不是出售答案的站点。

为什么这些低分比看上去更要紧

这些是首页，不是文章，而首页是任何站点上最难拿高分的页面：它很短、以导航为主，几乎不携带生成式回答所需的证据。这里分数低，并不意味着一个站点在 AI 回答里不可见——它们的文章可能好得多。

它真正说明的是，AI 系统最先落到的那一页，几乎没给它任何可引用的东西。没有统计数字，没有引述，通常没有问题式标题，而且往往没有实体标记来说明这个域名属于哪个组织。在 30 个里的 22 个上，读首页的模型拿不到一句关于「谁拥有这个站点」的结构化陈述。

三种不同的东西都能挡住爬虫

它们很容易被混为一谈，所以表里把它们分开。禁止是指 robots.txt 在根目录写明某个 AI agent 不得访问——一条公开的、有意为之的策略，任何爬虫都会遵守。拒绝是指服务器用错误回应了爬虫形式的请求，却把同一个 URL 正常返回给浏览器形式的请求：这种拦截发生在读取 robots.txt 之前，而由于 GPTBot、ClaudeBot、PerplexityBot 和 OAI-SearchBot 都以 bot 身份出现，这样一条规则会把这一页所讨论的每一个引擎都挡在门外。表里有 2 个域名属于这种情况。

两种请求形式都被拒绝，是第三种情况，不计为屏蔽。它说明请求是从这次扫描所在的网络被挡掉的，那是关于扫描器的证据，而不是关于 AI 访问的证据。表里有 4 个域名处于这种位置，表中把它们记为既不是禁止，也不是拒绝。

结果

这项研究是怎么做的

1. 这 30 个域名是手工挑选的，用来覆盖搜索、AI 实验室、企业软件、基础设施、开发者平台、新闻和德国工业。这是一个便利样本，不是随机样本，它也不是对互联网上最大站点的排名。
2. 每个首页都由 LLMention 爬虫从它自己的基础设施抓取，并诚实地以 bot 身份表明自己。它没有冒充 AI 爬虫，也不是从某个 AI 爬虫的地址发出的。在请求被拒绝的情况下，同一个 URL 会用浏览器形式的 User-Agent 再请求一次，这样就能把「针对已识别 bot 的规则」和「地址被封」区分开来。第二次请求从不给页面内容打分；它只决定一项检查，而它背后的规则发布在方法页上。
3. robots.txt、llms.txt 和 sitemap.xml 都从同一个源请求，然后对结果运行了 38 项有文档记录的检查。那是测量这些记录时的数量；扫描器今天发布 40 项检查，所以即使站点上什么都没变，在这里重跑一个域名也可能得到不同的分数。
4. 没有查询任何 AI 引擎。这一页上没有任何内容是对 ChatGPT、Claude 或 Perplexity 实际说了什么的测量——那是另一个实验，这个工具并不运行它。

这项研究的局限

• 只有首页。一个站点的文章通常比它的首页状态更好，所以这些分数低估了表中大多数站点。
• 只是一个时间点。robots.txt 和标记一直在变；表是快照，每一行都可以重跑。
• 地理依赖。按访客位置重定向的站点返回的是某个地区版本，而地区版本并不相同。stripe.com 在一次运行里返回了荷兰版，在另一次里返回了新加坡版。
• 两种请求形式都被拒绝，不能证明任何关于 AI 访问的事情。当扫描器既被当作 bot 又被当作浏览器挡掉时，拦截针对的是它来自的网络，表里会照实这么写，而不是怪罪站点。一次拒绝能说明的，是相反的那种情况——浏览器被正常服务，bot 被拒绝——那才是一条正好针对这一页所测量爬虫的规则。
• 一次拒绝可能在两次请求之间变化。在这次重跑中，有一个站点先以 200 回应了浏览器形式的请求，几分钟后又给出了和给爬虫一样的错误。所以「拒绝」的标记是某一个时刻的一次观察，不是站点的稳定属性，重跑时这一行可能看起来不一样。
• 不是预测。这些是就绪度检查，不是对引用的测量。一个站点可能只有 12 分，明天照样被引用。

复现它

整张表都以数据形式发布，所以不用抓取这一页也能核对它的算术：/study/data/（英文）返回包含数据行、计数、平均分和等级分布的 JSON，而 ?format=csv（英文）把同样的数据行返回成电子表格。两者都由这一页渲染的那个数组生成，所以不可能与它不一致。

采集步骤也在仓库里。npm run study:run 会对着线上端点把同样的 30 个首页走一遍，并按照上面那张表存储这些行的形状把它们打印出来——也就是 /study/data/（英文）以 JSON 返回的同一批数据行。节奏控制是方法的一部分，而不是出于礼貌：它保持在端点自己的速率限制之下，因为一个被记为「关于某个站点的发现」的 429 会污染数据，而不只是让这次运行变慢。

上面的每一行都来自同一个公开端点，而 brief=1 只返回最关键的几个数字：

curl "https://llmention-geo.com/api/scan?domain=github.com&brief=1"

{"domain":"github.com","status":200,"browserStatus":null,
 "scoreBasis":"homepage","score":60,"grade":"D",
 "checksRun":38,"checksPassed":22,"aiCrawlersBlocked":false,
 "hasJsonLdEntity":false,"hasSameAs":false,"hasRobotsTxt":true,
 "topIssue":"robots-sitemap"}

每个数字背后的规则都发布在方法页上，包括分数看不到的那部分图景。如果这里的结果看起来不对，那是一个缺陷报告，而且很受欢迎——会修的是检查，而不是数字。

对这张表的三种解读

这些数据行是一回事，从它们得出的东西是另一回事。下面三篇走的是同一份数据，并且都链回它：

• 我们扫描了 30 个首页，没有一个拿到 A——0 of 30 评分为 A。
• 九个首页从未回应爬虫——9 of 30 以错误响应作答。
• 六家新闻出版商，六家屏蔽 AI 爬虫——6 of 6 新闻站点屏蔽了爬虫。