BotVisibility Checker：基于37项清单的AI友好度网站审计代理-开发者社区

1. 项目概述：一个为AI时代准备的网站审计代理

如果你正在开发一个网站或API，并且希望它不仅仅能被人类用户访问，还能被各种AI助手、智能代理和自动化工具顺畅地“理解”和“使用”，那么你很可能已经遇到了一个核心问题：如何系统地评估和改进你的站点对AI的友好度？这正是BotVisibility Checker这个Claude托管代理所要解决的核心痛点。它不是一个需要你自行部署和维护的复杂应用，而是一个可以直接在Anthropic的托管环境中运行的“审计专家”，其核心任务就是对照一份包含37个检查项的清单，对你的网站或代码仓库进行一次全面的“AI可读性”体检。

这个项目的价值在于，它将一个抽象的概念——“对AI友好”——转化为了具体、可测量、可执行的检查项。在AI代理（如ChatGPT、Claude、GitHub Copilot以及各种自定义GPT和MCP客户端）日益成为重要用户入口的今天，你的数字资产是否做好了准备，直接决定了你能否抓住这波技术浪潮带来的机会。许多站点在开发时并未考虑机器可读的元数据、结构化的API描述或专门的AI端点，这导致AI代理在尝试交互时要么根本“找不到”你，要么“看不懂”你，要么“用不好”你。BotVisibility Checker就像一位经验丰富的顾问，能精准地告诉你哪里缺失了关键信息，以及修复这些问题的优先级和预估工作量。

2. 核心设计理念与工作流程拆解

2.1 为何选择托管代理模式？

BotVisibility Checker选择以Claude托管代理的形式交付，这背后有几个关键考量。首先，它极大地降低了使用门槛。用户无需关心服务器部署、依赖管理、工具链配置或代理循环逻辑的编写。你只需要一个Claude API密钥和一个符合要求的托管环境，上传代理定义文件即可获得一个随时可用的审计服务。这种“即服务”模式，将复杂性完全封装，让开发者可以专注于审计结果本身，而非运维细节。

其次，托管代理模式提供了强大的、开箱即用的工具集（agent_toolset_20260401）。这个工具集包含了执行审计所需的所有基础能力：bash用于运行本地命令（如执行BotVisibility CLI），web_fetch用于抓取网页内容，read/write用于文件操作等。代理开发者无需从零构建这些工具，只需在系统指令中定义好如何使用它们的逻辑。这保证了审计行为的稳定性和一致性，也使得代理的逻辑可以专注于更高层次的决策——如何解析输入、如何分配抓取预算、如何评估检查项、如何生成报告。

最后，这种模式确保了审计过程的可预测性和成本可控性。代理被设计为“沉默执行”，它在收到输入后，会严格按照预设的两轮抓取预算执行操作，期间不向用户输出任何中间状态，最终一次性返回完整的结构化报告。这种设计避免了因交互式对话或工具调用循环失控导致的不可预测的API调用次数和费用，使得单次审计的成本几乎是固定的。

2.2 两轮抓取预算：效率与深度的平衡术

代理的核心执行逻辑围绕一个严格的两轮抓取预算展开，这是整个设计中最精妙的部分之一。它完美地平衡了审计的深度与执行效率、成本之间的关系。

第一轮抓取：并行获取基础信号代理启动后，会立即并行发起最多四次网络请求：

获取主页HTML：这是评估站点内容的基础，用于检查<head>中的元标签、结构化数据（如JSON-LD）、Open Graph标签等。
获取HTTP响应头：通过bash调用curl -sI命令实现。响应头中包含了大量关键信息，如Content-Type、缓存控制头（Cache-Control）、CORS策略头（Access-Control-Allow-Origin）等，这些对于评估API的可用性至关重要。
获取robots.txt：这个文件定义了网站对爬虫的访问规则。一个对AI友好的robots.txt不应该盲目禁止所有AI爬虫，而是应该有选择性地允许负责任的AI代理访问。
获取sitemap.xml：站点地图是帮助AI代理发现网站深层内容的重要途径。检查其是否存在、格式是否正确、链接是否有效。

这四类信息是评估一个网站“AI可发现性”和基础“可用性”的最低必要数据集。并行获取最大限度地减少了等待时间。

第二轮抓取：针对性跟进在第一轮抓取结果的基础上，代理会解析内容，寻找需要进一步检查的特定文件或链接，并进行最多四次跟进抓取。例如：

如果在robots.txt中发现了针对AI爬虫的特殊规则文件（如llms.txt），则抓取它。
如果在HTML中发现了声明AI插件配置的文件链接（如ai-plugin.json或.well-known/ai-plugin.json），则抓取它。
如果发现了RSS/Atom订阅源（feed）的URL，也会抓取以评估内容更新的机器可读性。

“无第三轮”原则两轮之后，无论是否收集齐所有理想数据，代理都会停止抓取，并基于现有数据生成报告。无法获取数据而无法评估的检查项会被标记为N/A（不适用），并从总分分母中排除。这条铁律彻底杜绝了因链接爬取或重定向跟踪可能导致的无限循环或成本激增，确保了每次审计都是快速、廉价且结果确定的。

注意：这个两轮预算的设计是基于大量实践经验的总结。它覆盖了绝大多数关键检查点所需的数据源。如果某个站点的情况特别复杂，导致关键数据在两轮后仍未获取（例如，ai-plugin.json的链接藏在需要JavaScript渲染才能看到的元素中），报告中的“局限性”章节会明确指出这一点，并告知用户需要何种访问权限才能完成完整评估。这比让代理陷入不可预测的抓取尝试要透明和负责任得多。

2.3 多模式输入与智能路由

为了适应不同的审计场景，代理设计了灵活的多模式输入处理逻辑。这体现了其作为通用工具的实用性。

完整URL：这是最标准的模式。代理将其视为在线站点，执行上述的两轮网络抓取流程。它不会尝试在托管环境内运行任何本地CLI命令。
局部域名：如果用户只输入了example.com，代理会智能地为其添加https://前缀，并会在报告中注明这一假设。这个细节很重要，因为它避免了因协议缺失导致的抓取失败，同时保持了报告的准确性。
本地仓库路径：当输入类似/home/user/projects/my-app的路径时，代理的行为完全不同。它会首先尝试在环境内使用bash工具运行npx botvisibility <path>命令。这个命令会调用BotVisibility项目的Node.js CLI工具对本地代码进行静态分析。然后，代理会基于CLI的输出，再辅以一些手动检查（例如，检查目录中是否存在某些配置文件），来补充完成审计。这种模式非常适合在开发阶段或CI/CD流水线中集成。
原始HTML：用户可以直接粘贴一段HTML代码。代理会对这段静态代码进行分析，评估其中包含的元数据、结构化数据等。但它会明确在报告中指出，由于缺乏服务器端信号（如HTTP头、robots.txt），因此部分检查项无法评估。
模糊输入：对于无法识别的输入格式，代理不会猜测或执行可能错误的操作，而是会直接向用户询问澄清，确保审计目标明确无误。

这种智能路由机制使得同一个代理可以无缝应对生产环境站点审计、开发本地代码审查等多种场景，大大提升了工具的适用范围。

3. 37项检查清单深度解析

BotVisibility的37项检查并非随意罗列，而是被精心组织成四个具有逻辑递进关系的层级，分别对应一个站点在“AI友好度”上可能达到的不同成熟度阶段。理解这四个层级，有助于我们把握优化的整体方向。

3.1 第一层级：可发现性

目标：确保AI代理能够找到并初步理解你的网站。检查项：14项。这是最基础也是最重要的层级。如果AI连你的网站都发现不了，或者发现了却看不懂基本内容，后续的一切都无从谈起。这一层主要检查“静态”的、声明式的元信息。

核心元标签：检查<title>、<meta name="description">是否清晰、独特。这是AI理解页面主题的最快途径。
结构化数据：检查是否使用了Schema.org词汇表（通过JSON-LD、微数据或RDFa格式）来标记内容，例如文章、产品、活动等。结构化数据是机器理解页面内容的“金钥匙”。
开放图谱与Twitter卡片：检查OG和Twitter Card标签是否完善。虽然最初为社交媒体设计，但这些标签也已成为AI代理获取页面摘要和缩略图信息的通用标准。
机器可读文件：检查robots.txt、sitemap.xml、humans.txt（可选）等文件是否存在且格式正确。特别是robots.txt，需要评估其是否对常见的AI用户代理（如GPTBot,ClaudeBot）有合理的规则。
llms.txt文件：这是一个新兴的最佳实践文件，类似于robots.txt，但专门用于向大型语言模型和AI代理声明网站的访问偏好和规则。检查其是否存在及内容合理性。
API发现端点：检查是否在.well-known/目录下提供了标准的API描述文件，如ai-plugin.json（用于OpenAI插件）或openapi.json（Swagger/OpenAPI规范）。这是AI代理发现并连接你网站API的标准化方式。

实操心得：很多开发者会忽略robots.txt对AI爬虫的影响。一个常见的反模式是User-agent: * Disallow: /，这等于对包括AI在内的所有爬虫关上了大门。更合理的做法是针对特定的、行为良好的AI爬虫（如User-agent: GPTBot）设置允许规则，或者至少为内容页面设置Allow。BotVisibility检查会明确指出这类问题。

3.2 第二层级：可用性

目标：确保AI代理能够有效地与你的网站或API进行交互。检查项：9项。当AI找到了你的站点，下一步就是尝试使用它。这一层关注动态交互过程中的兼容性问题。

API身份验证：检查API是否支持AI代理友好的认证方式，如API密钥（在请求头中传递）、Bearer Token或OAuth 2.0。避免使用仅适用于浏览器会话的Cookie认证或复杂的人类交互式认证流程。
错误处理：检查API是否返回机器可读的错误响应。理想情况下，错误应该使用标准的HTTP状态码，并在响应体中提供结构化的JSON错误信息，包含code和message字段，而不是简单的HTML错误页面。
速率限制与配额：检查API是否公开了清晰的速率限制策略（通过响应头如X-RateLimit-Limit,X-RateLimit-Remaining等）。这有助于AI代理规划其请求节奏，避免被意外封禁。
CORS策略：对于Web API，检查是否设置了适当的跨源资源共享头，允许从不同源（如AI代理运行的环境）发起的请求。不正确的CORS配置会直接在浏览器环境中阻止请求。
内容协商：检查API是否支持Accept和Content-Type头，能够根据请求返回JSON等机器友好格式，而非默认的HTML。

3.3 第三层级：优化

目标：提升AI代理与你的服务交互时的效率，减少不必要的资源消耗（尤其是昂贵的LLM上下文令牌）。检查项：7项。在可用基础上，进一步优化体验，让AI代理用得更“省力”、更“聪明”。

分页与过滤：检查列表API是否支持分页（如page,limit,offset参数）和过滤（如filter[field]=value）。这允许AI代理精准获取所需数据子集，避免一次性拉取海量数据。
字段选择：检查API是否支持类似GraphQL字段选择或?fields=参数的功能，允许调用方指定需要返回的字段。这可以显著减少不必要的数据传输和令牌占用。
缓存控制：检查HTTP响应是否包含有效的Cache-Control、ETag或Last-Modified头。这使AI代理能够缓存静态或半静态资源，减少重复请求。
响应压缩：检查是否支持gzip或br等响应压缩，以减少网络传输的数据量。

3.4 第四层级：原生代理支持

目标：为AI代理提供一流的、量身定制的交互体验。检查项：7项。这是最高级别的支持，意味着你的服务将AI代理视为一等公民，提供了专为它们设计的接口。

意图端点：提供专门的API端点，接收自然语言描述的“意图”（如“为用户预订下周二下午两点的会议室”），而不是僵硬的参数。这需要后端集成自然语言理解能力。
会话管理：为AI代理提供创建和管理多轮对话会话的能力，保持上下文。
范围令牌：提供具有细粒度权限、短期有效的访问令牌，增强安全性。
工具模式：以结构化格式（如OpenAI的Function Calling Schema或Anthropic的Tool Use Schema）公开你的API能力，使AI代理能直接“理解”并调用它们。
ai-plugin.json规范：完整实现OpenAI插件规范，提供清晰的自然语言描述、认证方式和API定义。

需要特别注意的是，第四层级的检查项（4.1至4.7）在标准网站审计中通常是N/A，因为它们往往需要已认证的API访问权限才能评估。因此，在BotVisibility Checker的报告中，这些项会被单独列在“CLI-Only Items”部分。要完整评估这一层级，通常需要结合本地代码审计或提供API密钥进行深度扫描。

4. 报告结构与评分机制详解

BotVisibility Checker的最终产出是一份高度结构化的7部分报告。这份报告的设计目标不仅是给人看，也便于被其他工具解析和集成。

4.1 报告各部分精读

1. 输入与范围这部分首先确认代理是如何理解你的输入的（例如，将example.com解释为https://example.com）。然后，它会详细列出审计过程中实际获取了哪些资源（如成功抓取的URL列表），以及遇到了哪些访问限制（如被robots.txt阻止、遇到CAPTCHA验证码）。这为报告的局限性提供了透明背景。

2. 总体得分给出一个直观的分数，格式为X / 37。关键在于，分母37会减去所有被标记为N/A的检查项数量。这意味着得分只基于实际可评估的检查项计算，更加公平合理。例如，一个纯静态网站没有API，那么所有与API相关的检查项都是N/A，它的得分就是基于剩余的可评估项计算，不会因为缺少不相关的功能而得分过低。

3. 分类得分用一个4行的表格展示四个层级各自的得分情况。这能让你一眼看出网站的强项和短板在哪里。是“可发现性”基础没打好，还是“可用性”的API设计有问题，亦或是“优化”层面做得不足？

4. 检查结果表这是报告的核心，是一个逐项列出37个检查结果的表格。每一行包含：

#：检查项编号。
Item：检查项名称。
Status：状态，取值为PASS（通过）、FAIL（失败）、PARTIAL（部分通过）、N/A（不适用）。
Severity：严重性（仅对FAIL/PARTIAL状态）。分为High（阻碍AI代理发现或使用）、Medium（降低AI代理用户体验）、Low（最佳实践缺失）。
Finding：具体的检查发现描述。对于FAIL项，这里会明确指出问题所在；对于PASS项，可能会确认发现的正确配置。

5. 仅CLI检查项单独列出第4层级的7个检查项及其状态。如前所述，这些通常需要更深度的访问权限。

6. 优先级建议这是最具行动指导意义的部分。代理会根据检查结果的严重性，将修复建议分为高、中、低三个优先级。

高优先级：通常是那些标记为High严重性的FAIL项。例如，robots.txt完全禁止了所有AI爬虫，或者API完全缺乏机器可读的错误信息。修复建议会具体说明“做什么”，并附上“为什么这很重要”的原理性解释，以及“预估工作量”（Quick Win, Moderate, Complex）。
中优先级：通常是Medium严重性的问题或High严重性的PARTIAL项。例如，缺少结构化数据或sitemap.xml。
低优先级：通常是Low严重性的问题或一些优化建议。例如，未启用HTTP/2或缺少特定的缓存头。

7. 局限性诚实地列出本次审计中哪些项目因为数据不足无法评估，以及需要什么条件（如提供API访问权限、登录凭证等）才能完成完整评估。这体现了工具的严谨性。

4.2 评分算法逻辑

评分不是简单的加权平均，而是采用了条件递进式逻辑，更符合实际能力建设的阶段。

对于第1-3层级（递进式评分）：

达到第1层级：需要超过50%的第1层级检查项通过（PASS）。
达到第2层级：有两种路径：
1. （稳健路径）第1层级达标（≥50%）且第2层级达标（≥50%）。
2. （补偿路径）第1层级略有欠缺但尚可（≥35%）且第2层级非常优秀（≥75%）。这考虑到了某些应用可能天生“可发现性”特征较弱（如内部API），但“可用性”设计得极其出色的情况。
达到第3层级：同样有两种路径：
1. 第2层级已达标且第3层级达标（≥50%）。
2. 第2层级略有欠缺（≥35%）且第3层级非常优秀（≥75%）。

对于第4层级（独立评分）：

独立于1-3层级计算。只要超过50%的适用的第4层级检查项通过，即可被认定为“具备原生代理支持能力”。
这意味着一个网站可以同时是“第2层级 + 原生代理就绪”，即它的基础交互功能良好，并且为高级AI集成做好了准备。

这种评分机制鼓励开发者先打好基础（L1，L2），再追求高级优化（L3）和原生集成（L4），同时也为不同特点的服务提供了灵活的达标路径。

5. 部署与使用实战指南

5.1 环境准备与代理注册

使用BotVisibility Checker代理，你需要准备的是一个符合要求的Claude托管环境，而不是部署一个传统的服务器应用。

第一步：获取凭证与权限

拥有一个有效的Anthropic平台账户。
在平台设置中生成一个API密钥（ANTHROPIC_API_KEY）。
确认你的账户已启用Managed Agents功能（目前对所有API账户默认开启）。

第二步：准备托管环境你需要创建一个Managed Agents Environment。关键配置如下：

基础镜像：选择或创建一个包含Node.js和npm的环境。因为当输入是本地路径时，代理需要运行npx botvisibility命令。确保Node.js版本不是过于陈旧。
网络策略：这是最容易出错的地方。你的环境必须允许出站网络访问到：
- 任意用户提供的域名：因为代理需要去抓取用户指定的网站（如https://example.com）。如果你的环境默认拒绝所有出站连接，你需要配置允许访问*或*.com等（具体取决于你的安全策略）。
- npm注册表：npx命令在第一次运行时需要从https://registry.npmjs.org下载botvisibility包。同样需要放行。
文件系统：无需预先挂载任何特定文件。当进行本地仓库审计时，假设目标仓库的代码已经存在于容器启动时的当前工作目录中。

第三步：注册代理你可以使用项目根目录提供的botvisibility-agent.yaml或botvisibility-agent.json文件进行注册。两者内容完全一致，JSON格式更适合通过API直接调用。以下是使用cURL命令通过JSON文件注册的示例：

# 假设你的API密钥已存储在环境变量中 export ANTHROPIC_API_KEY='your-api-key-here' # 使用curl命令注册代理，注意必须包含beta头 curl -fsSL https://api.anthropic.com/v1/agents \ -H "x-api-key: $ANTHROPIC_API_KEY" \ -H "anthropic-version: 2023-06-01" \ -H "anthropic-beta: managed-agents-2026-04-01" \ -H "content-type: application/json" \ -d @botvisibility-agent.json

执行成功后，API会返回一个JSON响应，其中包含新创建的代理的id字段。请妥善保存这个ID，后续启动会话时需要用到。

重要提示：anthropic-beta: managed-agents-2026-04-01这个请求头是必须的，它表明你正在调用托管代理的Beta API。缺少这个头会导致请求失败。

5.2 启动审计会话与解读报告

注册代理后，你就可以通过创建会话来使用它了。会话（Session）是代理运行的一次实例化。

启动会话并发送审计请求这个过程通常需要编写一段简单的程序来完成。以下是一个概念性的Python示例，展示了如何使用Anthropic Python SDK（请注意，具体SDK调用方式可能随版本更新而变化，请以官方文档为准）：

import anthropic import json client = anthropic.Anthropic(api_key="your-api-key") # 1. 创建会话，指定之前注册的代理ID和你配置好的环境ID session = client.agents.sessions.create( agent_id="your-botvisibility-agent-id", environment_id="your-managed-environment-id", metadata={"purpose": "website_audit"} # 可选的元数据 ) # 2. 向会话发送用户消息，内容就是你要审计的目标 user_message = "请审计 https://example.com" user_event = client.agents.sessions.messages.create( session_id=session.id, role="user", content=user_message ) # 3. 等待并获取代理的回复 # 由于代理被设计为“沉默执行”，它会在一段时间后一次性返回完整报告。 # 在实际应用中，你可能需要轮询或使用流式响应/Webhook来获取最终结果。 response = client.agents.sessions.messages.list( session_id=session.id, limit=1 ) # 假设最后一条消息是代理的回复 agent_response = response.data[0].content[0].text print(agent_response)

报告解读与行动收到报告后，你应该按以下步骤处理：

直奔“优先级建议”：先看高优先级建议。这些问题通常是阻碍AI代理访问的核心障碍，修复它们往往能带来立竿见影的效果。
核对“检查结果表”：针对高优先级问题，回到详细表格查看具体的Finding描述，理解问题细节。
评估“局限性”：如果报告指出某些项目因权限问题无法评估，你需要判断是否值得提供相应权限（如API密钥）进行更深入的扫描。对于内部或开发中的项目，这可能很有价值。
制定修复计划：根据“预估工作量”，将修复项纳入你的开发排期。许多“快速修复”可能只需要几分钟（如在robots.txt中添加一行规则），但收益巨大。
迭代优化：修复后，可以再次运行审计，验证问题是否已解决，并查看得分提升情况。将其作为持续改进流程的一部分。

5.3 自定义代理行为

项目提供的代理定义文件是高度可定制的。最常见的自定义场景包括：

更换模型默认使用claude-sonnet-4-6模型。如果你希望使用更快的claude-haiku以降低成本（但可能牺牲一些复杂逻辑的理解能力），或者使用更强大的claude-opus进行最深入的分析，只需修改YAML或JSON文件中的model.id字段。

# 在 botvisibility-agent.yaml 中修改 model: id: claude-haiku-20240307 # 或 claude-opus-20240229 preset: standard

精简工具集以增强安全如果你在一个高度受限或安全至上的环境中使用此代理，并且确定不需要某些工具（例如，你只审计本地代码，不需要web_search功能），可以显式禁用它们。

tools: - type: agent_toolset_20260401 default_config: enabled: true permission_policy: type: always_allow configs: - name: web_search enabled: false # 禁用网络搜索功能 - name: web_fetch # 可以进一步配置web_fetch，例如设置超时或允许的域名列表 config: timeout_ms: 10000

修改系统指令（高级）system字段中的提示词是代理的“宪法”，定义了它的所有行为规则。你可以修改它，但必须非常小心，以免破坏其核心逻辑。如果你需要调整，请务必理解并保持以下几个“不变式”：

两轮抓取的预算逻辑。
“沉默执行”原则（仅在开始和结束时输出）。
输入路由逻辑（URL、路径、HTML的处理方式）。
37项检查清单的结构和四个层级的定义。
7部分报告的输出格式。

修改后，务必同时更新.yaml和.json两个文件，并使用diff工具确保它们内容一致。

6. 常见问题与排查技巧

在实际部署和使用BotVisibility Checker代理的过程中，你可能会遇到一些典型问题。以下是我根据经验总结的排查清单。

6.1 代理注册与会话启动失败

问题现象	可能原因	解决方案
注册代理时返回`401`或`403`错误	1. API密钥无效或过期。 2. 账户未启用Managed Agents功能。	1. 在Anthropic控制台重新生成API密钥并确保复制完整。 2. 检查账户权限或联系Anthropic支持确认功能状态。
注册代理时返回`400`错误，提示无效JSON/YAML	代理定义文件格式错误。	1. 使用在线YAML/JSON校验器检查文件语法。 2. 确保YAML缩进正确（使用空格，不要用Tab）。 3. 确保JSON文件是有效的，没有尾随逗号。
注册代理时返回`400`错误，提示缺少beta头	请求头中未包含`anthropic-beta: managed-agents-2026-04-01`。	在注册请求的headers中明确添加该头。
创建会话失败，提示`Environment not found`或`Agent not found`	提供的`environment_id`或`agent_id`不正确。	1. 确认环境ID和代理ID是从正确的API响应中获取的。 2. 检查ID是否输入错误。
会话创建成功，但发送消息后代理无响应或报错	1. 环境网络策略阻止了出站连接。 2. 环境中缺少Node.js。	1. 检查Managed Environment的网络策略，确保允许访问外部网站和npm registry。 2. 登录环境检查Node.js和npm是否已安装且版本合适。

6.2 审计执行过程中的问题

问题现象	可能原因	解决方案
报告显示大量检查项状态为`N/A`，且“局限性”指出抓取失败。	目标网站屏蔽了爬虫或代理的IP。	1. 检查目标网站的`robots.txt`和防火墙规则。 2. 尝试从另一个网络环境（非托管环境）访问该URL，确认其可公开访问。 3. 考虑是否因频繁请求触发了速率限制。
对本地路径审计时，报告显示`npx botvisibility`命令未找到或执行失败。	1. 环境内未安装Node.js/npm。 2.`npx`网络连接失败。 3. 指定的本地路径在容器中不存在。	1. 确保创建环境时选择了包含Node.js的基础镜像。 2. 检查环境网络策略是否允许访问`registry.npmjs.org`。 3. 确认启动会话时，本地代码已正确挂载或放置在环境的当前工作目录。
报告中的分数与预期不符，感觉某些该通过的项失败了。	1. 代理的检查逻辑可能有误判。 2. 网站使用了动态渲染，代理抓取到的HTML与浏览器看到的不同。 3. 网站有地域或CDN缓存问题，导致代理看到的是旧版本。	1. 仔细阅读失败项的`Finding`描述，确认问题。 2. 手动检查网页源代码，确认元数据是否确实存在且格式正确。 3. 尝试清除CDN缓存或直接访问源站IP进行测试。
审计耗时非常长。	1. 目标网站响应慢。 2. 网络延迟高。 3. 代理在等待某个超时的请求。	1. 这是两轮抓取预算设计的优势之一，最坏情况下也有时间上限。 2. 检查环境与目标网站之间的网络状况。 3. 考虑在代理定义中为`web_fetch`工具配置更短的超时时间（如`timeout_ms: 8000`）。

6.3 报告解读与优化建议

疑问点	解释与建议
我的网站没有API，为什么还要关心“可用性”和“优化”层级？	即使是一个纯内容网站，其“可用性”也体现在HTML的语义化、图片的`alt`标签、链接的清晰度上，这些影响AI对内容的理解。“优化”则体现在页面加载速度、缓存策略上，影响AI代理处理页面的效率。你可以专注于与内容相关的检查项。
“可发现性”层级得分很高，但“总体得分”不高，怎么办？	这很常见。说明你的网站基础SEO做得不错，但在面向AI交互的更深层次支持上有所欠缺。请重点查看“可用性”和“优化”层级的失败项，这些往往是阻碍AI从“阅读”转向“使用”你网站的关键。
报告建议我添加`llms.txt`，这是什么？有必要吗？	`llms.txt`是一个新兴的、专门面向AI爬虫的声明文件。它允许你更精细地控制AI如何与你的网站交互，例如指定允许抓取的页面、建议的抓取频率、甚至提供联系信息。虽然不是强制标准，但添加它是一个明确的友好信号，并且被BotVisibility清单视为一项最佳实践。
如何将BotVisibility审计集成到我的CI/CD流程中？	最佳实践是使用其本地仓库路径模式。在你的CI服务器（如GitHub Actions, GitLab CI）上，配置一个包含Node.js的环境，在构建步骤中克隆你的代码，然后调用部署好的BotVisibility代理（通过API）对代码路径进行审计。可以将报告输出为结构化数据（如JSON），并设置质量门禁：例如，要求“可发现性”层级必须达标，或不允许有“高”严重性问题。

BotVisibility Checker代理提供了一个前所未有的、系统化的视角，让我们能够以机器可度量、可执行的方式，来评估和提升数字资产在AI时代的适应能力。它不仅仅是一个检查工具，更是一份面向未来的网站与API设计指南。通过定期运行审计并将其纳入开发流程，你可以确保你的项目始终走在人机协作体验的前沿。