WordPress processa cada visita por PHP e banco de dados antes de devolver o HTML. Cache de plugin adianta parte do caminho; cache full-page na Cloudflare elimina o caminho inteiro para a maioria dos visitantes: o HTML pronto fica armazenado na edge mais próxima e o servidor nem é chamado. A diferença nos Core Web Vitals que movem o RPM do AdSense é direta, e em 2026 o Google usa exatamente esses sinais (LCP, INP, CLS) tanto para ranqueamento quanto para o desempenho de anúncios.
Checklist 1: entenda a camada antes de ativar
- Sem cache de página: visitante → Cloudflare → servidor WordPress → PHP → banco → HTML gerado na hora.
- Com cache full-page: visitante → edge da Cloudflare → HTML em cache, entregue na hora.
- Cache de assets (CSS, JS, imagens, fontes): já acontece por padrão na Cloudflare; o que exige configuração é a página inteira.
- Plugin de cache no WordPress: continua útil para minificação e cache local; full-page na edge não substitui tudo, soma.
Checklist 2: exclusões obrigatórias antes de ativar
Cache full-page errado entrega a página de um visitante para outro. Estas rotas ficam fora do cache em qualquer configuração séria:
- /wp-admin/ e /wp-login.php: o painel inteiro nunca em cache.
- Carrinho, checkout e minha conta em WooCommerce (/carrinho/, /finalizar-compra/, /minha-conta/).
- Qualquer página com conteúdo personalizado por visitante (área de membro, painel do usuário).
- Páginas com formulário que exibe dados do visitante ou nonce de segurança expirável.
- Parâmetros de sessão na query string (utm é seguro; session_id nunca).
Abra o site em duas janelas anônimas, faça login em uma e não na outra, e recarregue a mesma página com cache ativo: se a janela logada ver conteúdo de visitante (ou o inverso), há rota personalizada vazando em cache. Esse teste de 2 minutos evita o incidente mais comum de full-page cache em WordPress.
Checklist 3: os 10 pontos antes de ativar em produção
- HTTPS ativo: Cloudflare full e SSL no modo Full (strict): pré-requisito de segurança.
- Backup recente: snapshot do site e do banco antes de qualquer regra nova.
- Página de cache rule: regra de Cache Everything restrita a HTML de páginas públicas (/posts/, /paginas/), não ao domínio inteiro.
- Edge TTL definido: 4 a 24 horas para conteúdo editorial; TTL longo demais segura atualização, curto demais perde a vantagem.
- Purga automática no publish: plugin de cache que purga a URL na publicação/atualização (o tipo de integração que plugins como o SuperFlare Cache automatizam no painel do WordPress).
- Exclusões do Checklist 2 aplicadas: testadas uma a uma com o teste das duas janelas.
- Formulários testados: contato, comentário e newsletter enviando sem erro de nonce expirado.
- Cabecalhos de cache conferidos: resposta com cf-cache-status: HIT nas visitas repetidas e BYPASS nas rotas excluídas.
- Core Web Vitals medidos: PageSpeed Insights antes e depois: LCP e TTFB melhoram na comparação direta.
- Rollback documentado: como desligar a regra em 1 minuto se algo quebrar (é desativar a Cache Rule, sem tocar no site).
Checklist 4: velocidade que paga conta (o elo com monetização)
Velocidade não é só SEO: sites monetizados ganham linha de renda com Core Web Vitals bons. O Google declara melhor RPM e desempenho de anúncios para páginas com LCP, INP e CLS saudáveis, e o checklist de busca com IA mostra por que velocidade também é porta de entrada de rastreadores, e leitor que espera menos rola mais, vendo mais impressões. O checklist de ganhos do AdSense lista velocidade como um dos 10 ajustes de maior retorno, e a fundação técnica está no serviço de auditoria de SEO técnico da M&C.
Quando full-page cache não resolve
Cache entrega HTML rápido; não conserta página pesada. Imagem de 4 MB, tema com 12 carousels e 9 pixels de rastreamento continuam lentos com HIT na edge. A ordem certa: enxugar página (imagens otimizadas, menos scripts, tema são) e depois cachear. Para diagnóstico, o diagnóstico gratuito de SEO da M&C inclui a leitura de performance com as prioridades de correção.