Checklist de Cloudflare para WordPress de alto tráfego
Um checklist prático de Cloudflare para proteger, acelerar e operar portais WordPress com mais previsibilidade em tráfego alto.
WordPress de alto tráfego não pode depender apenas de plugin de cache.
Plugin ajuda, mas ele está dentro da aplicação. Quando o tráfego sobe, a melhor defesa é fazer menos requisições chegarem ao PHP, ao banco e ao servidor de origem. É aí que o Cloudflare deixa de ser apenas “DNS com CDN” e vira uma camada operacional importante.
Este checklist é o que eu usaria como ponto de partida para um portal WordPress que precisa continuar no ar com previsibilidade: cache bem definido, origem protegida, wp-admin menos exposto e regras simples o suficiente para serem mantidas.
A mentalidade correta
Antes de configurar qualquer botão, é preciso separar três coisas:
- O que pode ser cacheado na borda.
- O que precisa chegar ao WordPress.
- O que deveria ser bloqueado antes de chegar ao servidor.
Essa separação muda o jogo.
Página pública de notícia, artigo, categoria e tag geralmente pode receber cache agressivo, desde que exista estratégia de purga. Área logada, carrinho, checkout, preview, comentários administrativos e wp-admin precisam de bypass. Tráfego malicioso, scans e tentativas repetidas de login devem ser filtrados antes de consumir recurso da origem.
O objetivo não é esconder um WordPress frágil atrás do Cloudflare. O objetivo é reduzir superfície, carga e variabilidade.
DNS, SSL e origem
O básico precisa estar certo antes do cache.
Checklist inicial:
- usar proxy ativo nos registros públicos do site;
- manter SSL em modo adequado, preferencialmente ponta a ponta;
- garantir certificado válido também na origem;
- remover exposição desnecessária do IP real do servidor;
- revisar registros DNS antigos;
- separar subdomínios administrativos quando fizer sentido;
- manter redirects centralizados e previsíveis.
Um erro comum é configurar Cloudflare na frente, mas deixar o servidor aceitando tráfego direto pelo IP. Nesse cenário, parte da proteção pode ser contornada. Quando possível, a origem deve aceitar requisições apenas da camada esperada ou de redes confiáveis.
Também vale revisar headers, compressão, HTTP/2 ou HTTP/3 e regras de redirecionamento. Performance não nasce só no cache. Ela começa no caminho entre usuário, borda e origem.
Cache sem quebrar login
Cache em WordPress exige cuidado porque nem toda página é igual.
Para conteúdo público, a borda pode aliviar muito o servidor. Para conteúdo personalizado, cache errado pode vazar estado, mostrar barra administrativa indevida ou entregar uma página desatualizada para quem não deveria vê-la.
Um desenho conservador:
- cachear páginas públicas de posts, páginas, categorias e tags;
- ignorar query strings desnecessárias quando houver segurança para isso;
- bypass para
wp-admin,wp-login.php, previews e endpoints sensíveis; - bypass quando houver cookies de usuário logado;
- definir TTL de borda de acordo com a frequência editorial;
- manter purga por URL ou por grupo sempre que um post for atualizado;
- testar comportamento em janela anônima e usuário logado.
O ponto mais importante: cache bom precisa ser previsível.
Se a equipe editorial publica muitas atualizações ao longo do dia, o plano de cache precisa conversar com essa rotina. Não adianta ter cache agressivo se a operação precisa limpar tudo manualmente a cada alteração.
WAF, bots e wp-admin
WordPress é alvo constante porque é popular. Isso não significa que ele seja inviável. Significa que a superfície precisa ser tratada com seriedade.
Eu começaria com regras para:
- desafiar ou bloquear tentativas abusivas contra
wp-login.php; - proteger
/wp-admin/por país, IP, Access ou regra específica quando possível; - bloquear métodos HTTP que o site não usa;
- criar rate limit para endpoints sensíveis;
- monitorar XML-RPC e desativar quando não for necessário;
- bloquear padrões óbvios de exploração;
- revisar bots que consomem muito recurso sem trazer valor.
Aqui vale uma observação pragmática: regra demais também vira risco.
Uma configuração difícil de entender tende a ser abandonada. Melhor começar com poucas regras claras, medir impacto e evoluir com base em logs. Segurança boa reduz risco sem transformar cada publicação em medo de quebrar o site.
Operação e monitoramento
Cloudflare não é configuração de uma vez só. É parte da operação.
Depois da configuração inicial, eu acompanharia:
- taxa de cache hit;
- páginas mais acessadas;
- tráfego bloqueado pelo WAF;
- origem recebendo picos inesperados;
- erros 5xx;
- tempo de resposta da origem;
- regras acionadas com frequência;
- URLs que deveriam estar cacheadas, mas não estão.
Também manteria um pequeno runbook:
- Como ativar modo de desenvolvimento.
- Como purgar uma URL.
- Como purgar um grupo de páginas.
- Como desativar uma regra problemática.
- Como identificar se o erro vem da origem ou da borda.
Em alto tráfego, improviso custa caro. O time precisa saber o que fazer antes da crise.
O melhor uso do Cloudflare em WordPress não é empilhar recursos. É desenhar uma borda inteligente: cachear o que é público, proteger o que é sensível e deixar a origem trabalhar apenas quando ela realmente precisa trabalhar.