AI时代产品被发现的6步清单

当朋友都注册之后，下一批用户需要自己找到你，而这件事主要发生在 Google 和 AI 助手里。Serpair 团队把自己发布后最想要的「可发现性」技术清单整理了出来，按执行顺序排列，核心思路来自 YC 的 Ankit Gupta：找第一批用户更像是一个搜索问题，而不是说服问题。

一、先让自己的名字被搜到

如果有人听到你的产品名去搜索，你应该排在第一位。很多新产品做不到，尤其是名字由常见词构成、或已被其他公司占用时。

检查方法：用隐私窗口搜产品名，再搜「名字 + 品类」；在 Google Search Console 验证站点，用 URL Inspection 确认首页已被索引；在 ChatGPT、Perplexity、Gemini 里搜你的名字，看它们认为你是什么。

修复方式：把名字和品类同时写进首页 title 和第一个 H1，「Acme：面向自由职业者的发票工具」比单独一个「Acme」好得多；站内、社交资料、发布平台、GitHub 使用完全一致的名字；在首页用 WebSite 结构化数据告诉 Google 你偏好的站点名，并可加 alternateName 作为备选。Google 官方文档明确表示，如果你想声明偏好，这个标记是「最重要的」。

二、补上 Organization 结构化数据，但别抱不切实际的期望

Organization 标记能帮助 Google 在搜索结果中「消歧」你的组织，当有其他东西和你同名时尤其重要。sameAs 属性把官方资料串起来。每个 sameAs URL 都要手动核对，一个拼错的 handle 就会把 Google 指向别人。

这里需要泼一盆冷水：结构化数据不是获得 AI 引用的捷径。Ahrefs 追踪了 1,885 个添加 JSON-LD 的页面，发现它们在 Google AI Mode 或 ChatGPT 中的引用量没有明显提升。不过这些页面本身已被大量引用，结论对全新站点说服力有限。Google 也表示其 AI 功能不需要「特殊的 schema.org 结构化数据」，结构化数据应与可见文本一致。所以：加 schema 是为了让 Google 搞清楚你是谁，真正重要的事实要写进用户看得见的正文里。

结构化数据（Schema.org）与 JSON-LD 简介

结构化数据是用一套共享词汇表（schema.org，由 Google、微软、Yahoo、Yandex 共同发起）给网页内容打标签的机制，让搜索引擎不必仅靠自然语言猜测页面含义。常见类型包括 Organization（组织）、WebSite（站点）、Product（产品）、FAQPage（常见问题）等。JSON-LD 是 Google 推荐的序列化格式，通常以 <script type="application/ld+json"> 嵌入 <head> 或 <body>，与可见文本分离，便于维护。

sameAs 是 Organization 下的关键属性，用于声明该组织在其他平台上的官方主页（如 LinkedIn、X、GitHub），帮助 Google 把这些分散身份归并到同一实体。alternateName 则用于声明实体的别名或简称。需要强调：结构化数据描述的事实必须与页面可见内容一致，否则可能被视为误导，且不会带来排名或引用收益。

三、放行 AI 爬虫

AI 助手只能引用其爬虫够得着的页面。各家都有自己的文档：

• OAI-SearchBot 驱动 ChatGPT 搜索，OpenAI 称选择退出的站点「不会出现在 ChatGPT 搜索答案中」；
• GPTBot 是 OpenAI 的训练爬虫，与搜索是分开的设置，可以屏蔽训练而保留搜索；
• PerplexityBot 负责在 Perplexity 结果中呈现和链接站点；
• Googlebot 覆盖 Google 搜索，包括 AI Overviews 和 AI Mode，Google 表示针对 Googlebot 的 robots.txt 规则就是这些功能的控制开关。

一份欢迎搜索爬虫的最小 robots.txt 应该显式允许上述 UA 并声明 sitemap。但 robots.txt 不是唯一的门：CDN 或防火墙也可能拦截。Google 把 CDN 与托管设置列为需要检查的项，Perplexity 文档则包含放行其爬虫通过 Cloudflare 和 AWS WAF 的规则。

可以用终端做一次冒烟测试，用 OpenAI 文档中的 UA 请求首页：

curl -s -o /dev/null -w "%{http_code}\n" \
  -A "Mozilla/5.0 (compatible; OAI-SearchBot/1.4; +https://openai.com/searchbot)" \
  https://acme.com/

返回 403 或挑战页说明有东西在拦机器人。部分防火墙还会校验真实 IP 段（OpenAI 和 Perplexity 都公开了），所以 200 只能算好兆头，不是证明。

robots.txt 与 UA 匹配机制

robots.txt 是放在站点根目录的纯文本文件，通过 User-agent 与 Disallow/Allow 指令告诉爬虫哪些路径可以抓取。爬虫在请求每个 URL 前会先读取该文件，并按其 UA 字符串匹配对应规则组；未匹配任何组的爬虫通常遵循 User-agent: * 的通用规则。

因此，「放行某个 AI 爬虫」的正确做法是为其 UA 单独建组并写 Allow: /，而不是只依赖通用规则——许多站点在通用组里写了 Disallow: /，会连带屏蔽未显式列出的爬虫。注意 robots.txt 只约束守规矩的爬虫，不构成访问控制；真正的拦截往往来自 CDN 或 WAF 的机器人管理规则，这也是后文要用 curl 冒烟测试的原因。

四、写一个真正回答问题的页面

可抓取不等于有用。AI 搜索工具常为一个问题发起多次相关搜索，Google 称之为「query fan-out」，然后从那些清晰回答某个具体子问题的页面中摘取段落。

做法：用用户自己的话锁定你解决的那个具体问题（去 Reddit、Hacker News、客服邮件里找他们怎么描述）；写一个页面，开头两三句就给出答案，再展开细节；重要内容保持在 HTML 文本中，不要只放在图片、视频或客户端组件里；加一段简短 FAQ，收罗人们真实追问的问题。

Query fan-out 的含义

Query fan-out 指 AI 搜索系统在回答一个用户问题时，并不只发起一次检索，而是把原问题拆解成多个相关子查询并行发出，再综合各来源的片段生成答案。例如用户问「小团队用什么发票工具」，系统可能同时检索「小团队发票工具推荐」「发票工具价格对比」「自由职业者发票软件」等。

这意味着你的页面不需要覆盖整个大主题，而应精准命中其中某个具体子问题，并在开头就给出可被摘取的答案句。页面结构清晰、小标题明确、答案前置，更容易被 fan-out 后的某次检索选中并引用。

五、出现在答案的来源里

AI 答案偏向网络已经信任的来源。Pew 的研究发现，Wikipedia、YouTube 和 Reddit 是 Google AI 摘要中被引用最多的三个来源。你买不进去，但可以诚实地出现：在相关目录和发布站列出产品，名字和一句话描述保持一致；在用户提问的社区回答真实问题，只在确实有帮助时提及产品；在平台上写对比或「如何做」类文章并链回自己的站点。

六、度量，然后重复

在 GA4 或分析工具里看 chatgpt.com、perplexity.ai、gemini.google.com 这类来源。部分 AI 访问没有 referrer，会落入直接流量，所以这个数字只是下限。在 Search Console 里盯品牌词和问题词的曝光量。每隔几周重跑同样的 prompt——SparkToro 发现 AI 工具给出同一份品牌清单的概率不到百分之一，因此要跟踪多次运行中的出现频率，而不是单次答案里的排名。

Serpair 本身提供这类追踪：监控 Google 排名以及 ChatGPT、Perplexity、Gemini 是否提到你，再转成一份简短的修复清单。

朋友帮你完成了发布，这份清单帮下一批人找到你。