---
title: "AdSense bloqueado pela Cloudflare no plano Free: o que testei e o que resolveu"
description: "O AdSense não conseguia ler o toin.app atrás da Cloudflare no plano Free, com o Bot Fight Mode desligado. Foram regras de WAF, exceções por ASN e User-Agent e dez dias de ticket. Nenhuma regra resolveu: o que resolveu foi subir pro Pro e o Super Bot Fight Mode."
published: "2026-10-26"
tags: ["cloudflare", "adsense", "seguranca"]
source: "https://marciotoledo.com/blog/cloudflare-free-adsense-bloqueado"
---

# AdSense bloqueado pela Cloudflare no plano Free: o que testei e o que resolveu

Coloquei o [TOIN.app](/blog/toin-app-ferramentas-online-gratuitas) na Cloudflare, como tenho feito com a maioria dos projetos, e fui cadastrar o site no AdSense. A tela de setup dos anúncios do Google simplesmente não carregava o site. O robô do AdSense voltava com erro, sempre.

Eu tinha conferido o painel: o Bot Fight Mode estava desligado, e nada mais ali parecia barrar bot. Pra tirar a dúvida, apontei o DNS pra outra hospedagem: o AdSense leu o site na hora. Voltei pra Cloudflare: erro de novo. O problema era a Cloudflare, mas o plano Free não mostrava nenhum evento de bloqueio.

Abri um ticket no suporte em 15 de outubro de 2026. Foram dez dias, quatro sugestões de regra diferentes e uma conclusão que eu não esperava: **nenhuma regra resolveu, o que resolveu foi pagar o plano Pro**. Este post é o caminho inteiro, pra quem cair no mesmo buraco (e eu tenho um cliente, um portal de notícias, que vai cair nele quando migrar pra Cloudflare).

## Free e Pro, rapidamente

A proteção contra bots muda de natureza entre os dois planos. No Free existe o **Bot Fight Mode**: um botão só, liga ou desliga, sem exceção e sem log detalhado. No Pro e acima ele é substituído pelo **Super Bot Fight Mode**, que separa os bots em categorias (automatizado com certeza, provavelmente automatizado, bot verificado), deixa escolher a ação de cada uma e aceita exceção por regra.

A diferença que importou aqui foi a categoria **Verified bots**: no Super Bot Fight Mode, crawlers verificados pela Cloudflare (o do AdSense entre eles) passam com _Allow_ por padrão.

## O ticket, dia a dia

**15/10: a primeira pista.** O suporte achou no Security Analytics um bloqueio real: uma requisição `POST` para `/app`, vinda da rede do Google (ASN 396982), barrada pela regra gerenciada **React - RCE - CVE-2025-55182** do Cloudflare Managed Free Ruleset. Essa regra existe pra barrar uma falha de execução remota em React Server Components, e um site estático em Astro não tinha nada pra ser explorado ali. Era um falso positivo clássico. A sugestão foi uma regra customizada com ação _Skip_:

```txt
(http.request.uri.path eq "/app" and ip.geoip.asnum eq 396982 and http.user_agent contains "Googlebot")
```

Ação _Skip_, marcando **All managed rules**. Criei, testei, e o AdSense seguiu sem carregar. Pior: o Security Events continuava vazio.

**21/10: a segunda tentativa.** O suporte olhou a zona e viu que não havia regra customizada nenhuma (eu tinha criado, visto que não funcionava, e apagado). A nova sugestão foi uma exceção dentro da própria regra gerenciada, escopada para `/app`, ASN 396982 e User-Agent contendo `AdsBot-Google` ou `Googlebot`. Criei de novo, junto com uma regra pelo ASN do Google e outra pelos User-Agents dos bots, e deixei tudo ativo pra eles acompanharem. Nada.

**21/10, mais tarde: o limite do Free.** Aqui veio a resposta mais honesta do ticket. O suporte explicou que contas Free não têm acesso ao histórico detalhado de eventos de segurança nem a filtro de log por User-Agent, então eles **não conseguiam ver a requisição bloqueada** pra saber qual camada estava barrando. A recomendação: subir temporariamente para o Pro, que libera os logs, pra capturar o bloqueio e criar a exceção certa.

**22/10: subi pro Pro.** A tela de configuração do AdSense carregou na primeira tentativa. Com o Pro ativo, o suporte enxergou no analytics das últimas 24 horas um User-Agent que eu nunca tinha visto:

```txt
Mozilla/5.0 (Linux; Android 4.0.4; Galaxy Nexus Build/IMM76B) AppleWebKit/537.36 (KHTML, like Gecko; GoogleAdSenseInfeed) Chrome/153.0.8010.52 Mobile Safari/537.36
```

E sugeriu mais uma regra de _Skip_, agora com `http.user_agent contains "GoogleAdSenseInfeed"`.

**22/10, à noite: o teste que derrubou as regras.** Desativei todas as regras customizadas. O AdSense continuou funcionando. Então as regras nunca foram a solução: era alguma coisa do plano pago. Mandei isso de volta no ticket.

**25/10: a resposta final.** O suporte confirmou: o que resolveu foi a troca de plano, não as regras. No Pro, o Super Bot Fight Mode entra no lugar do Bot Fight Mode e libera bots verificados como o do AdSense por padrão, por isso o site abriu mesmo com as minhas regras desligadas.

## O que ficou provado, e o que não

A explicação do suporte veio com um detalhe que não batia com o meu caso. Eles atribuíram o bloqueio no Free ao Bot Fight Mode, que de fato **não aceita exceção por regra nenhuma**: ele roda fora do Ruleset Engine, onde as ações _Skip_, _Bypass_ e _Allow_ não têm efeito. Só que no toin.app ele estava desligado desde o começo.

Então separo o que eu consigo provar do que não consigo:

1. **Fora da Cloudflare, o AdSense lia o site.** Na Cloudflare Free, não.
2. **No Free, nenhuma regra resolveu.** Nem a exceção na regra gerenciada, nem o _Skip_ por ASN, nem o _Skip_ por User-Agent.
3. **No Pro, o AdSense funcionou sem regra nenhuma**, com todas as minhas regras customizadas desligadas.

O que não consigo provar é **qual camada barrava o AdSense no Free**. O Free não mostra o log que diria isso, e o suporte disse com todas as letras que também não conseguia ver. O bloqueio do CVE do React existia, mas a exceção pra ele não resolveu, então ele não era o único.

Na prática, isso não muda a decisão: no Free eu esgotei as alavancas disponíveis, e no Pro o problema sumiu sem eu mexer em nada.

| | Free | Pro |
| :-- | :-- | :-- |
| Proteção de bots | Bot Fight Mode | Super Bot Fight Mode |
| Roda no Ruleset Engine | Não | Sim |
| Aceita regra de _Skip_ | Não | Sim |
| Controle de bots verificados | Não | Sim, _Allow_ por padrão |
| Log detalhado por User-Agent | Não | Sim |
| AdSense no toin.app | Bloqueado, com ou sem regra | Liberado, sem regra |
| Preço | US$ 0 | US$ 25/mês, ou US$ 20/mês no anual |

## Por que as regras não resolveram

Olhando pra trás, cada regra fazia sentido isoladamente. A primeira tratava um bloqueio que existia de verdade, no managed ruleset. A segunda era a forma mais cirúrgica de tratar o mesmo bloqueio. A terceira pegava um User-Agent que só apareceu porque o Pro liberou o log.

O problema é que todas atacavam camadas que eu **conseguia** configurar, e o bloqueio estava numa camada que eu não conseguia ver. Sem log no Free, nem eu nem o suporte tínhamos como chegar nela. É o tipo de problema em que a ferramenta de diagnóstico está atrás do mesmo paywall que a solução.

## Por que o Pro resolveu

Três coisas mudam ao mesmo tempo quando você sobe pro Pro:

1. **Entra o Super Bot Fight Mode**, que respeita a lista de bots verificados da Cloudflare. O crawler do AdSense está nela, e com **Verified bots** em _Allow_ ele passa sem regra.
2. **Os logs aparecem.** Foi só com o Pro que o User-Agent `GoogleAdSenseInfeed` ficou visível.
3. **As regras de _Skip_ ganham a opção "All Super Bot Fight Mode Rules"**, pra quando precisar de exceção fina.

A regra que tenho no toin.app, chamada "Skip Google", é esta:

```txt
(ip.src.asnum eq 15169)
```

Ação _Skip_, pulando as custom rules restantes, todas as managed rules, todas as regras do Super Bot Fight Mode, Zone Lockdown, User Agent Blocking, Browser Integrity Check, Hotlink Protection e Security Level. Nos últimos 30 dias ela casou 12,8 mil requisições, 7,2% de todo o tráfego do site. Hoje ela está desligada e o AdSense segue funcionando, o que confirma que no Pro quem resolve é o **Verified bots**, não a regra.

## Vale pagar US$ 25 por mês?

Depende de quanto o site vai render. Pra um projeto pessoal esperando aprovação do AdSense, US$ 25 por mês (US$ 240 por ano no plano anual) é caro pra uma receita que ainda não existe. Pra um portal de notícias que já vive de anúncio, é troco: um dia de AdSense fora do ar custa mais que o ano inteiro de Pro.

E tem um detalhe que pesa a favor do Pro: o crawler do AdSense não visita o site só na aprovação. Ele continua lendo as páginas pra decidir quais anúncios mostrar em cada uma. Um site que o crawler não consegue ler depois de aprovado mostra anúncio pior, ou nenhum.

## Meu plano daqui pra frente

Minha ideia inicial era esperar o AdSense aprovar, voltar pro Free e, se desse problema, religar a regra "Skip Google". O teste mostrou que esse plano B não se sustenta: regra pelo ASN do Google eu já tinha no Free, e ela não resolveu.

Então o plano ficou assim:

1. Esperar a aprovação do AdSense com o Pro ativo.
2. Se quiser economizar, testar o Free por poucos dias, olhando o relatório de erros do rastreador no AdSense.
3. Apareceu erro de rastreamento, voltar pro Pro e não insistir com regra.
4. Para o portal de notícias do cliente, migrar já no Pro. Não vale arriscar a receita de anúncio pra economizar US$ 25.

> **WARNING**
>
> Se for criar regra de _Skip_ por ASN, cuidado com o escopo. O ASN 15169 é a rede do próprio Google, mas o 396982, de onde veio o primeiro bloqueio, é a do **Google Cloud**: qualquer pessoa que alugue uma máquina lá passa a pular o seu WAF. Combine o ASN com o User-Agent, ou use o campo `cf.client.bot`, que só casa com bots verificados pela Cloudflare. Exemplo: `(cf.client.bot or (ip.src.asnum eq 15169 and http.user_agent contains "Google"))`.

> **TIP**
>
> Se o site vai viver de AdSense atrás da Cloudflare, comece no Pro, ou pelo menos teste a verificação do AdSense logo depois de apontar o DNS. Se não carregar no Free, não perca uma semana criando regra de WAF como eu perdi.

Esse é o segundo tropeço que tenho com Cloudflare que só se resolve entendendo onde cada camada roda. O primeiro foi o [trailing slash no Astro](/blog/trailing-slash-astro-cloudflare-pages), que também parecia bug e era design da plataforma.

## Resumo

**No plano Free, o AdSense pode ficar bloqueado mesmo com o Bot Fight Mode desligado, e regra de WAF nenhuma resolveu.** No Pro, o AdSense passou sem regra nenhuma.

- **No Free:** sem log detalhado, não dá pra descobrir qual camada bloqueia. Exceção por ASN, por User-Agent e na regra gerenciada não resolveram no meu caso.
- **No Pro (US$ 25/mês ou US$ 20/mês no anual):** mantenha o Super Bot Fight Mode ligado e confira se Verified bots está em _Allow_. O AdSense passa sem regra.
- **Falso positivo em managed rule** (como o do CVE do React) se trata com _Skip_, mas com escopo apertado, nunca o ASN inteiro do Google Cloud.
- **Site que vive de anúncio, já começa no Pro.** O crawler do AdSense continua visitando o site depois da aprovação.

> **NOTE**
>
> Pra ser justo com a Cloudflare: o suporte respondeu ticket de plano gratuito durante dez dias, subiu a prioridade quando pedi, e a recomendação de subir pro Pro veio como forma de enxergar o problema, não como empurrão de venda. O que incomoda é que a explicação final não fechou com o meu caso, e ficar sem saber o que bloqueava no Free é exatamente o custo de não ter log.

## Referências

- Cloudflare Docs. [Bot Fight Mode](https://developers.cloudflare.com/bots/get-started/bot-fight-mode/)
- Cloudflare Docs. [Super Bot Fight Mode](https://developers.cloudflare.com/bots/get-started/super-bot-fight-mode/)
- Cloudflare Docs. [Security features interoperability](https://developers.cloudflare.com/waf/feature-interoperability/)
- Cloudflare Docs. [Available skip options](https://developers.cloudflare.com/waf/custom-rules/skip/options/)
- Cloudflare Docs. [Verified bots](https://developers.cloudflare.com/bots/concepts/bot/verified-bots/)
- Cloudflare Docs. [cf.client.bot](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/reference/cf.client.bot/)
- Cloudflare. [Planos e preços](https://www.cloudflare.com/plans/)