当网站规模大、更新快、重复 URL 多，或者存在大量参数路径时，抓取预算仍然会影响 AI 可见度。AI 答案需要可检索的证据。如果解释产品、对比、价格、政策的页面很少被抓、被 robots 阻挡、被 canonical 到别处，或藏在弱内链后面，答案系统就更难把这些页面当作来源。
核心要点
- 抓取预算主要影响大型、频繁更新、重复路径多的网站。
- 写 AI 可见度内容前，先看日志、可索引性和重要证据页是否被抓。
- 报告里要分开看 Googlebot、OAI-SearchBot、Claude-SearchBot 和 PerplexityBot。
- 大规模新增内容前，先处理 crawl trap、状态码浪费、canonical 冲突和过期 sitemap。
什么时候抓取预算会影响 AI 可见度？
小型静态站通常不会首先卡在抓取预算上。但 marketplace、商品目录、SaaS 文档库、国际化网站很容易遇到这个问题。Google 把 crawl budget 管理主要放在大型网站或频繁变化的网站场景里（见 Google crawl budget guide）。AI 可见度的额外要求是：答案系统也需要能发现、抓取并信任公开证据。
预警信号不是简单的“Google 抓少了”。更值得看的是：重要证据页在日志里几乎没出现；AI 答案总是错过新页面；crawler 把时间花在筛选、参数、旧 PDF、站内搜索页上，而产品页、对比页和指南页很安静。
| 信号 | 检查什么 | 为什么影响 AI 可见度 |
|---|---|---|
| 证据页抓取低 | 按 URL 组看服务器日志。 | 重要页面可能进不了答案来源池。 |
| 参数 URL 抓取高 | 筛选导航和内链规则。 | crawler 请求被近重复页面消耗。 |
| canonical 冲突 | canonical 目标和 sitemap URL 是否一致。 | 你优化的页面未必是被索引的页面。 |
| 来源页被阻挡 | robots.txt 和 noindex。 | 被挡页面很难稳定成为 citation source。 |
按 bot 画访问地图，不要凭感觉判断
AI 相关 crawler 的职责不同。OpenAI 文档区分了用于搜索相关抓取的 OAI-SearchBot 和用于训练的 GPTBot；Anthropic 说明了 Claude-SearchBot；Perplexity 建议允许 PerplexityBot 以便出现在搜索结果里。日志和 robots 规则都应该逐个 user agent 看，而不是写一个笼统的“AI bots”。
这很重要，因为一个网站可以选择不允许训练抓取，但仍允许搜索来源抓取；也可能误挡了原本能带来答案引用的 crawler。Google 也提醒，robots.txt 主要用于控制抓取流量，不是让已知页面彻底不出现在搜索里的可靠方式（见 Google robots.txt introduction）。
| Crawler / system | 检查点 | 决策 |
|---|---|---|
| Googlebot | 能否抓到证据页和必要资源？ | 重要公开页面保持可抓取、可内链发现。 |
| OAI-SearchBot | 是否按策略允许搜索相关访问？ | 对照 OpenAI crawler documentation 检查。 |
| Claude-SearchBot | 是否有意允许或阻止搜索索引？ | 改规则前先看 Anthropic crawler guidance。 |
| PerplexityBot | robots.txt 和 WAF 行为是否一致？ | 以 Perplexity crawler docs 为基线。 |
新增文章前，先找到抓取浪费
抓取浪费就是 crawler 反复抓取却不能增强公开证据集合的路径：排序参数、筛选组合、旧活动 URL、薄 tag 页、空搜索页、重复商品变体。对 AI 可见度来说，它的问题不只是索引膨胀，而是新鲜、有用的证据页可能被更晚发现、更少刷新。
日志要按 URL pattern 分组，不要人工看几千行。再把抓取量和业务价值对齐：产品页、对比页、帮助文档、品类解释、政策页、数据丰富的教程，应该得到足够抓取关注。
| 浪费模式 | 日志症状 | 修复 |
|---|---|---|
| 筛选爆炸 | 大量 URL 只差筛选顺序或排序。 | 谨慎收紧内链、canonical 和 robots 规则。 |
| XML sitemap 过期 | 包含重定向、noindex 或低价值 URL。 | 围绕 canonical、可索引、重要证据页重建 sitemap。 |
| Soft 404 / 薄页 | crawler 反复访问几乎没有唯一内容的页面。 | 从发现路径移除或合并。 |
| 旧活动 URL | 过期 landing page 仍有抓取。 | 重定向、canonical 或从活跃模板移除链接。 |
robots、sitemap、canonical 和状态码要一起看
单个技术信号很少能独立解决问题。robots.txt 控制抓取，noindex 要 crawler 能看到页面后才控制索引，canonical 用来合并重复，状态码告诉系统 URL 是否还可用。混用不当，会让需要确认信号的 crawler 看不到页面。
例如，被 robots.txt 阻挡的 noindex 页面，可能无法被重新抓取来确认 noindex。Google 因此把 noindex 和 robots.txt 分开说明（见 Google noindex documentation）。重复页组也一样，canonical 应指向证据最完整的版本，而不是薄弱或过期页面（见 Google canonical guidance）。
| 控制项 | 适合用法 | 风险 |
|---|---|---|
| robots.txt | 降低低价值路径抓取。 | 误挡证据页，或挡住需要确认 noindex 的页面。 |
| XML sitemap | 暴露 canonical、重要、近期更新的 URL。 | 提交重定向、被挡或重复 URL。 |
| rel=canonical | 把近重复页合并到最佳来源页。 | 全部指向缺少证据的薄页面。 |
| 状态码 | 明确使用 200、301、404、410。 | Soft 404 和跳转链浪费抓取。 |
改爬虫规则前先看日志
编辑 robots.txt 前，先确认真实情况。至少拉 30 天服务器日志，按 user agent 和 URL pattern 分组，再和你希望被引用的页面对比。如果拿不到日志，可以用 crawl stats、服务器分析和 CDN 日志做替代，但结论要标弱证据。
还要看 policy 和行为是否不一致。robots.txt 允许了 crawler，但 WAF 把它拦了，文件看起来没问题，实际仍然失败。浏览器访问是 200，但 bot 访问是 403，内容团队再怎么改正文也不会提升 citation eligibility。
- 导出 Googlebot 和关键 AI user agent 的日志。
- 把 URL 分成证据页、重复路径、参数、媒体和错误。
- 把抓取命中与 sitemap 和近期更新文章对比。
- 检查 3xx 链、4xx 峰值、5xx 错误和 bot-specific 403。
- 小批量上线 crawler 规则，并记录日期用于后续复测。
从抓取到引用的工作流
顺序很简单：先确认页面能被抓，再确认它应该被索引或作为来源保留，再确认答案文字可见，最后检查 AI 答案是否引用它。顺序不能反。如果页面被挡、太薄或 canonical 到别处，更好的段落也解决不了来源问题。
| 步骤 | 问题 | 通过标准 |
|---|---|---|
| Fetch | 目标 crawler 能访问 URL 吗？ | 200 响应、没有误挡、正文在 HTML 中可见。 |
| Indexability | 搜索系统能把 URL 保留为来源吗？ | 自 canonical 或正确 canonical，没有误 noindex。 |
| Evidence | 页面是否清楚回答 Prompt？ | 短答案、表格、证明、日期和 caveat。 |
| Internal discovery | crawler 能从相关页面发现它吗？ | 来自 hub、文章或产品页的语义内链。 |
| Citation recheck | 答案是否引用或使用了页面？ | 固定 Prompt 集里出现自有引用或提及状态改善。 |
常见问题
抓取预算会影响所有网站吗？
不会。它主要影响大型、更新快、重复重或技术混乱的网站。小站通常应先修内容清晰度和内链。
为了省抓取预算，要不要屏蔽 AI crawler？
只有当这就是你的策略目标时才做。屏蔽搜索相关 crawler 可能降低在对应答案系统里的可见性，所以训练 opt-out 和搜索来源访问要分开。
Google 有排名的页面，AI 引用也一定好吗？
不一定。排名、检索、引用、推荐相关但不相同。页面仍然需要清楚答案块和可检索证据。
日志里第一组应该看什么？
先看重要证据页：产品、对比、政策、文档和教程 URL。再对比高抓取但低价值的路径。
内容声明
本文于 2026 年 6 月 26 日复核，参考 Google Search Central 关于 crawling、robots.txt、noindex、canonical 和 crawl budget 的文档，以及 OpenAI、Anthropic、Perplexity 的公开 crawler 文档。大范围改规则前，请先在低风险 URL 组测试。