Cloudflare grátis: como configurar o cache e a CDN do site

A Cloudflare grátis funciona como uma portaria na frente do seu site: o visitante conversa com ela, e ela só incomoda o seu servidor quando não tem guardada uma cópia do que foi pedido. Essa cópia é o cache. A rede de servidores espalhados que guarda as cópias perto de quem visita é a CDN. Para ativar, você cadastra o domínio no plano Free, confere os registros de DNS, troca os nameservers e deixa o proxy ligado.

O que quase todo tutorial pula: depois disso, imagens, CSS e JavaScript já passam pelo cache, mas o HTML das páginas continua indo ao servidor em toda visita. Abaixo, como mudar isso sem expor a área logada, como conferir nos cabeçalhos e como voltar atrás.

O que são CDN e cache, em palavras simples?

Cache é guardar uma resposta pronta para não ter de montá-la de novo. Ele mora em três lugares: no navegador de quem visita, que reaproveita o que já baixou; no servidor, onde um plugin ou a hospedagem guarda o HTML montado; e, no meio, na CDN, sigla em inglês para rede de distribuição de conteúdo. Sem CDN, quem abre o site em Manaus busca cada arquivo no servidor da hospedagem, esteja ele em São Paulo ou nos Estados Unidos. Com a Cloudflare na frente, as visitas seguintes recebem a cópia que ficou na rede dela.

O tráfego só passa pela Cloudflare quando o registro de DNS está como Proxied, a nuvem laranja do painel. Com a nuvem cinza (DNS only), ela apenas informa o IP do seu servidor e não guarda, não otimiza e não protege nada daquele endereço.

A Cloudflare grátis vale a pena para o seu site?

Vale quando a demora está na entrega dos arquivos, na distância até o visitante ou nos picos de acesso. Não muda quase nada quando a página é pesada ou quando o servidor demora para montar um HTML que ninguém configurou para ir ao cache. Pela página do plano Free, ele inclui SSL, CDN e proteção contra ataques DDoS.

Na nossa leitura, para empresa pequena ou blog em hospedagem compartilhada, o plano Free é o ajuste de velocidade com melhor relação entre esforço e resultado, desde que alguém saiba onde fica o botão de pausar.

Quantos sites brasileiros estão sem cache e sem CDN?

Mais da metade. Dos 52 sites brasileiros cuja infraestrutura o Nota do Site conseguiu medir entre 20 e 22 de outubro de 2026, olhando a página inicial de cada um:

• 30 de 52 não mostraram sinal de CDN nenhum nos cabeçalhos da resposta.
• 35 de 52 levaram alerta no cache da página HTML. Em 25, a página não envia ETag nem Last-Modified, e o buscador não tem como saber se ela mudou sem baixar tudo de novo. Em 10, não havia cabeçalho de cache algum.
• 15 de 31 sites em que deu para testar os arquivos estáticos reprovaram no cache deles, número que também aparece no nosso diagnóstico de lentidão.

Antes de escrever, rodamos o mesmo teste no nosso site, que fica atrás da Cloudflare com o SSL em Full (strict). O CSS e o JavaScript voltam com cf-cache-status: HIT e um ano de cache no navegador, com o nome do arquivo trocando a cada versão. As páginas voltam com DYNAMIC: o servidor responde com Cache-Control: private, a página inicial ainda manda Set-Cookie, e a Cloudflare, com razão, não guarda o HTML. E, como nos 25 sites do levantamento, elas não enviam ETag nem Last-Modified. CDN ligada não significa página em cache.

E vai continuar assim por enquanto, por escolha. Toda página do nosso site carrega um token de segurança ligado à sessão de quem visita, usado pelo formulário de análise. Um ETag calculado pelo conteúdo mudaria a cada visita e não serviria para nada. Pior: se o servidor respondesse 304 a um navegador, ele reaproveitaria a página guardada com um token vencido, e o formulário falharia com "página expirada". Para ligar o cache do HTML com segurança, as páginas públicas precisariam deixar de abrir sessão. Se o seu site tem login, carrinho ou formulário, faça a mesma conta antes de ligar.

Como ativar a Cloudflare no plano grátis?

Tenha à mão o acesso ao painel onde o domínio foi registrado (para .br, o Registro.br).

1. Crie a conta e adicione o domínio. No painel da Cloudflare, vá em Domains, escolha adicionar (onboard) um domínio, digite o endereço sem www e selecione o plano Free.
2. Compare os registros de DNS importados com os atuais. A varredura automática pode esquecer algum. Confira a raiz, o www e os de e-mail (MX, SPF, DKIM e DMARC): registro de e-mail esquecido é caixa de entrada parada.
3. Escolha a nuvem de cada registro. Só registros A, AAAA e CNAME passam pelo proxy. Deixe laranja os do site, a raiz e o www. MX e TXT são sempre DNS only, e subdomínios que não servem páginas, como o de FTP, também ficam cinza.
4. Desligue o DNSSEC no registrador, se estiver ativo. Trocar os nameservers com ele ligado pode deixar o domínio inacessível. Depois dá para religar pela Cloudflare.
5. Troque os nameservers. A Cloudflare mostra dois nomes. Apague os atuais no registrador e cole os dois exatamente como aparecem. Ela fala em até 24 horas para o registrador aplicar a troca.
6. Acerte o modo de SSL para Full (strict). O Flexible é a origem clássica do erro de redirecionamento sem fim, explicado no guia do aviso de site não seguro.
7. Espere o status Active. Quando a troca é reconhecida, chega um e-mail e o domínio aparece como ativo na lista.

O que a Cloudflare guarda sozinha, e o que fica de fora?

Ela decide pela extensão do arquivo. Entram no cache por padrão imagens, CSS, JavaScript, fontes, PDF, documentos, áudio, vídeo, arquivos compactados e o robots.txt.

Ficam de fora, pela documentação:

• HTML e JSON, ou seja, as páginas do site e as respostas de API;
• respostas com Cache-Control marcado como private, no-store, no-cache ou max-age=0;
• respostas que trazem Set-Cookie;
• pedidos que não são GET, como o envio de um formulário.

Quando o servidor não manda cabeçalho de cache, a Cloudflare aplica tempos padrão na rede dela: 120 minutos para respostas 200 e 301, 20 minutos para 302 e 3 minutos para 404.

Por isso tanta gente ativa a Cloudflare e o primeiro byte da página não melhora: o HTML segue sendo montado pelo servidor a cada visita.

Como colocar as páginas no cache sem expor a área logada?

Com duas Cache Rules: uma que libera o cache para o site e outra, abaixo dela, que tira dele tudo o que muda de pessoa para pessoa. As regras de cache da Cloudflare se acumulam e, quando duas mexem na mesma configuração, vale a última da lista. Por isso a exceção fica depois. O plano Free permite até 10 Cache Rules.

No painel do domínio, abra a página Cache Rules, em Caching, e clique em Create rule.

Regra 1, "Cachear o site"

Em When incoming requests match, escolha Custom filter expression, clique em Edit expression e cole:

(http.host eq "www.seusite.com.br")

Em Then, marque Eligible for cache. No Edge TTL, o mais seguro é seguir o Cache-Control do servidor quando houver e o padrão da Cloudflare quando não houver. Se o servidor marca toda página como private ou no-cache, como o nosso, nada será guardado: ajuste os cabeçalhos no servidor ou ignore-os e fixe um tempo. No plano Free, o menor tempo fixo é de 2 horas, então cada atualização só chega a todos depois disso ou de uma limpeza do cache.

Regra 2, "Nunca cachear", colocada depois da primeira

(starts_with(http.request.uri.path, "/wp-admin"))
or (http.request.uri.path eq "/wp-login.php")
or (starts_with(http.request.uri.path, "/carrinho"))
or (starts_with(http.request.uri.path, "/finalizar-compra"))
or (starts_with(http.request.uri.path, "/minha-conta"))
or (http.cookie contains "wordpress_logged_in")
or (http.cookie contains "woocommerce_items_in_cart")

Em Then, marque Bypass cache e troque os caminhos pelos da sua loja. Os dois cookies são o que o WordPress grava em quem fez login e o que o WooCommerce grava quando há produto no carrinho: quem está logado ou comprando recebe sempre a página do servidor.

A própria Cloudflare alerta que cachear tudo guarda o HTML mesmo quando ele tem conteúdo dinâmico, e que um visitante pode receber informação que não era para ele. Nunca deixe ir para o cache:

• o painel e o login (no WordPress, /wp-admin e wp-login.php);
• carrinho, checkout e área do cliente;
• página que mostre nome, pedido, saldo ou preço calculado para quem está logado.

Depois de ligar a regra, envie um formulário de teste para ver se ele continua funcionando. Quem prefere não mexer em regra pode usar, no WordPress, um plugin de cache de página no servidor, e deixar a Cloudflare só com os arquivos.

Quanto tempo o navegador deve guardar cada arquivo?

Arquivo que nunca muda pode ficar um ano. Página deve ser conferida a cada visita. A regra prática, que segue o MDN e o web.dev:

O no-cache engana pelo nome. Ele não proíbe guardar, só obriga a conferir antes de usar. Quem proíbe é o no-store, o certo para dados sensíveis.

Na Cloudflare, o Browser Cache TTL define esse tempo no navegador. O padrão é de 4 horas, e ela sobrescreve o cabeçalho do servidor quando ele pede menos ou não pede nada. Se o servidor já manda os tempos certos, escolha Respect Existing Headers.

O validador olha os CSS, JS, fontes e imagens do próprio site e conta os que saem com cache menor que 7 dias. Se passam de um quarto do total, a regra reprova; se são um quarto ou menos, fica no alerta.

ETag e Last-Modified: como o buscador pergunta se a página mudou?

Com uma etiqueta ou uma data. A página chega com ETag (uma impressão digital daquela versão) ou Last-Modified (a data da última alteração), e o navegador e o Googlebot guardam o valor. Na volta, em vez de baixar tudo, perguntam "ainda é aquela versão?" (If-None-Match) ou "mudou desde aquela data?" (If-Modified-Since). Se nada mudou, o servidor responde 304 Not Modified, sem o conteúdo.

O Google confirma que a infraestrutura de rastreamento dele aceita os dois pares e que o Googlebot usa esse cache quando rastreia de novo as páginas para a Pesquisa. Entre os dois, ele prefere o ETag, mas recomenda enviar ambos, porque outros sistemas usam a data.

A regra de cache da página HTML do validador confere isso na página inicial: dá alerta sem cabeçalho de cache nenhum e também quando há cabeçalho, mas sem ETag e sem Last-Modified. Quem cria esses cabeçalhos é o servidor ou a aplicação, não a Cloudflare. Com ela no meio, por padrão o ETag vira um ETag fraco (W/"..."), que indica conteúdo equivalente, e o forte só é preservado com a opção Respect Strong ETags numa Cache Rule. Para a pergunta "mudou?", o fraco serve: o If-None-Match faz justamente a comparação fraca.

Como conferir se o cache está funcionando?

Pelo cabeçalho cf-cache-status. No terminal:

curl -sI https://www.seusite.com.br/ | grep -iE "cf-cache-status|cache-control|etag|last-modified|age"

Rode duas vezes num arquivo: o que acabou de entrar no cache sai MISS e depois HIT. No navegador, a aba Rede do F12 mostra os mesmos cabeçalhos.

Se a página continua DYNAMIC depois da regra, confira a ordem das regras e os cabeçalhos que o servidor manda. A análise gratuita reconhece o CDN pelos cabeçalhos da resposta, como o cf-ray da Cloudflare, e mostra o status do cache que ele devolveu.

Como limpar o cache e testar mudanças?

Limpe só o endereço que mudou, com o Purge by URL, método que a Cloudflare recomenda. O Purge Everything apaga tudo, e cada página volta a ser buscada no servidor na visita seguinte. Os dois estão no plano Free, e nenhum apaga o que já está no navegador de quem visitou.

Para mexer no layout e ver o resultado na hora, ligue o Development Mode, na página Configuration de Caching. Ele ignora o cache por três horas e desliga sozinho, mas não apaga nada: ao terminar, limpe os endereços alterados.

A Cloudflare pode barrar os robôs de IA?

Pode, e sem você perceber. Desde 15 de setembro de 2026, domínios novos na Cloudflare entram com os robôs de treinamento e de agente bloqueados nas páginas que exibem anúncios, e a empresa avisa que robôs de uso misto, que buscam e treinam ao mesmo tempo, também são afetados por quem bloqueia o treinamento. Ao ativar, abra as configurações de segurança, revise as políticas de robôs de IA e veja se o robots.txt gerenciado está ligado. O que conferir está no passo sobre firewall e CDN do post do ChatGPT, e quais robôs liberar e quais barrar tem post próprio.

Como desfazer se algo der errado?

Comece pelo ajuste mais leve e só passe ao seguinte se o problema continuar:

1. Página errada ou desatualizada: limpe aquele endereço ou ligue o Development Mode.
2. Uma regra de cache causando estrago: desative a regra na lista de Cache Rules. O resto continua como estava.
3. Um subdomínio com defeito: em DNS > Records, edite o registro e desligue o proxy. Só ele sai da Cloudflare, e perde as regras, o firewall e o certificado dela.
4. O site inteiro: em Overview > Advanced Actions, use Pause Cloudflare on Site. Em até cinco minutos, o tráfego vai direto ao seu servidor. Se o servidor usa o certificado de origem da Cloudflare, o visitante verá erro de certificado durante a pausa.

Não volte os nameservers antigos como saída rápida. A própria Cloudflare lembra que essa troca pode levar horas para se espalhar, e o problema fica no ar enquanto isso.

O que conferir primeiro no seu site?

Rode a análise gratuita e olhe três regras na parte de infraestrutura: CDN, cache da página HTML e cache de CSS, JS, fontes e imagens. Sem CDN, comece pela ativação. Com CDN, rode o curl na página inicial: HTML em DYNAMIC e nenhum ETag é o retrato mais comum, inclusive no nosso site, e as seções sobre a Cache Rule e sobre o ETag mostram o que fazer em seguida.