Copilot 可见度(copilot visibility)归根结底取决于 Bing:微软的文档写明,Copilot 搜索网页时,会把用户的提示词改写成一个简短的查询,发给 Bing 搜索服务,再根据 Bing 返回的结果组织回答。所以想在 Microsoft Copilot 里出现,你的页面需要被 Bing 索引、保持最新、可以抓取,并且没有带上会把内容挡在 Bing AI 回答之外的 robots meta 标签;效果可以在 Bing Webmaster Tools 的 AI Performance 报告里看到。Grok 可见度(grok visibility)则是另一回事。xAI 为 Grok 记载了网页搜索和 X 搜索工具,却没有公开任何可以按名字放行或封锁的爬虫,也没有给站长的报告,所以手段都是间接的:让页面对通用抓取可读;在 Grok 倚重的目录、点评和社区上有一致的旁证;在 X 上保持事实一致;自己去测 Grok 的回答,并且只统计它真正引用的来源。
这篇文章把微软和 xAI 写明了的、没写明的分开讲,因为在这两个引擎上,大部分错误建议恰恰出在没写明的那一半。我们有第一方测量数据的地方(Grok,覆盖 12 份行业基准),会连同注意事项一起给出;没有的地方(我们目前不测 Copilot 的回答),会直说,并只依据微软自己公布的内容。
要点
- Copilot 的网页回答经由 Bing 搜索服务获取依据。进入 Bing 索引并保持新鲜,是 Copilot 可见度的地基;IndexNow、站点地图和 Bing Webmaster Tools 是工具。
- Bing 公布过的 robots meta 规则很关键:按它 2023 年为 Bing Chat 定的规则,NOARCHIVE 会让内容完全进不了回答,NOCACHE 则只展示网址、标题和摘要。
- Bing Webmaster Tools 现在会报告你在 Copilot 和 Bing AI 摘要中的引用情况,包括把你的页面检索出来的 grounding 查询。它是预览版、是抽样,但它是主要引擎里唯一给站长的第一方 AI 引用报告。
- Grok 没有文档化的爬虫 User-Agent,所以无法按名字放行或封锁。不要在 robots.txt 里编一个。
- 在我们的基准里,12 个行业中有 11 个,Grok 每条回答附带的引用数多于 ChatGPT、Claude 和 Gemini;在好几个本地类目里,它也是最常把读者引向目录和点评网站的引擎。
为什么 Copilot 和 Grok 的可见度常被跳过
大多数 GEO 计划从 ChatGPT、Google 的 AI 功能和 Perplexity 开始,然后就停了。原因可以理解:Copilot 和 Grok 都不像 OpenAI、Anthropic、Perplexity 那样有具名的爬虫;直到最近,覆盖它们的监测工具也很少;而且和 ChatGPT 比,它们看起来都偏小众。
「小众」是这些理由里最站不住的一个。Copilot 内置在 Windows、Edge 和微软的办公应用里,对很多上班族来说,遇到工作问题时,它就是那个已经打开着的助手。Grok 内置在 X 里,而关于品牌、产品和突发事件的快速叙事正是在 X 上发酵的。如果你的买家在重度使用微软产品的组织里工作,或者你的品类在 X 上被频繁讨论,跳过其中任何一个,都会在一部分受众提问的地方留下盲区。
好消息是,这些工作大多不是新东西。Copilot 奖励的,是 Bing 一直以来都奖励的索引卫生,再加几项 AI 专属的控制;Grok 奖励的,是所有答案引擎都奖励的可读性和佐证,只是权重不同。变化的是工具箱和衡量方法。
先排哪一个
两个引擎都值得做一次基线检查,但投入多深,应当跟着你的受众走。几条经验:
- 优先 Copilot:你面向的企业客户员工日常使用微软办公应用;你的买家在工作日、在公司管理的设备上做调研;或者你已经从 Bing 获得了可观的流量。Copilot 的工作同时也会回报在 Bing 搜索本身,很少白做。
- 优先 Grok:你的品类在 X 上有活跃的讨论(去 X 上搜一搜你的品类和竞品就知道);你的品牌常处于快速变化的新闻里;或者你是口碑主要沉淀在点评平台上的本地或消费类商家。
- 两个都轻做:如果以上都不明显——本文里的 Bing 索引检查一天就能做完,每月抽测一次 Grok 对核心问题的回答也只要一小时。
无论怎么选,都把决定连同理由写下来。半年后有人问「为什么团队在做或不做某个引擎」时,理由比决定本身更有用。
我们能给你看什么、不能给你看什么
我们在行业基准里把 Grok 作为五个引擎之一来测,所以 Grok 部分有真实数据:2026-09-07 采集的 240 条 Grok 回答。我们目前不测 Copilot 的回答,所以 Copilot 部分只依据微软自己的文档和公告;凡是网上广泛流传、却无法在微软来源里核实的说法,我们都会标出来。
Microsoft Copilot 怎样找到并引用你的页面
微软关于 Microsoft Copilot 与 Copilot Chat 网页搜索的数据、隐私与安全的文档,把机制写得相当具体,而每一步对站长都有影响。
逐步拆解,以及每一步对你意味着什么
- Copilot 先判断要不要上网。开启网页搜索时,Copilot 会解析提示词,找出网页信息能改善回答的那些词。并不是每个提示词都会触发网页搜索;模型自己能答的、或用用户自己文件就能答的问题,可能不会。
- 它自己写一个简短的查询。微软说生成的查询和用户的提示词不同,只是受提示词启发的几个词。一个长长的口语化提问——比如「一个 40 人的团队怎样最好地自动化发票审批」——可能会变成一个更像传统搜索的短查询。这意味着短查询下的传统搜索相关性,对 Copilot 依然重要:把「发票审批自动化」讲清楚的那张页面,就是 Bing 会返回的那张。
- 查询发给 Bing。微软说发给 Bing 搜索服务的生成查询,不包含用户的完整提示词(除非很短),不包含完整文件,也不包含用户名、域名或租户 ID 等身份信息。
- Bing 从它的索引里返回结果。这是你最能施加影响的一步。Bing 没抓过的页面,或者抓的是旧版本的页面,就没法为回答提供依据。
- Copilot 组织回答。回答根据返回的信息写成,并带有引用。微软说,在 Copilot Chat 里,用户可以在引用区看到实际发给 Bing 的网页搜索查询,这些查询在对话中保留 24 小时。
两个会改变你测试方式的细节
第一,Copilot Chat 的查询透明度是一个免费的研究工具。在 Copilot Chat 里测一个问题时,打开引用区,读一读它发给 Bing 的确切查询;然后自己去 Bing 搜这些查询。如果你的页面不在这些生成查询的前排结果里,问题出在 Bing 对这个查询的相关性,而不是 Copilot 有什么特别之处。
第二,Copilot 的网页搜索是可以关掉的。微软记载了一个管理员策略「Allow web search in Copilot」,以及用户层面的「Web content」开关。在关闭了网页搜索的组织里,Copilot 回答工作问题时完全不上网,任何 GEO 都触及不到这些回答。用工作账号测试 Copilot 时,先确认网页搜索是否开启,再下结论。微软还说,生成的查询不会影响 Bing 的搜索排名,所以测试 Copilot 不会干扰你自己的 Bing 结果。
在 Copilot 里测一个问题,一步一步来
- 从问题集里挑一个问题,按客户的说法写,带上处境(公司规模、所在地、约束条件)。
- 在确认已开启网页搜索的 Copilot 里提问,保存完整回答和引用来源清单,并记下日期。
- 在 Copilot Chat 里打开引用区,复制 Copilot 生成的确切网页查询。留意它们比你的问题短得多、也更像搜索词。
- 把每个生成查询拿到 Bing 里搜,记下你最好的那张页面排在第几,以及哪些页面排在它前面。
- 对比 Copilot 引用的页面和 Bing 对这些查询的前排结果。如果两者高度重合,你的抓手是这些查询下的 Bing 相关性;如果 Copilot 引用了排得更靠后的页面,说明它在按内容挑选,你的抓手是页面本身是否清楚。
- 下个月再问同一个问题。不同轮次生成的查询可能不同,所以把见到的每个版本都留下;一组查询变体比任何单个查询都更有用。
微软写明了什么、没写明什么
| 问题 | 微软有文档吗? | 我们能说的 |
|---|---|---|
| Copilot 的网页搜索用的是 Bing 吗? | 有 | Copilot 把生成的查询发给 Bing 搜索服务,并根据结果组织回答 |
| 有没有 Copilot 专属、可以放行或封锁的爬虫? | 我们没能核实到 | 我们的爬虫参考表里没有这一项;Bing 的索引由 Bing 自己的爬虫 Bingbot 建立 |
| 能看到 Copilot 什么时候引用了我的网站吗? | 能,预览版 | Bing Webmaster Tools 的 AI Performance 报告统计你在 Copilot 和 Bing AI 摘要中的引用 |
| 能限制 Bing 的 AI 功能怎样使用我的内容吗? | 能 | Bing 为 Bing Chat 公布过 NOCACHE 和 NOARCHIVE 规则;现在如何适用,以 Bing 当前的指南为准 |
| 消费版 Copilot 和办公版完全一样吗? | 没有同等细节 | 上面的网页搜索文档覆盖的是微软商业产品里的 Microsoft Copilot 和 Copilot Chat;消费版在原理上可视为相似,细节不一定相同 |
第二行值得强调。网上流传的一些清单里有一个「Copilot bot」User-Agent。我们没能在微软公开的站长文档里核实到它,所以我们的 AI 爬虫清单里 Copilot 一栏宁可空着,也不去猜。为一个猜出来的名字写 robots.txt 规则不会起任何作用,只会让你误以为自己已经放行或封锁了什么。
怎样出现在 Microsoft Copilot 里:从 Bing 索引开始
既然 Copilot 通过 Bing 获取依据,Copilot 可见度就从 Bing 可见度开始。很多网站为 Google 优化了好几年,却从没看过 Bing 眼里的自己是什么样。从这里做起。
第 1 步:在 Bing Webmaster Tools 里验证网站
验证所有权,提交 XML 站点地图,读一读抓取和索引报告。重点找三样东西:你在意却没被索引的页面、被索引的是旧版本的页面,以及抓取错误或拦截。
第 2 步:确认 Bingbot 被放行,并且能渲染页面
检查 robots.txt 里有没有明确或通过宽泛的 User-agent: * 禁止规则拦住 Bingbot 的条目。检查 CDN 或机器人管理规则,它们有时会对 Googlebot 以外的爬虫发起验证。然后检查渲染:如果关键内容只有在客户端脚本运行后才出现,就测一测 Bing 的爬虫实际拿到了什么。JavaScript 渲染与 AI 指南讲了具体检查方法;经验法则是:你希望被引用的事实,应当出现在服务器发出的 HTML 里。
第 3 步:用 IndexNow 告诉 Bing 页面变了
IndexNow 是一个协议,用来主动告诉参与的搜索引擎某个网址变了,而不是等它们重新抓取。Bing 自己在 AI Performance 的发布文章里,推荐用它让信息在搜索和 AI 体验中保持新鲜。IndexNow 文档写明了机制:生成一个 8 到 128 位十六进制字符的密钥,以文本文件形式放在站点根目录,然后提交变更的网址——可以一次一个,也可以每次 POST 最多 10,000 个。提交的网址会共享给所有其他参与引擎。IndexNow 常见问题列出的参与方是 Amazon、Bing、Naver、Seznam.cz、Yandex 和 Yep;Google 不在其中,所以 IndexNow 是对你 Google 那一套的补充,而不是替代。
# 1. Host your key at the site root (the key is your own hex string)
https://www.example.com/0f3c9a7e5b2d4c18a6e7.txt -> file contents: 0f3c9a7e5b2d4c18a6e7
# 2a. One changed URL
GET https://api.indexnow.org/indexnow?url=https://www.example.com/pricing/&key=0f3c9a7e5b2d4c18a6e7
# 2b. A batch of changed URLs
POST https://api.indexnow.org/indexnow
Content-Type: application/json; charset=utf-8
{
"host": "www.example.com",
"key": "0f3c9a7e5b2d4c18a6e7",
"keyLocation": "https://www.example.com/0f3c9a7e5b2d4c18a6e7.txt",
"urlList": [
"https://www.example.com/pricing/",
"https://www.example.com/help/billing/"
]
}
多数 CMS 和 CDN 都有 IndexNow 插件或内置选项,很少需要自己写。关键在于触发时机:发布时、有实质更新时、删除时提交;不要定时重复提交没变的网址。
第 4 步:让站点地图说实话
站点地图仍然是被发现的另一半。只收规范、可索引的网址,并让 lastmod 如实:内容有实质变化时才更新,而不是每次部署都改。一个所有网址都声称「今天刚改过」的站点地图,只会教会爬虫无视这个字段。站点地图与 AI 搜索一文讲得更深入。
第 5 步:用清楚的页面去匹配短查询
因为 Copilot 发出的是简短的生成查询,赢的是把这个短查询回答清楚的那张页面。具体做法:
- 每个重要问题都有自己的页面或带清晰小标题的段落,答案放在小标题下的第一段。
- 标题和小标题里,既有口语化的说法,也有人们会敲进搜索框的词。
- 用 Bing 推荐的结构呈现事实——按 Bing 在 AI Performance 发布文章里的说法,是清晰的标题、表格和 FAQ 段落。
- 用例子、数据和来源支撑观点(Bing 同样这样建议),并让文字、图片和视频对同一实体的描述保持一致。
- 本地商家要保持 Bing Places for Business 的信息最新;Bing 的发布文章专门点出了这一条。
第 6 步:控制 Copilot 怎样使用你的内容
Bing 专门为它的 AI 回答公布过 robots meta 控制项。2023 年 9 月 22 日,Bing 说明了 NOCACHE 和 NOARCHIVE 在 Bing Chat 中的作用——Bing Chat 就是后来的 Copilot。
| 页面上的标签 | 在 Bing Chat 回答中(2023 年规则) | 在 Bing 搜索结果中 | 适用情形 |
|---|---|---|---|
| 两个都不带 | 可能被纳入回答 | 正常出现 | 希望页面被使用和引用(多数营销和帮助内容的默认状态) |
| NOCACHE | 可能被纳入,但只展示网址、标题和摘要 | 仍然出现 | 希望被提到,但限制展示的文字量 |
| NOARCHIVE | 不纳入回答,也不在回答中链接 | 仍然出现 | 希望留在搜索里,但不进 AI 回答 |
| 两个都带 | 按 NOCACHE 处理 | 仍然出现 | 很少是本意;查一查旧的 NOARCHIVE 是不是本该是 NOCACHE |
第 7 步:审计你已有的 NOARCHIVE 和 NOCACHE
很多网站带着 noarchive,那是很久以前为了「搜索结果里的缓存快照」做的决定,和 AI 毫无关系。按 Bing 为 Bing Chat 定的规则,这个标签会让页面完全进不了 AI 回答。在模板和 HTTP 头里搜一遍 noarchive 和 nocache——robots meta 标签和 X-Robots-Tag 头都要查——确认每一处都是有意为之。meta robots 与 X-Robots-Tag 指南讲了这些指令写在哪里、怎样叠加。
这些规则有多新,要打个问号
这些规则是 2023 年为 Bing Chat 公布的。此后微软给 Copilot 改了名、扩展了功能,也有第三方报道说 Bing 站长指南更新后覆盖了 Copilot。我们没能直接读到当前的指南页面来核实细节,所以请把上表当作我们能核实的 Bing 最新规则;在重要页面上改标签之前,先看一眼 Bing 当前的站长指南。
用 Bing Webmaster Tools 的 AI Performance 衡量 Copilot 可见度
2026 年 2 月 10 日,Bing 在 Bing Webmaster Tools 中推出了 AI Performance 公开预览版。它报告你在 Microsoft Copilot、Bing 的 AI 生成摘要以及部分合作方集成中的引用情况。就 Copilot 可见度而言,这是主要引擎里最接近「AI 版 Search Console」的东西。
| 指标 | Bing 说它显示什么 | 怎么用 |
|---|---|---|
| 总引用数 | 你的内容在 AI 回答中作为来源被展示的次数 | Copilot 整体可见度的趋势线;比较时段,不比较单日 |
| 平均被引页面数 | 每天被引用的你站点的不同页面数 | 可见度是集中在少数页面,还是分散在很多页面? |
| Grounding 查询 | AI 检索到并在回答中引用你内容时所用的关键短语,抽样展示 | 最有用的字段:真正把人带到你页面的那些短查询 |
| 页面级引用 | 具体网址的引用次数 | 哪些页面在赢得引用,哪些重要页面一次都没有 |
| Intents(2026 年 6 月新增,预览) | 把 grounding 查询归入信息型、商业型、导航型、学习与解决、调研、创作、本地等类别 | 你是在购买类问题上被引用,还是只在「是什么」类问题上? |
| Citation Share(2026 年 6 月新增,预览) | 某个 grounding 查询下,你的引用占所有站点引用的百分比 | 在某个查询上的相对位置;不是流量份额,也不是排名 |
6 月的新增功能在 2026 年 6 月 16 日上线:Bing 开始以预览形式推出 Intents、Topics、Citation Share 和 Compare。对 Citation Share 的边界,Bing 说得很明白:它不暴露竞争对手的域名,不代表流量份额,也不给内容打质量分。把它读作「这个查询下被引用的空间里,我占了多少」,仅此而已。
每月一次的循环
- 读。导出上一周期的 grounding 查询和页面级引用,按意图和主题分组。
- 对应。给每组查询指定你网站上应当回答它的那张页面。被引用的是错的页面(比如一篇旧博客而不是当前的产品页),或者你的页面一张都没被引用,都记下来。
- 改进并推送。改好那张应当回答的页面:清楚的小标题、直接的回答、最新的事实、需要时用表格。用 IndexNow 提交网址。
- 对比。下一个周期,用 Compare 叠加上一期,看这组查询是否转到了正确的页面、引用是否增加。
读 grounding 查询报告时要找什么
第一次导出通常会让人意外。有四种情况常见到值得专门去找:
- 被引用的页面不对。一个关于价格的查询,引用的是一篇三年前顺带提过价格的博客,而不是价格页。更新或跳转那篇旧文,让价格页在第一段就回答这个查询,然后两者都用 IndexNow 提交。
- 只有「是什么」类查询找到你。Intents 显示你只在定义类问题上被引用,商业类问题上没有。说明你的科普内容在起作用,但产品页和对比页在购买类查询上没被检索到。看看这些页面的标题怎么写,以及它们到底有没有在回答一个问题。
- 一张页面扛起了全部。平均被引页面数很低,一个网址占了绝大多数。那张页面就是单点故障;为它被引用的那些子问题补建支撑页面。
- 出现你从没瞄准过的查询。Grounding 查询里冒出你不知道自己相关的话题。有些是值得单独建页的机会;有些是错配,值得写清楚,免得你因为一件自己不做的事被引用。
这份报告说明不了什么
引用不是点击,也不是访问。报告显示的是你的内容什么时候成了来源,而不是有没有人点了链接。Grounding 查询是抽样展示的,新功能也还是预览版,所以小数字会有很大噪声。而且报告只覆盖微软自己的界面。把它和你自己对关键问题的回答测量一起用,而不是用它替代。
Grok 怎样检索和引用来源
xAI 的开发者文档描述了 Grok 通过 API 可以使用的检索工具。消费版 Grok 的行为没有同等细致的文档,所以请把这一节理解为「Grok 能怎样查资料」的最佳公开证据,而不是对应用的完整描述。
两种搜索工具
Web Search 工具让 Grok 实时搜索网页、浏览页面。开发者可以用 allowed_domains 限定站点,或用 excluded_domains 排除站点,各自最多 5 个域名,且不能同时使用。X Search 工具让 Grok 在 X 上做关键词搜索、语义搜索、用户搜索和帖子串抓取,可以选择最多 20 个纳入或排除的账号,并限定日期范围。
由此有两个推论。第一,X 对 Grok 来说是一等来源,这一点其他引擎都不具备。在 X 上讨论变化很快的话题(新品发布、服务中断、争议、热点),X 上关于你品牌的说法可以直接进入 Grok 的回答。第二,基于 Grok API 构建的应用可以收窄或排除来源。某个开发者基于 Grok 做的助手,可能只看寥寥几个域名;你影响不了这一点,除非你出现在你所在领域开发者信任的那些网站上。
两种引用
xAI 的引用文档区分了两样东西:一份默认返回的、搜索过程中遇到的全部来源的完整清单,以及嵌在回答正文里的行内引用。xAI 说完整清单里的网址并不一定都在最终回答中被引用,而行内引用放在哪里由模型决定,所以并不保证每条回答都有。这一点对衡量至关重要。如果把完整清单都算作「引用」,你数的就是 Grok 扫过一眼的每张页面,某个域名看起来会比实际被引用的多得多。只数行内引用。
没写明的部分
xAI 没有公开文档化的爬虫 User-Agent。你没法在 robots.txt 里按名字放行或封锁 Grok;为一个猜出来的名字(比如一个「GrokBot」分组)写的规则,针对的可能是一个根本不存在的代理。你能控制的,是页面对通用抓取是否可读:真实的 HTML,以及不对访问公开页面的未知代理返回错误或验证的机器人管理规则。Grok 引擎页持续记录哪些有文档、哪些没有。
Grok 可见度的实际表现:我们的基准数据
我们在 12 份行业基准里把 Grok 作为五个引擎之一来测,每份 20 个买家问题,采集于 2026-09-07。合计 240 条 Grok 回答;12 个行业里,每个行业的 20 条 Grok 回答全部带有引用。
先说方法上的注意事项
在这些基准里,除 Perplexity 外,每个引擎都是以「模型 + 同一个网页搜索工具」的方式通过 API 调用的,并且只统计在回答正文里做了行内标注的来源。对 Grok 来说,这意味着回答体现的是 Grok 自己决定说什么、引用什么,但搜索结果池来自那个共用的搜索层,而不是 xAI 自己的 Web Search 或 X Search 工具。这就是为什么我们的数据里没有任何一条回答引用 X,也是为什么能搜索 X 的消费版 Grok 可能会引用不同的来源。请把下面的数字理解为 Grok 的作答行为,而不是 Grok 应用去哪里查资料的地图。
Grok 引用得比多数引擎多
12 个行业里,Grok 每条回答平均附带 9.35 到 11.7 条引用。在 12 个行业中的 11 个里,它多于 ChatGPT、Claude 和 Gemini(只有律所这一类 ChatGPT 略多),而在全部 12 个行业里都少于 Perplexity。一个引用多的引擎,对在自己话题的搜索结果里有充分曝光的网站是好消息:可以落进去的位置更多。这也意味着,被 Grok 引用一次,比被一个引用稀少的引擎引用一次,信号要弱。
Grok 倚重目录和点评网站
在本地和消费类品类里,Grok 经常把读者引向目录和点评网站,有时代替点名机构,有时与点名并存。关于奥斯汀牙科诊所和迈阿密酒店的回答,各有 10 条(共 20 条)这样做;关于餐厅的有 9 条。软件品类里一次都没有。和其他引擎在同一组问题上相比,Grok 常常是最依赖目录的那一个。
在迈阿密酒店基准里,Grok 在 20 条回答中有 10 条点名了目录或点评网站,ChatGPT 是 8 条,Claude 7 条,Perplexity 4 条,Gemini 3 条。对本地或消费类商家来说,这让目录和点评资料对 Grok 可见度的重要性超过了多数引擎:如果 Grok 把读者送去了某个点评平台,你在那里的资料实际上就是你的回答。
我们不会据此下的结论
一天的采集、每个品类 20 个问题、一个共用的搜索层。这些数字描述的是 Grok 模型在这套设置下怎样作答。它们说明不了 Grok 应用在你的品类里有多少人用、它的 X 搜索会怎样改变结果,也说明不了回答随时间怎样变化。把它们当作「去你自己的品类里查一查 Grok」的理由,而不是预测。
Grok 可见度操作手册
没有可以放行的爬虫,没有内容使用控制,也没有第一方报告,所以 Grok 可见度的工作,就是确保 Grok 无论去哪里找,都能看到关于你的准确画面。
1. 对通用抓取可读
既然 Grok 无法按名字放行,你的 User-agent: * 规则和机器人管理设置,就决定了任何没有文档的代理能抓到什么。确保公开页面(产品、价格、帮助、关于我们)返回带有重要事实的真实 HTML,并且防火墙或 CDN 不会对访问公开页面的未知代理返回 403 或验证。如果你出于安全考虑刻意拦截未知代理,要清楚这意味着在没有具名爬虫的引擎上接受可见度损失。
# There is no documented Grok crawler, so there is no Grok group to write.
# Whatever this group allows is what undocumented agents can read.
User-agent: *
Allow: /
Disallow: /account/
Disallow: /checkout/
# Named groups only for agents whose operators document them, e.g.:
User-agent: Bingbot
Allow: /
Disallow: /account/
Disallow: /checkout/
Sitemap: https://www.example.com/sitemap.xml
2. 修好目录和点评这一层
基准显示,在本地和消费类品类里 Grok 倚重目录和点评网站。把 Grok 在你的问题上引用过的平台列出来,然后让你在那里的资料完整、及时,并与官网一致:名称、类目、地址、营业时间、展示价格时的价格,以及按统一规则持续收集的真实评价。
3. 把 X 当作来源,而不只是渠道
因为 Grok 可以直接搜索 X,你在 X 上的存在就是证据的一部分。保持一个官方账号,简介与官网对你业务的描述一致;把关于新品、调价和故障的准确说明置顶;用指向自己页面的链接纠正错误信息。不要制造虚假互动,也不要用不披露身份的账号;除了平台和监管上的明显风险,这还会制造出答案引擎恰恰会打折扣的那种前后矛盾的画面。
每月按「最新」排序,在 X 上搜一次你的品牌名、产品名和客户常问的问题。记下反复出现的关于你的说法(不论对错),以及是哪些账号在说。说法错了,正确的修复是在你自己的网站上发一份清楚、带日期的说明,再用链接到它的回复回应,而不是争论。如果某个说法之所以反复出现,是因为你自己的文档写得不清楚,那就修文档——那正是 Grok 的网页搜索会在这些帖子旁边找到的来源。
4. 让事实在整个公开网络上一致
和每个引擎一样,Grok 对能佐证的事实更有把握。你的关于我们页面、公司资料、媒体报道和目录条目,应当在「你是谁、服务谁、要多少钱」上说法一致。哪里不一致,回答就会含糊其辞,或者挑了错的那个。
5. 为变化快的问题发布答案
Grok 的工具是为时效信息设计的。当你的业务发生了人们会来问的变化(新产品、调价、故障、政策调整),及时在网站上发布一份带日期的平实说明,并从 X 上链接过去。从未被新信息取代的旧信息,往往会一直流传。
6. 当 Grok 或 Copilot 与其他引擎说法不一时
被 ChatGPT 和 Gemini 点名、却在 Copilot 或 Grok 里缺席,或者反过来,都很常见。先诊断,再行动。如果 Copilot 漏了你、而以 Google 为依据的引擎有你,就对比被引页面在 Bing 和 Google 的索引情况;两个索引之间的差异是常见原因,Bing Webmaster Tools 会显示出来。如果 Grok 漏了你、而其他引擎有你,就看看 Grok 在这个问题上引用了哪些目录和点评网站;你在那里缺席或资料单薄,那就是缺口。如果 Grok 有你、其他引擎没有,先核对它说的是否准确再高兴,因为由目录带出来的回答,可能带着一份过时资料里的旧细节。
并排衡量 Copilot 与 Grok 的可见度
两个引擎需要不同的衡量方式,因为一个提供第一方数据,另一个完全不提供。
| Microsoft Copilot | Grok | |
|---|---|---|
| 第一方数据 | Bing Webmaster Tools AI Performance:引用数、被引页面、grounding 查询、意图、引用份额 | 站长没有 |
| 需要自己抽测的 | 在开启网页搜索的 Copilot 里跑你的问题集;在 Copilot Chat 里读生成的查询 | 跑你的问题集,连同来源 |
| 什么算引用 | Copilot 在回答中展示的来源 | 只算行内引用,永远不算「遇到过的全部来源」 |
| 额外要记录的维度 | 所用账号是否开启了网页搜索 | 来源来自网页还是来自 X |
| 落后时的主要抓手 | 生成查询下的 Bing 索引与相关性 | 可读性、目录资料与佐证 |
| 频率 | 每月看一次 AI Performance;重大内容改动后抽测 | 每月抽测;新品发布或突发事件前后加测 |
搭建问题集
两个引擎用同一套问题集,比较才公平:用客户的原话写买家问题,按意图分组(找服务商、比较选项、核实可信度、了解原理)。带你自己品牌名的问题不算进可见度,单独报告。针对 Grok,再加几个关于你品类近期事件的问题,因为这正是它的 X 搜索让它与其他引擎表现不同的地方。
解读结果
对每个引擎,记录你有没有被点名、有没有被引用、引用的是哪张页面,以及还引用了哪些其他域名。随时间拿同样的东西比:同样的问题、同一个引擎、每月一次。没有测过的引擎报「未测」,永远不要报成零。
Copilot 与 Grok 可见度的 30 天计划
第 1 周:访问
- 在 Bing Webmaster Tools 验证网站,提交站点地图,修好重要页面的抓取和索引错误。
- 检查 robots.txt、CDN 和机器人管理规则,找出拦截 Bingbot、或对访问公开页面的未知代理发起验证的设置。
- 在模板和响应头里搜索
noarchive和nocache,只保留有意为之的那些。
第 2 周:新鲜度
- 通过 CMS 或 CDN 接入 IndexNow,在发布、更新和删除时触发。
- 清理站点地图,让
lastmod反映真实的内容变化。 - 审计你所在品类里重要的目录和点评资料,确保准确、一致。
第 3 周:内容
- 为最重要的那些问题,确保各有一张页面把它讲清楚:小标题、直接回答的第一段、需要时用表格、附来源。
- 让你的 X 简介和置顶说明,与官网的描述和当前事实保持一致。
第 4 周:衡量
- 读 AI Performance:grounding 查询、被引页面、意图。把查询分组对应到页面。
- 在 Copilot 和 Grok 里跑你的问题集,记录点名情况、行内引用和被引页面。
- 定下每月循环:看 AI Performance、每次修改后推 IndexNow、每月跑同一套问题集。
如果你想看到各引擎在你的问题上引用了哪些域名、又不想手工抽测,可以用我们的引用来源报告,它覆盖我们测量的那些引擎。
资料来源
- Microsoft Learn,《Data, privacy, and security for web search in Microsoft Copilot and Microsoft Copilot Chat》(更新于 2026-08-18):learn.microsoft.com/en-us/microsoft-365/copilot/manage-public-web-access
- Microsoft Bing 站长博客,《Introducing AI Performance in Bing Webmaster Tools Public Preview》(2026-02-10):blogs.bing.com
- Microsoft Bing 搜索博客,《New AI Visibility Insights in Bing Webmaster Tools: Intents, Topics, Citation Share, Compare》(2026-06-16):blogs.bing.com
- Microsoft Bing 站长博客,《Announcing new options for webmasters to control usage of their content in Bing Chat》(2023-09-22):blogs.bing.com
- IndexNow 文档与常见问题:indexnow.org/documentation、indexnow.org/faq
- xAI 文档,Web Search、X Search 与 Citations:docs.x.ai/developers/tools/web-search、docs.x.ai/developers/tools/x-search、docs.x.ai/developers/tools/citations
- InsightWonder 行业基准,12 个品类 × 5 个引擎 × 20 个问题,采集于 2026-09-07;Grok 引擎页:insightwonder.com/ai-engines/grok/