直接结论
Cloudflare AI Search在2026年8月6日新增`discover`网站抓取模式：它可以从源URL出发，同时读取sitemap并跟随已抓取页面中的链接，适合没有sitemap或sitemap不完整、陈旧的网站。但它不是sitemap的升级替代品：`discover`受抓取深度、页面上限和缓存时间约束，忽略`lastmod`与`changefreq`，也不支持指定特定sitemap；对已维护完整sitemap的品牌官网，默认`sitemap`模式仍更可靠。
事实与背景
Cloudflare于2026年8月6日更新AI Search网站数据源文档，新增discover parse type。默认的sitemap模式只读取robots.txt声明或后台配置的XML sitemap，不跟随页面链接；discover则从源URL启动抓取任务，默认同时使用sitemap与页面链接发现候选URL。抓到的页面会被存储、转换为Markdown、切分并进入AI Search索引。
新增的是企业知识索引发现方式，不是公共搜索收录机制
Cloudflare AI Search是企业为应用、客服、经销商门户或Agent建立检索索引的基础设施。discover决定的是该索引如何找到同一Cloudflare账户下网站中的页面，不会替代Google、Bing或ChatGPT的抓取、排名和引用机制，也不会因为启用后自动增加公共AI搜索曝光。
两种模式的核心差异
| 决策项 | sitemap（默认） | discover |
|---|---|---|
| 页面发现 | 读取配置或robots.txt声明的sitemap，不跟随链接 | 默认同时读取sitemap并跟随页面链接 |
| 适用条件 | sitemap完整、更新及时 | 无sitemap，或sitemap遗漏、陈旧 |
| 更新信号 | 读取lastmod；缺失时参考changefreq | 忽略lastmod与changefreq，按max_age重新获取 |
| 覆盖边界 | 索引sitemap列出的页面 | 受limit、depth与实例对象上限共同约束 |
| 顺序控制 | 可按sitemap中的priority决定索引顺序 | 不使用sitemap优先级控制 |
| 特定sitemap | 最多可配置5个 | 不支持parse_options.specific_sitemaps |
| 切换影响 | — | 修改已有实例的parse type会触发全量重新同步 |
Discover能补漏，但不能修复失控的信息架构
discover默认最多抓取100,000个页面、链接深度默认为5，并可在配置范围内调整。它能发现sitemap漏掉但仍被页面链接连接的内容；不过，深层孤立页、只有站内搜索才能到达的页面、错误canonical或未被稳定链接的市场版本，仍可能落在抓取边界之外。若抓取达到页面上限或未完成，Cloudflare会保留此前已索引但本轮未触达的页面，而不是立即删除它们，因此“任务成功”也不等于覆盖完整。
刷新逻辑从Lastmod转向缓存年龄
sitemap模式会在lastmod晚于上次同步时间时重新抓取页面；discover则使用max_age决定缓存内容可以复用多久，默认值为86,400秒，可配置为0到604,800秒。设置为0会每次从源站获取，但会增加源站与抓取成本。价格、库存、交付范围或政策更新频繁的页面，不能只依赖站点更新时间文本，应把缓存策略、同步频率和发布触发器一并设计。
Bot准入与内容边界仍是硬门槛
同一账户域名上的抓取使用Cloudflare-AI-Search用户代理。若允许抓取外部链接或子域名并进入账户外域名，用户代理会变为Cloudflare-AI-Search-External。robots.txt拒绝的页面会记录为blocked_by_robots_txt；Cloudflare文档还说明，该爬虫声明search与ai-input用途，任一用途被Content Signals设为no时都会拒绝抓取。即使准入通过，路径过滤、正文选择器、登录保护或WAF规则仍可能让索引只得到错误页面、导航噪声或残缺正文。
对企业的影响
多语言、多市场和多CMS网站常见的问题不是“完全没有sitemap”，而是商品页、政策页、证据页或区域子目录没有被同一发现链稳定覆盖。`discover`提供了一个补漏手段，但也会把信息架构问题放大：链接图过深可能造成漏抓，未限制路径可能把登录页、参数页、筛选页或旧版本带入知识库，开启子域名或外链还可能显著扩大抓取范围。企业需要把抓取模式选择视为知识治理决策，而不是一个单独的后台开关。
智核增长的判断
稳健的优先级应是“先修sitemap与内部链接，再决定是否用discover补漏”。若官网已有完整、可审计、带真实`lastmod`的sitemap，应继续使用默认模式，并把链接发现用于覆盖审计，而不是替换权威URL清单。只有在旧CMS无法及时生成完整sitemap、迁移期间存在暂时漏项，或知识入口天然由链接图组织时，才适合启用`discover`；上线前必须预设路径白名单、页数、深度、缓存年龄和全量重建窗口。
建议行动
- 导出当前sitemap URL清单，与可抓取的站内链接图、CMS已发布记录和canonical URL做差集，确认缺口类型。
- 若sitemap完整且`lastmod`可信，保持默认`sitemap`模式；不要仅为“抓得更多”切换到`discover`。
- 若使用`discover`，先定义源URL、发现来源（sitemap、links或all）、`limit`、`depth`与`max_age`，并记录切换会触发全量同步。
- 通过include/exclude路径规则排除登录、后台、站内搜索、筛选参数、预览、草稿、归档副本与无权进入知识库的目录；注意规则区分大小写、尾部斜杠，并由exclude优先。
- 检查robots.txt与Content Signals，确保目标页面允许`Cloudflare-AI-Search`的`search`和`ai-input`用途；对子域名或外部域名另行验证`Cloudflare-AI-Search-External`。
- 为商品、政策、证据和指南建立两跳以内的可见内部链接；孤立页不能只依靠站内搜索框或JavaScript事件发现。
- 在抓取结果中抽样核对最终URL、canonical、HTTP 200、正文完整性、市场/语言版本、更新时间和来源链接，不只看已索引数量。
- 把CMS发布、AI Search同步、失败日志、抽样问答与回滚记录绑定到Update Log；达到页数上限、深度上限或全量同步未完成时不得判定上线通过。
限制条件
Cloudflare AI Search目前标注为Beta，功能、限制与接口可能继续变化。网站数据源要求源域名已接入同一Cloudflare账户。`discover`最多抓取100,000个页面，实际覆盖还受实例对象上限、抓取深度、路径过滤、robots.txt、Content Signals、WAF、页面渲染和缓存设置影响。返回“已索引”不等于检索结果完整或答案正确；启用Cloudflare AI Search也不构成Google、Bing、ChatGPT公共搜索的收录、排名、引用、流量或转化保证。