Em resumo: Em 15 de setembro de 2026, a Cloudflare anunciou Disallow AI Training e novos defaults recomendados que tratam o tráfego Search, Training e Agent em separado. Essa atualização junta-se ao Precursor (deteção comportamental ao nível da sessão, lançado em julho) e à stack habitual de Managed Challenges / Turnstile. Se os teus scrapes ou monitores travaram este mês, não estás a imaginar.
O job ainda acaba? É a única pergunta que importa para a maior parte das equipas de dados. A Piloterr já corre este tipo de recolha com WebUnlocker e os outros produtos website.
O que a Cloudflare entregou de facto em setembro
O anúncio datado é a atualização de 15 de setembro de Bot Management / AI Crawl Control, coberta no post do blog da Cloudflare e no comunicado de imprensa.
O que publicaram:
- Uma nova definição Disallow AI Training para um site recusar treino e manter-se na pesquisa (para crawlers que a Cloudflare classifica como Accountable).
- Significado mais claro de Block e Block on pages with ads: essas ações passam a aplicar-se também a crawlers de uso misto como Googlebot, Bingbot e Applebot. Se só queres parar o treino e manter a pesquisa, usa Disallow AI Training em vez de Block.
- Depreciação do interruptor grosseiro Block AI Bots a favor de controlos separados de Search, Training e Agent.
- Bot Preference Sync substitui Managed Robots.txt.
- Para domínios novos onboardados a partir dessa data, presets recomendados em sites com publicidade: Search permitido, Training em Disallow AI Training, Agents bloqueados em páginas com anúncios. O changelog de julho já tinha antecipado esses defaults.
As zones existentes foram migradas conforme as definições anteriores. Muitos operadores mesmo assim mexeram nas opções à mão depois do ciclo de notícias. Em qualquer caso, mais domínios passam a classificar por omissão fetchers de chat, agentes de browser e crawlers estilo treino como indesejados.
Isto é uma mudança de produto oficial. Em paralelo, o que muitos collectors observam no browser é a stack antiga de challenges a ficar mais rígida na prática porque mais zones ligam funcionalidades.
Porque jobs que passavam agora falham
O próprio changelog da Cloudflare e a doc do Precursor descrevem uma mudança que começou mais cedo no verão e continua a chegar às zones dos clientes: deteção ao longo de toda a sessão, não um único portão à entrada.
O Precursor injeta JavaScript no cliente, recolhe sinais comportamentais ao longo do tempo e atualiza o estado da sessão no cookie cf_clearance. A Cloudflare indica que o clearance pode ser reduzido ou invalidado a meio da sessão, e que challenges adicionais podem disparar depois de um visitante já ter «passado» uma vez. Um refresh da página não apaga essa assinatura de sessão como fazia um CAPTCHA de um só tiro.
Assim, um monitor que parece humano no primeiro fetch HTML ainda pode levar um challenge no terceiro hop de paginação. Um scraper de preços que passa um interstitial e depois martela URLs de produto em ciclo apertado começa a parecer tráfego Agent sob a nova taxonomia Search / Training / Agent.
Nada disso exige seres um crawler de IA com nome. Os donos de sites ligam controlos Agent e Training porque viram os defaults de setembro. O teu job legítimo de enrichment B2B cai no mesmo balde automatizado, a menos que o publisher tenha aberto uma exceção.
«O HTTP parece bem» mas não estás na página real
É aqui que os pipelines se calam pelo motivo errado.
A Cloudflare documenta que uma Challenge Page interstitial completa define o header de resposta cf-mitigated: challenge, serve content-type: text/html e (em Managed Challenge / Under Attack Mode) devolve um 403 com HTML de challenge em vez do teu payload de produto. Ver Detect a Challenge Page response e os tipos de páginas de erro.
No terreno, as equipas ainda dizem «HTTP 200 mas preso num challenge». Muitas vezes falam de uma falha mais suave do que o interstitial documentado.
Alguns collectors só olham para códigos de estado e tratam qualquer corpo HTML como sucesso. HTML de challenge continua a ser HTML. Se o teu check é status < 400, podes gravar «Checking your browser…» como um preço.
As JavaScript Detections e o Precursor são outra coisa outra vez: a Cloudflare injeta-as em respostas HTML sem pausar o visitante como um interstitial. Recebes um 200 que parece real enquanto o edge continua a pontuar a sessão, e depois dispara um challenge ou baixa o bot score. Um Turnstile embutido num formulário que já devolveu 200 comporta-se da mesma forma do ponto de vista do operador. A página carrega. A ação protegida não termina até o widget validar.
Os Managed Challenges continuam adaptativos. Muitos humanos veem uma espera curta não interativa; o tráfego que parece automatizado é pedido a interagir. Esse comportamento está na doc de Challenge Pages, não numa release note só de setembro. Setembro empurrou mais políticas para o tráfego Agent e Training. A maquinaria de challenge é o que essas políticas chamam.
O que os operadores devem esperar até ao outono
Nem todas as zones mudaram no mesmo dia. Ainda assim, se corres collectors contra propriedades Cloudflare, prepara-te para mais Managed Challenges interativos quando a fingerprint e o comportamento se desviam, e para um clearance que não dura o job inteiro quando o Precursor está em Maximize Security ou a sessão deriva.
As falhas soft continuam comuns: respostas que parecem bem até olhares para cf-mitigated, o comprimento do body, ou se o payload tem de facto os campos que extrais. Sites com anúncios que adotaram os novos presets de onboarding vão tratar como indesejado mais do que a Cloudflare chama tráfego Agent. Stacks caseiras que «resolveram a Cloudflare» em 2024 ou início de 2025 muitas vezes precisam de outro ciclo de manutenção. O scoring de sessão e os defaults de Agent mudam o modo de falha mais depressa do que tweaks de fingerprint TLS sozinhos conseguem acompanhar.
Se és tu quem opera os collectors, orçamenta retries que ainda devolvem HTML de challenge, e validação que olha para o conteúdo em vez de só para o status.
Se o pipeline trava na Cloudflare
A maior parte das equipas com quem falamos quer os dados fora, não um segundo projeto anti-bot a tempo inteiro. A Piloterr já corre collectors contra alvos protegidos pela Cloudflare com Website WebUnlocker (domínios em allowlist, modo HTTP) e Website Rendering quando a própria página precisa de um browser real. Para escolher a ferramenta: Crawler vs Rendering vs WebUnlocker.
As mudanças da Cloudflare de setembro são reais. Absorver este tipo de viragem de vendor faz parte do que fazemos para que o teu roadmap de produto não tenha de o fazer.
Precisas de rever um domínio após os defaults de meados de setembro? Começa por Website Rendering quando é preciso um browser real, ou pela doc da API WebUnlocker para alvos HTTP em allowlist. Abre uma conversa a partir do site se quiseres que digamos se o alvo está no scope e que taxa de sucesso esperar.
