AI搜索排名跟踪系统搭建指南：从可见性指标到巡检实践

Setting up AI search rank tracking easily 这个需求看起来只是把传统 SEO 的排名跟踪从搜索引擎搬到 AI 搜索，真正动手后会发现，采集对象、指标口径和存储模型全都得重新设计。传统搜索返回的是十条蓝色链接，站点可以明确知道自己排在第几位；AI 搜索返回的是一段模型综合生成的回答，它可能引用十个来源，也可能只给一个直接结论，你的品牌或产品有没有进入这一段回答，才是今天更需要关注的问题。

这篇文章要做的，不是套用某个 SEO 工具的按钮，而是从工程角度搭一套可以日常巡检的 AI 搜索可见度跟踪系统。你会得到一套清晰的数据模型、一个可以在本地跑通的最小闭环、一个能接入真实 AI 搜索页面的采集器结构、一套定时报警机制，以及后续排查问题时的检查顺序。

AI 搜索的形态还在快速变化，包括通用问答型搜索、浏览器内置 AI 搜索、电商平台内部的 AI 导购与搜索结果。比如近期《leaps: an llm-empowered adaptive plugin in taobao ai search》这类工作也说明，AI 搜索已经不只是搜索引擎的事，业务系统内部同样在出现“由模型组织搜索结果”的场景。因此这篇文章讲的方法，尽量不做成某个站点的专用抓取脚本，而是做成一个可以替换目标源、可以扩展指标的自建巡检系统。

1. AI 搜索里的“排名”，和传统搜索结果里的排名不是一回事

1.1 AI 搜索的结果形态决定了指标口径

传统 SEO 排名跟踪的核心指标很直接：关键词、URL、排名位置、变化趋势。AI 搜索结果没有这个结构。

当用户向 AI 搜索提出一个问题，模型会先检索候选内容，再对这些内容进行摘要、综合和重写。最后用户看到的内容可以拆成几层：

• 模型直接生成的文字，通常是一段连贯回答。
• 回答里可能出现的品牌名、产品名、公司名。
• 引用来源链接，有些是链接列表，有些是引用角标。
• 后续追问时的补充答案。

在这种情况下，一个站点可能被模型阅读了，但回答里完全没有出现品牌词；也可能品牌词出现了，但引用链接里放的是友商内容。这些问题如果只统计“有没有排名”，根本解释不了业务价值。

这里要建立的第一原则是：AI 搜索里值得跟踪的不是“位置”，而是“可见性”。可见性的粒度包括是否被提及、出现在哪句语境中、是否被列为引用来源、这种状态在连续时间窗内是否稳定。

1.2 从传统排名到 AI 可见度的指标迁移

先把两种场景的监测差异列出来，后面设计表结构和报警规则时都要围绕这些差异展开。

这张表解释了为什么不能照搬旧系统的表结构。旧系统记录“keyword 和 position”，新系统至少要记录“提问关键词、采集时间、当时的完整回答、从回答中抽取的提及结果、当时的引用 URL 列表”。

只有保留完整回答，后续才能在模型迭代后重新解析历史数据。如果只存一个“是否出现”的布尔值，将来想分析“以前提到过但语境是否正面”这类问题就无从下手。

1.3 什么业务场景需要这套系统

典型场景包括三类：

第一类是内容品牌监测。运营团队想知道自家网站是否被 AI 搜索推荐，例如用户问“推荐三个开源日志采集工具”，自己的项目有没有出现在回答里。

第二类是竞品对比监测。同一批问题中，持续记录 A 品牌和 B 品牌的提及情况，能得到品牌在 AI 回答中的相对存在感，不过这更多是趋势参考，不是精确的市场份额。

第三类是电商或业务内 AI 搜索监测。比如电商平台的 AI 导购推荐摘要是否包含自家商品，或者企业内部的智能助手是否会返回某个业务系统的入口。

第三类场景往往比公共 AI 搜索更容易落地，因为目标是自己的业务系统，有查询权限，也能拿到更结构化的日志。这也是把采集层做成可替换策略的原因之一。

2. 先想清楚要存什么，再写第一个爬虫

2.1 最小模块划分

一个能持续运行的 AI 排名跟踪服务，拆成模块后并不复杂，每个模块都只做一件事：

• 任务管理：负责维护要跟踪的关键词、目标对象、品牌关键词、跟踪策略。
• 采集执行：向某个 AI 搜索源发起一次查询，拿到原始回答和引用 URL。
• 解析入库：把原始回答解析成结构化字段，包括提到的品牌、上下文片段、引用链接。
• 分析报警：对比历史结果，在可见性出现波动时产生提醒。
• 调度监控：定时触发任务，记录失败原因，保存每次运行状态。

这里的边界值得注意：采集和解析必须分开。AI 搜索页面结构不稳定，采集层今天能用，明天可能因为页面改版就抓不到内容。如果解析逻辑和采集逻辑混在一起，一次页面调整会导致整个链路不可用，而且历史数据也很难重新解析。

2.2 技术选型尽量贴近学习成本

整套系统不需要一开始就上微服务，先本地一个进程跑通，再接真实数据源，最后根据数据量决定是否需要拆开部署。

推荐的学习环境组合：

生产环境要考虑的差异更大，会涉及任务队列、PostgreSQL、监控白名单、采集限流和更多的异常兜底。本文后续会在最佳实践部分说明差异，不建议直接把学习环境代码原样部署。

2.3 数据表设计：一次查询对应一次快照

数据建模的核心思路是把每次 AI 搜索当作一次不可变的快照。

先设计任务表，用来记录要监控的关键词：

CREATE TABLE search_tasks ( id INTEGER PRIMARY KEY AUTOINCREMENT, keyword TEXT NOT NULL, biz_type TEXT NOT NULL DEFAULT 'brand', engine_code TEXT NOT NULL DEFAULT 'mock_ai', enabled INTEGER NOT NULL DEFAULT 1, created_at TEXT NOT NULL DEFAULT (datetime('now')) );

engine_code很重要，它表示这个任务应该走哪套采集策略。同一个关键词可能同时存在于通用 AI 搜索、电商 AI 搜索等多个目标，未来接多少个源都可以通过这张表控制。

再设计运行结果表，每次采集产生一条记录：

CREATE TABLE search_runs ( id INTEGER PRIMARY KEY AUTOINCREMENT, task_id INTEGER NOT NULL, status TEXT NOT NULL DEFAULT 'running', full_answer TEXT, cited_urls TEXT, started_at TEXT NOT NULL, finished_at TEXT, error_code TEXT, error_message TEXT, FOREIGN KEY(task_id) REFERENCES search_tasks(id) );

full_answer保存完整回答文本，cited_urls可以保存 JSON 数组。为了便于排错，状态字段要区分 running、success、failed、timeout，不能把所有异常都归成失败。

最后是品牌提及表，负责保存真正要统计的结果：

CREATE TABLE brand_mentions ( id INTEGER PRIMARY KEY AUTOINCREMENT, run_id INTEGER NOT NULL, brand_keyword TEXT NOT NULL, is_mentioned INTEGER NOT NULL DEFAULT 0, context_snippet TEXT, matched_flag INTEGER NOT NULL DEFAULT 0, created_at TEXT NOT NULL DEFAULT (datetime('now')), FOREIGN KEY(run_id) REFERENCES search_runs(id) );

context_snippet保存命中的上下文片段，后续做语境分析和人工复盘时会非常有用。matched_flag用来记录这次命中是关键词精确命中，还是经过语义模型判断后的命中。这样可以为不同的匹配策略保留回退余地。

3. 先用 Mock 目标跑通“搜索、匹配、入库”最小闭环

3.1 没有真实目标时怎么验证分析链路

接入真实 AI 搜索页面之前，比较稳妥的办法是先写一个 Mock 采集器。它的目标是返回一段模拟回答，让后端的“匹配、入库、查询”链路先转起来。

这样做的价值在于：当后续接入真实采集源时，不会同时面临采集问题、解析问题和数据库问题，可以先分离验证。

定义统一的回答结构：

# schemas.py from dataclasses import dataclass, field @dataclass class AIAnswer: text: str = "" cited_urls: list = field(default_factory=list) raw: object = None

无论未来对接哪个 AI 搜索源，采集结果尽量统一成这个结构。raw字段可以保存原始响应，方便后续排查。

3.2 Mock 采集器

Mock 采集器通过模板返回模拟回答，这样不需要等待真实搜索引擎响应，适合先跑通本地流程。

# fetchers/mock_ai_search.py from schemas import AIAnswer class MockAISearchFetcher: def __init__(self, answer_template: str): self.answer_template = answer_template def search(self, query: str) -> AIAnswer: answer_text = self.answer_template.replace("{query}", query) return AIAnswer( text=answer_text, cited_urls=[ "https://example.com/docs/ai-search", "https://example.net/blog/keyword-research", ], )

模板里可以用{query}作为占位符，模仿模型回答中包含查询词的情况。实际项目中，Mock 数据可以来自真实产品早期的人工对话记录，这样更接近未来要处理的内容。

3.3 从回答中提取品牌提及

先采用规则型匹配，逻辑是查找品牌关键词在完整回答中的位置，并截取前后文。

# analyzer.py def find_mentions(answer_text: str, brands: list[str]) -> list[dict]: results = [] for brand in brands: idx = answer_text.lower().find(brand.lower()) is_mentioned = idx != -1 snippet = "" if idx != -1: left = max(0, idx - 60) right = min(len(answer_text), idx + len(brand) + 60) snippet = answer_text[left:right] results.append( { "brand": brand, "is_mentioned": is_mentioned, "context_snippet": snippet, "matched_flag": 1 if is_mentioned else 0, } ) return results

这里只做了文本包含判断，它的局限在中文场景下尤其明显。比如词根变化、英文大小写、简繁体、中英文品牌名混用、同义改写等都可能漏判。规则匹配是第一版，生产环境建议在规则匹配之后再接一层语义判断。

3.4 入库代码

入库时把一次运行和多个品牌结果写入两张表，是一个典型的事务操作。

# storage.py import json import sqlite3 from datetime import datetime, timezone def save_run(db_path, task_id, answer, mentions): conn = sqlite3.connect(db_path) try: now = datetime.now(timezone.utc).isoformat() cur = conn.execute( """ INSERT INTO search_runs (task_id, status, full_answer, cited_urls, started_at, finished_at) VALUES (?, ?, ?, ?, ?, ?) """, ( task_id, "success", answer.text, json.dumps(answer.cited_urls, ensure_ascii=False), now, now, ), ) run_id = cur.lastrowid for m in mentions: conn.execute( """ INSERT INTO brand_mentions (run_id, brand_keyword, is_mentioned, context_snippet, matched_flag) VALUES (?, ?, ?, ?, ?) """, ( run_id, m["brand"], 1 if m["is_mentioned"] else 0, m["context_snippet"], m["matched_flag"], ), ) conn.commit() return run_id finally: conn.close()

注意这里使用了datetime.now(timezone.utc)，避免本地时区变化导致历史时间错乱。实际展示给业务方时，再在查询层转换时区。

跑通后的验证方式很简单：连续执行几次，查看search_runs里的full_answer，确认完整回答被保存；再查看brand_mentions，确认每一条品牌记录都有对应的上下文片段。

4. 接入真实 AI 搜索页面：从 Playwright 到可替换的采集层

4.1 采集边界要先定清楚，代码才有长期价值

任何关于 AI 搜索采集的实践文章，都应该把目标站点服务条款、robots.txt、接口付费策略、反爬机制讲清楚。自建脚本不是用于绕过限制，而是用于在合规的前提下做低频品牌巡检，或者采集自己业务内部有权限访问的 AI 搜索服务。

在动手前建议先完成三项检查：

1. 查看目标站点robots.txt，确认是否存在禁止访问的路径。
2. 阅读目标站点服务条款，确认自动化查询是否被允许。
3. 确认采集频率在目标服务的可接受范围内，低频、小批量、单账号是基础要求。

如果目标站点提供官方 API，优先使用 API。API 返回的数据结构稳定，不会被页面改版影响，只是可能需要付费并且有配额限制。常见项目中也可以把多个目标源统一封装成同一个接口，这是后面所有采集器结构设计的核心。

4.2 使用 Playwright 采集页面型 AI 搜索

页面型 AI 搜索适合用浏览器自动化方式处理，因为它需要等待 JavaScript 加载，且答案经常是流式输出的。

下面代码展示的是一个通用结构，不能直接用于所有网站，因为输入框选择器、回答容器选择器会随着站点不同而变化。

# fetchers/web_ai_search.py from playwright.sync_api import sync_playwright from schemas import AIAnswer class PlaywrightAISearchFetcher: """页面型 AI 搜索采集器。 不同站点的 selector 差异很大，建议把 selector 放到配置文件中， 不要硬编码在采集逻辑里。 """ def __init__(self, engine_url, input_selector, result_selector, timeout_ms=30000): self.engine_url = engine_url self.input_selector = input_selector self.result_selector = result_selector self.timeout_ms = timeout_ms def search(self, query: str) -> AIAnswer: with sync_playwright() as p: browser = p.chromium.launch(headless=True) page = browser.new_page() page.goto(self.engine_url, wait_until="domcontentloaded") page.fill(self.input_selector, query) page.keyboard.press("Enter") try: page.wait_for_selector(self.result_selector, timeout=self.timeout_ms) except Exception: page.screenshot(path="ai_search_timeout.png", full_page=True) raise text = page.inner_text(self.result_selector) cited_urls = self._extract_urls(text) browser.close() return AIAnswer(text=text, cited_urls=cited_urls) def _extract_urls(self, text: str) -> list: # 简单 URL 提取，仅供原型使用 import re return list(set(re.findall(r"https?://[^\s)\]\"]+", text)))

这里有一个非常重要的注意点：wait_for_selector等待的是结果容器出现，并不代表 AI 回答已经流式输出结束。页面可能先出现一个“正在回答”的占位区域，实际内容还在逐字生成。更稳妥的方式是等待一个特定的结束标记，比如“参考来源”区域出现，或者判断回答区域的文本长度在一段时间内不再变化。

不要固定等待 10 秒或者 20 秒，这种方案在慢网络环境里会经常失败，在快网络环境里又会浪费大量时间。

4.3 优先使用 API 或内部网关

如果有权访问内部 AI 搜索网关，或者目标服务提供官方搜索 API，采集层要简单得多。此时不需要维护浏览器选择器，只需要处理 HTTP 客户端、超时和重试。

# fetchers/api_ai_search.py import requests from schemas import AIAnswer class ApiAISearchFetcher: def __init__(self, api_url: str, token: str): self.api_url = api_url self.token = token def search(self, query: str) -> AIAnswer: resp = requests.post( self.api_url, json={"query": query, "top_n": 10}, headers={"Authorization": f"Bearer {self.token}"}, timeout=60, ) resp.raise_for_status() data = resp.json() return AIAnswer( text=data.get("answer", ""), cited_urls=data.get("cited_urls", []), raw=data, )

上面的请求参数是示意性的，真实接口的字段名称要以目标服务文档为准。核心设计原则是，不管底层是 Playwright 还是 requests，对外都返回统一的AIAnswer。

4.4 把采集策略做成可配置替换

在主程序中可以根据任务的engine_code选择不同采集器，避免写大量if分支。

# executor.py from fetchers.mock_ai_search import MockAISearchFetcher from fetchers.web_ai_search import PlaywrightAISearchFetcher from fetchers.api_ai_search import ApiAISearchFetcher def build_fetcher(engine_code: str, config: dict): if engine_code == "mock": return MockAISearchFetcher(config["answer_template"]) if engine_code == "web": return PlaywrightAISearchFetcher( engine_url=config["engine_url"], input_selector=config["input_selector"], result_selector=config["result_selector"], ) if engine_code == "api": return ApiAISearchFetcher(config["api_url"], config["token"]) raise ValueError(f"unsupported engine_code: {engine_code}")

扩展新目标时，只需要新增一个 fetcher 类，并在工厂函数里注册。这样不会破坏已有目标源的稳定性。

5. 把一次性脚本变成定时巡检服务

5.1 定时调度与随机抖动

一旦开始运行真实 AI 搜索页面，采集频率就不能设置得太高。个人或小团队巡检，建议每个关键词每天 1 到 4 次，并且不要让任务在同一秒集中执行。

APScheduler 可以很好地胜任单机调度任务：

# main.py import datetime as dt import logging from apscheduler.schedulers.blocking import BlockingScheduler from executor import build_fetcher from storage import save_run, load_tasks from analyzer import find_mentions logging.basicConfig(level=logging.INFO) logger = logging.getLogger("ai_rank_tracker") def run_all(): tasks = load_tasks(db_path="tracker.db") for task in tasks: if not task["enabled"]: continue try: fetcher = build_fetcher(task["engine_code"], task["config"]) answer = fetcher.search(task["keyword"]) mentions = find_mentions(answer.text, task["brand_keywords"]) run_id = save_run( db_path="tracker.db", task_id=task["id"], answer=answer, mentions=mentions, ) logger.info("task %s, run %s finished", task["id"], run_id) except Exception: logger.exception("task %s failed", task["id"]) scheduler = BlockingScheduler() scheduler.add_job( run_all, trigger="cron", hour="8,20", minute=15, jitter=300, max_instances=1, ) scheduler.start()

max_instances=1防止上一次任务还没结束，下一次任务就启动。jitter=300表示在 300 秒内随机偏移执行时间，避免多个任务同时打向目标服务。

5.2 报警规则要围绕“变化”设计

比单次是否提及更有价值的是变化趋势。最常见的报警规则包括：

• 某个品牌昨天在回答里出现，今天消失了。
• 连续 3 次运行都没有出现某个品牌词。
• 某个品牌词的上下文从介绍型变成推荐其他竞品。
• 引用 URL 列表里，自家域名消失或新增。

判断“连续消失”是最容易实现的规则之一，可以在每次入库后查询最近历史记录。

def should_alert(run_id, task_id, brand_keyword): recent = get_recent_mentions(db_path, task_id, brand_keyword, limit=5) if len(recent) >= 3 and sum(r["is_mentioned"] for r in recent) == 0: return { "level": "warning", "message": f"{brand_keyword} 已经连续 {len(recent)} 次未在 AI 回答中出现", } return None

报警渠道不需要在一开始就做得很复杂，最简单的做法是发一个 Webhook JSON 到企业微信、钉钉或 Slack。如果团队没有 Webhook，也可以退而求其次，先写一个本地日志文件，连续运行几天后再决定是否要接即时通知。

5.3 用 SQL 做每日可见度报表

入库之后，应该形成稳定的统计口径。下面这个查询可以统计每个品牌每天的出现率：

SELECT date(r.finished_at) AS day, b.brand_keyword, COUNT(*) AS run_count, SUM(b.is_mentioned) AS mention_count, ROUND(100.0 * SUM(b.is_mentioned) / COUNT(*), 2) AS mention_rate FROM search_runs r JOIN brand_mentions b ON b.run_id = r.id GROUP BY day, b.brand_keyword ORDER BY day DESC, b.brand_keyword;

这里的口径先定义为“当天所有运行中有多少比例出现了该品牌”。实际业务中还需要考虑同一个关键词的同一天多次运行会因为模型版本、服务端缓存导致结果不一致，因此建议用较长的时间窗口观察趋势，而不是用单次结果下结论。

6. 常见现象排查：按这条链路逐层找根因

自建 AI 搜索跟踪系统，故障不只在代码层。目标服务页面改版、接口更新、账号状态异常都会导致采集失败。以下排查顺序值得固定下来：

1. 确认任务参数是否正确，关键词和品牌词是否拼写一致。
2. 确认采集目标是页面型还是 API 型，页面型先看回答容器是否找到。
3. 查看原始响应内容，判断是采集失败，还是页面返回了空内容。
4. 对比最近一次成功运行的数据，观察是不是目标模型输出格式变化。
5. 检查是否触发频率限制、登录要求或验证码。
6. 最后再看代码逻辑和数据解析逻辑是否有 bug。

在实际运行过程中，最常见的问题可以整理成下表：

其中“历史数据无法对比”是最难修复的坑。很多系统一开始只保存布尔值，后来想往前分析语境变化时，发现根本没有原始文本。这也是本文在第 2 章反复强调保存full_answer的原因。

一个值得推荐的排查手段是每次失败都把页面截图和当前 HTML 保存到本地目录。这样即使选择器失效，也能通过截图快速判断是页面本身出了问题，还是采集代码出了问题。

7. 让这套系统在真实环境中稳定运行

7.1 学习环境和生产环境的边界

学习环境的核心目标是验证链路，可以用 Mock 数据，可以手动运行，可以分析失败的整页截图。

生产环境则需要额外考虑以下内容：

生产环境还需要特别关注采集目标的服务波动。如果目标服务本身不稳定，任务失败会成片出现。此时不要用提高并发来解决，而是要用退避重试、错峰执行和失败队列来控制冲击。

7.2 把“自建逻辑”和“第三方能力”结合

自建全套系统没必要，也不建议。采集端如果真的没有合法稳定的获取通道，可以评估第三方搜索 API 或商业级排名跟踪服务的接口，因为这些服务通常解决了登录态、频率限制、数据格式兼容问题。

但如果只是接第三方接口然后打印结果，就把系统做得太薄了。更有价值的是把第三方数据接到自己的数据模型里，再叠加品牌词、口径定义、报警规则，这样每次业务方问“为什么这个品牌这周的出现率下降了”，都有历史数据可查。

7.3 上线前的可复用检查清单

每次新增一个 AI 搜索目标源，都应该照着下面这个清单过一遍：

• 目标站点或 API 是否有合法使用边界，是否已经确认服务条款和频率限制。
• 是否使用统一的AIAnswer结构返回结果，有没有跳过统一封装直接改调用方。
• 是否保存了完整回答原文，而不是只保存布尔值。
• 每个任务的engine_code是否能落在已有工厂函数里。
• 是否记录了开始时间、结束时间、状态、错误码。
• 品牌关键词表是否覆盖大小写、简繁体、中英文常用别名。
• 同一天多次采集是否设置了足够的采集间隔。
• 报警规则是否在高频失败时能够自动静默，避免告警风暴。
• 是否具备失败现场保存，例如截图、页面 HTML 或原始响应。
• 是否已经确认 SQLite 在当前任务数量下不会频繁触发锁等待。

7.4 下一步可以怎么扩展

当规则型匹配无法满足需求时，可以把上下文片段交给 LLM 做统一分类，比如判断“答案推荐了我们的品牌”还是“答案只是顺带提到了我们的品牌”。此时要注意的是不要把 LLM API 调用放在采集过程中，最好做成异步的批量解析任务，这样即使模型服务不稳定也不会阻塞采集链路。

更复杂的方向是接入用户真实提问日志。如果有权访问用户提问脱敏数据，可以从高频提问中反向生成需要监控的关键词列表，让追踪系统从“人工配关键词”走向“根据真实提问自动扩充”。

完成这套系统后，最先要培养的使用习惯是：不要因为某次回答里没有出现品牌就紧张，也不要因为某一次出现就判定效果很好。AI 搜索内容存在模型迭代、地域差异、随机性等多重因素，只有持续积累数据，在周、月级别观察变化，才能得出对业务有参考价值的判断。