先分清两类"客人"
很多人把 robots.txt 当成省带宽的开关，看到 AI 相关的抓取就一刀切全拦。但上门的其实有两拨人：一拨是传统搜索引擎的爬虫，负责把你的页面收进索引；另一拨是各家答案引擎背后的 AI爬虫，负责在用户提问时实时检索、抽取能直接引用的片段。前者决定你"搜不搜得到",后者越来越决定你"问不问得出来"。把两类一起堵死,省下的那点流量,远抵不过在答案里消失的代价。
全拦为什么比被引用更亏
设想一个真实场景:一家做工业配件的 geo优化公司,技术文档写得很扎实,却因为担心内容被"白嫖"走,在 robots 里把 GPTBot、ClaudeBot、字节的 Bytespider 全部 disallow。结果半年后,客户在对话式助手里问"XX 规格的密封件耐温多少",跳出来的全是竞品——对方页面数据更糙,却因为对 AI爬虫 开放,被答案引擎 直接搬进了回答。你写得再好,机器进不来,内容可见性 就是零,自然也谈不上被引用。
别一刀切,按"客"和"区"分开管
真正划算的做法是分级:后台、登录、重复的筛选页可以禁,但承载答案的详情页、FAQ、参数表必须开放。具体三步:
- 先盘点 robots.txt 里到底拦了谁。常见的 AI爬虫 令牌包括 GPTBot、ClaudeBot、Claude-Web、Google-Extended、Bytespider、Bingbot。把"全站 disallow"改成"只对敏感目录 disallow"。
- 区分"训练"与"检索"。有些令牌偏训练用途,你可以策略性收紧;但负责回答的检索型爬虫,建议放行,它们正是把你送进答案区的通道。
- 给想被引用 的页面留白名单。把产品页、案例页、知识库文章放进允许清单,并确保这些是干净 HTML、响应快、URL 稳定,别再让 consent 弹窗或 JS 折叠把下半页挡住。
一个能直接抄的 robots 写法
别再写 Disallow: /。改成按目录放行:
User-agent: *
Disallow: /admin/
Disallow: /user/
Disallow: /search?
User-agent: GPTBot
Allow: /article/
Allow: /services/
Allow: /faq/
User-agent: ClaudeBot
Allow: /article/
Allow: /services/注意:不同厂家的令牌对"训练"和"检索"的边界并不统一,上面只是示意方向。核心原则是——凡是你希望进入答案引擎 检索范围的页面,都要在允许列表里,且返回的是完整 HTML,而不是需要点击才展开的壳。
三个容易踩的反向坑
- 只拦了别人,没拦自己。有的站把 Bingbot 也限了速,结果 Copilot 取不到你的内容;而 Bing 恰恰是国内外答案产品的重要来源,等于自断一臂。
- 前端藏内容,后端也藏。即使用了干净的 robots,却把关键参数、价格、认证都塞进图片或折叠区,AI爬虫 抓到的是空壳,内容可见性 依旧上不去。
- 更新了不通知。改完 robots 后没重新提交 sitemap,也没在站长平台请求抓取,新放开的区域要等引擎自己发现,少则几天多则几周。
把"被看见"当成一项指标
建议给团队设一个最小看板:每周统计 AI爬虫 的抓取次数、被收录的答案页数量、以及这些页带来的对话入口流量。当"可被引用"从口号变成可观测的数字,你才知道哪次松绑真正起了作用。多数企业的内容其实不缺质量,缺的是让机器进得来、读得懂、搬得走的那道门。
确认松绑到底生没生效也很直接:在 Bing Webmaster 的 URL 检查里输入刚放开的页面,看是否已被抓取且允许收录;同时翻一下服务器访问日志,看对应 AI爬虫 的 200 响应占比有没有回升。如果明明放行了却仍零抓取,优先排查页面是不是被 JS 包裹、或 canonical 指向了空页,而不是回过头再去加一道锁。
一句话收束
门可以上锁,但得知道锁的是哪扇、放的是谁。把答案区敞开给真正来取答案的客人,你的专业才不会被困在自己的服务器里。