一份 90 天计划：把 AI 爬虫变成客户
作者： Zakaria Reziki
Growli 首席执行官 · 2026年10月1日 · 7 分钟阅读
在 Zakaria Reziki 制定的编辑标准下借助 AI 撰写，并在通过来源与质量的自动检查后发布。
把 AI 爬虫变成客户是一个有先后顺序的流程，而不是一次性的修复：先确认究竟是谁在抓取你、它们能看到什么，再修复阻挡它们的结构和访问问题，然后构建真正能赢得引用的具体、可信的内容——按这个顺序，大约用时 90 天。下面的每个阶段都链接到本站上一篇专门的深度文章，详细讲解该如何完成那一步；这个页面则是把它们按正确顺序串联起来的地图。
这里没有任何一步从第一天起就需要特殊工具或技术团队——尤其是第一阶段，任何企业主都可以靠自己的服务器日志和一个网页浏览器独立完成。
第 1–2 周：先弄清楚什么是真的
在改动任何东西之前，先确立真实的事实。检查你的服务器日志中声称来自 AI 爬虫的访问，然后通过将 IP 地址与 OpenAI、Anthropic 和 Perplexity 各自维护的真实公开列表进行比对，来验证这些访问是否真实——完整的验证步骤在这里——因为仅凭日志中的一个名字什么都证明不了。
与此同时，检查这些爬虫在技术上究竟能在你的关键页面上看到什么。查看你页面的原始源代码，确认你的核心事实——服务项目、价格、位置——出现在文本本身中，而不只是出现在 JavaScript 运行之后浏览器最终呈现的画面里。
为什么是这个顺序
每个阶段都依赖于前一个阶段
先修复再审计是在浪费精力
如果不先确认究竟哪里坏了，你就无从知道该修复什么。
先做内容再修复访问是在浪费精力
在一个读不懂的页面上写得再好，依然不会被读到。
过早衡量成效看起来会像是失败
在评判结果之前，给结构性修复留出被重新抓取的时间。
第 3–6 周：修复访问和结构
手握真实的事实之后，去修复那些真正坏掉的地方。按照robots.txt 决策框架逐一梳理——三个问题，而不是一份要背下来的机器人清单——从而设定一套深思熟虑的策略，而不是沿用继承下来的默认设置。
然后处理第一阶段暴露出来的技术缺口：把关键事实移到服务器的首次响应中，修复任何被困在只有点击才加载的手风琴折叠栏或标签页里的内容，并查阅完整的技术清单，找出任何其他挡在你的内容和一个不能运行 JavaScript 的爬虫之间的障碍。如果你的部分内容在登录或付费墙之后，慎重决定哪些内容该保持开放，而不是任由默认设置决定。
第 7–10 周：构建真正能赢得引用的内容
可读不等于值得被引用。这一阶段关注的是被抓取和被引用之间的差距：用具体、可核实的陈述取代笼统的措辞，确保你企业的身份和资质被清楚地表述出来，并检查是否有独立来源——评论、目录、外部提及——佐证了你自己网站所说的内容。
这也是一个适合对特定爬虫"屏蔽"与"允许"之间真正的利弊权衡做出清醒决定的时刻，现在的决定应基于关于你自己网站的真实数据，而不是任何一个方向上笼统的恐惧。
第 11–12 周：衡量成效，设定现实的预期
通过检查实际发生了什么变化来闭环。重新审视你的服务器日志，查找真实（已验证）的爬虫访问，并定期测试 AI 助手现在是否会在对你重要的搜索中提到你的企业。
让你的预期立足于真实流量数字实际呈现的样子——Vercel 测得 AI 爬虫的流量只是 Googlebot 的一小部分，Cloudflare 发现其中大部分用于训练，而不是给你带来特定的访客（完整的拆解在这里）。这里的进展更接近缓慢的复利积累，而不是一夜爆发，这是正常现象，不是失败的迹象。
开始之前需要放下的一个迷思
这份计划中的任何一步都不应该由害怕失去 Google 排名的恐惧来驱动。Google 自己的文档明确指出，其 AI 训练控制机制 Google-Extended "不会影响网站在 Google 搜索中的收录情况，也不会被用作排名信号"——而其他每一个主要运营商也都以同样的方式，把训练与搜索可见性区分开来。这份计划中的每一个决定，都应该基于它自身的考量来做，而不是出于对排名的焦虑。
完整流程
90 天，四个阶段
第 1–2 周：审计
核实究竟是谁在抓取你，以及它们在技术上能看到什么。
第 3–6 周：修复访问
robots.txt 策略、技术可读性、付费墙相关决定。
第 7–10 周：构建可引用性
具体、可信、有佐证的内容，才能赢得提及。
第 11–12 周：衡量成效
检查真实的爬虫访问和实际的 AI 助手提及情况。
对一种真实的企业来说，这会是什么样子
设想一家家族经营的兽医诊所正在执行这份计划。在第 1–2 周，诊所老板检查了她的服务器日志，发现少数几个声称是 GPTBot 的请求，并通过将 IP 地址与 OpenAI 的公开列表比对，确认其中两个是真实的——其余的则是无关的流量，只是碰巧使用了同一个名字。
在第 3–6 周，她发现自己的"服务项目"页面通过一套 JavaScript 标签页系统加载治疗项目列表，这对不渲染的爬虫来说是不可见的，于是让她的网站开发者把这份列表移到页面初始的 HTML 中。她还写了一份简单、经过深思熟虑的 robots.txt 策略：大范围允许主流爬虫，因为她网站上没有任何内容设有付费墙，而被发现则有诸多好处。
在第 7–10 周，她重写了"关于我们"页面，把"富有同情心、优质的宠物护理"替换为具体、可核实的事实：诊所诊治哪些动物、在这个社区经营了多久、以及她自己的兽医资质——这正是助手真正能够引用的那种具体陈述。到第 11–12 周，她开始定期亲自向几个 AI 助手询问它们对她所在地区宠物护理的看法，几个月下来，她开始看到自己的诊所被提及在以前从未出现过的地方。
FAQ
顺序比精确的时间安排更重要。先审计再修复，先修复再做内容工作，可以避免把精力浪费在改善那些爬虫还接触不到、或者无法验证它是否真的访问过的内容上。
审计阶段、访问和结构阶段的大部分，以及整个内容阶段，企业主都可以直接亲自完成。部分技术修复可以借助开发者的帮助，但没有一项需要一支庞大的团队。
确认你的关键事实出现在页面的原始源代码中（第 1–2 周）。之后的每一步都假定爬虫确实能读到你的内容——跳过这一项检查，计划的其余部分可能就建立在一个错误的假设之上。
两个信号：日志中已验证的爬虫访问随时间增加，以及更有意义的一点——当你或其他人向 AI 助手提出你的客户会问的那类问题时，你的企业真的开始出现在回答中。
并不会——把第 11–12 周看作一项持续性季度检查的起点，而不是终点线。爬虫、模型以及人们使用它们的方式都在不断变化，季度复查能让你保持最新状态，又不至于变成一份全职工作。