开发者与 Agent
用 MCP 读取 SEO 与 GEO 数据，生成有依据的诊断
先说结论
高质量诊断必须形成一条可追踪链路：
原始数据 → 字段含义 → 检查规则 → 问题实例 → 修复建议 → 复核结果只让 Agent “看看数据并给建议”，通常会得到一篇语言流畅但无法复现的报告。
一、先建立数据源清单
| 数据源 | 能回答的问题 | 不能直接证明什么 |
|---|---|---|
| 页面抓取 | 状态码、正文、标签、链接 | 平台一定已抓取或引用 |
| Search Console | Google 搜索中的官方表现数据 | 其他 AI 平台表现 |
| Bing Webmaster Tools | Bing 生态中的抓取或 AI 数据 | 全网 AI 可见度 |
| 服务器日志 | 某请求何时访问、返回什么状态 | 请求背后的真实意图 |
| 分析工具 | 已识别访问、会话和转化 | 所有无引荐或跨设备路径 |
| 第三方问题采样 | 固定条件下的回答和引用 | 平台总体市场表现 |
| CRM / 收入 | 线索和成交结果 | 单一页面或引用必然造成成交 |
每个 MCP 工具都应返回数据来源和时间范围，而不是只返回一个分数。
二、工具设计：少做“万能分析”，多做明确动作
不推荐：
seo_everything(url) → score, recommendations推荐：
crawl_url(url, user_agent, render_mode)
get_index_status(url, date)
query_search_metrics(site, start_date, end_date, dimensions)
query_server_logs(path, start_time, end_time, status_codes)
get_prompt_observations(question_set_id, run_id)原因很简单：动作越具体，输入、权限、证据和错误越容易验证。
示例输入 Schema
{
"type": "object",
"properties": {
"url": {"type": "string", "format": "uri"},
"userAgent": {"type": "string", "enum": ["browser", "googlebot", "oai-searchbot"]},
"renderMode": {"type": "string", "enum": ["initial-html", "rendered-dom"]}
},
"required": ["url", "userAgent", "renderMode"],
"additionalProperties": false
}Schema 能限制输入形式，却不能替代业务判断。例如 200 只说明请求成功，不说明正文正确，更不说明页面会被引用。
三、统一证据返回结构
{
"source": "server-log",
"collectedAt": "2026-10-04T10:00:00Z",
"scope": {
"site": "example.com",
"path": "/pricing",
"start": "2026-09-27",
"end": "2026-10-03"
},
"observation": {
"statusCodes": {"200": 21, "403": 7},
"matchedUserAgent": "OAI-SearchBot"
},
"limitations": [
"User-Agent can be spoofed",
"IP verification was not performed"
]
}至少保留：
- 来源；
- 采集时间；
- 查询范围；
- 原始值或可回查位置；
- 数据限制；
- 工具和规则版本。
没有范围的数据，不是证据，只是一个数字。
四、诊断应输出“问题实例”，而不是散乱建议
{
"issueId": "ISSUE-2026-104",
"ruleId": "access.waf-block",
"status": "confirmed",
"severity": "high",
"subject": "https://example.com/pricing",
"evidence": [
{
"source": "server-log",
"observedAt": "2026-10-03T09:30:00Z",
"fact": "7 requests returned HTTP 403"
}
],
"impact": "Search crawler may be unable to retrieve the pricing page",
"recommendation": "Review the matching WAF rule before changing robots.txt",
"verification": "Repeat the same request and confirm a valid 200 response"
}注意 impact 使用“可能”，因为 403 证据能证明请求失败，却不能单独证明引用下降由它造成。
五、错误与数据不足必须是一等结果
至少区分：
| 状态 | 含义 |
|---|---|
confirmed | 有足够证据确认问题 |
not_found | 已完成适用检查，未发现问题 |
insufficient_data | 权限、样本或时间范围不足 |
not_applicable | 规则不适用于该对象 |
tool_error | 工具或数据源失败 |
不要把“没有权限读取日志”写成“未发现 WAF 拦截”。
六、安全设计
- 最小权限：分析工具默认只读；
- 服务端授权：按用户、站点、资源和动作检查；
- 禁止令牌透传：不要把用户令牌不加验证地转交下游；
- 敏感字段脱敏：日志中的 IP、Cookie、邮箱和查询参数按需处理；
- 输入校验：防止任意 URL、SQL 或路径访问；
- 审计记录：记录谁在何时用什么参数访问了什么数据；
- 资源限制：限制时间范围、返回条数和执行时长。
Skill 中的安全提醒是辅助，真正的权限必须由工具和服务端强制执行。
可直接复制的诊断模板
## 有证据的 SEO/GEO 诊断
- 目标：
- 站点范围：
- 时间范围：
- 工具与版本：
- 规则版本：
### 数据源
| 数据源 | 查询范围 | 状态 | 限制 |
|---|---|---|---|
| | | 成功 / 失败 / 数据不足 | |
### 发现
| issueId | ruleId | 状态 | 证据 | 影响 | 建议 |
|---|---|---|---|---|---|
| | | | | | |
### 未知项
-
### 待批准动作
- [ ]
### 复核
- 复核条件：
- 复核日期：
- 成功标准：本篇行动清单
- 为每个数据源写清口径和限制；
- 通过工具发现获取真实能力，不猜测接口；
- 对字段、时间、站点和权限做校验；
- 保存原始证据及工具版本；
- 分开输出事实、推断和建议；
- 将数据不足作为正式结果；
- 线上写操作必须另设审批。
最后更新于