Redirecionamento na Cloudflare: menos PHP, mais performance

Redirecionar diretamente na borda da Cloudflare evita acionar o servidor de origem e o PHP para decidir aquele redirecionamento. Para regras previsíveis, como HTTP para HTTPS, troca de www e mudança de uma URL antiga para a nova, esse costuma ser o melhor ponto de execução quando o domínio já usa o proxy da Cloudflare.

Neste tutorial, você vai configurar Single Redirects, preservar parâmetros e testar se o visitante chega ao destino correto com o menor número de saltos. O exemplo usa siterapidowp.com.br, com HTTPS, sem www e com barra final nas páginas.

Por que redirecionar na borda melhora a performance?

Quando uma regra é processada pelo WordPress, a requisição chega à hospedagem e usa PHP para carregar a aplicação e decidir o destino. Isso consome recursos e acrescenta trabalho antes de devolver o cabeçalho Location. A documentação do Redirection confirma que seu funcionamento padrão depende de as URLs serem atendidas pelo WordPress.

Com uma Redirect Rule correspondente na Cloudflare, a resposta é produzida antes de consultar a origem. Assim, aquela etapa não precisa de execução PHP no servidor.

Onde a regra é executada	Trabalho para devolver o redirect
WordPress/plugin	A requisição precisa chegar à aplicação, com processamento PHP quando não for atendida antes por outra camada
Nginx ou Apache	O servidor pode responder sem carregar o WordPress, mas continua recebendo a requisição
Borda da Cloudflare	A regra pode responder sem consultar a hospedagem

O ganho depende de distância, carga, cache e configuração. Não há uma redução fixa de milissegundos para todo site, e o navegador ainda precisa fazer outra requisição para acessar o destino.

Para tratar as regras na hospedagem, veja como configurar redirecionamentos no Nginx para WordPress. O tutorial cobre as duas opções de www, HTTPS e adição ou remoção de barra final, sem depender de PHP para decidir esses redirects.

O plugin Redirection para WordPress continua útil para administrar mudanças de posts e analisar erros 404. Para regras que não dependem de informações internas do WordPress, prefira a borda quando ela estiver disponível.

O que precisa estar configurado?

Antes de criar as regras:

1. Ative o proxy — nuvem laranja — nos registros DNS do domínio e do www que receberão as requisições.
2. Confirme que o certificado de borda está ativo para os nomes utilizados.
3. Alinhe HTTPS, domínio preferido e barra final com a aplicação, a hospedagem e as demais regras existentes.
4. Confira se as URLs de destino funcionam e não redirecionam de volta à origem da regra.
5. Durante a validação, considere usar 302; depois de confirmar uma mudança permanente, altere para 301.

Single Redirects estão disponíveis no plano Free, com limite de 10 regras por zona na documentação consultada. O exemplo usa três e não depende de regex. Confira a disponibilidade e a ordem de execução dos redirects antes de configurar.

Para a conexão entre Cloudflare e hospedagem, mantenha a configuração SSL/TLS adequada ao certificado da origem, normalmente Full (strict) quando ele é válido. Fazer redirect não substitui configurar os certificados.

Defina a URL canônica antes de criar regras

Neste exemplo, o padrão escolhido é:

• HTTPS.
• Domínio sem www.
• Barra final nas páginas HTML abrangidas pela regra.
• Arquivos estáticos sem mudança de barra.
• Query string preservada.

Uma entrada como:

http://www.siterapidowp.com.br/performance?origem=teste

Deve chegar diretamente a:

https://siterapidowp.com.br/performance/?origem=teste

Isso evita uma cadeia em que cada resposta corrige apenas um detalhe: primeiro HTTPS, depois host e, por último, barra final. Substitua o domínio do exemplo pelo seu e mantenha somente uma preferência de host e barra.

Como criar as três Redirect Rules

No painel da Cloudflare, selecione o domínio e entre em Rules → Overview → Create rule → Redirect Rule. Escolha Custom filter expression e use um destino dinâmico para as regras abaixo. A documentação de criação pelo painel mostra esse fluxo.

Em todas as regras, marque Preserve query string e use o mesmo código de status durante os testes. As expressões abaixo tratam somente navegações GET e HEAD; não normalizam requisições POST.

Regra 1 — adicionar barra, HTTPS e domínio preferido

Nome sugerido: 01 — Canonical e barra final.

Expressão de correspondência:

http.host in {"siterapidowp.com.br" "www.siterapidowp.com.br"}
and http.request.method in {"GET" "HEAD"}
and http.request.uri.path ne "/"
and not ends_with(http.request.uri.path, "/")
and not http.request.uri.path contains "."
and not starts_with(http.request.uri.path, "/.well-known/")
and not starts_with(http.request.uri.path, "/wp-admin")
and not starts_with(http.request.uri.path, "/wp-json")
and not starts_with(http.request.uri.path, "/api")
and not starts_with(http.request.uri.path, "/checkout")
and not starts_with(http.request.uri.path, "/customer")
and not starts_with(http.request.uri.path, "/admin")

Expressão do destino dinâmico:

concat("https://siterapidowp.com.br", http.request.uri.path, "/")

Essa regra já corrige os três componentes quando falta a barra. As exclusões são um ponto de partida: rotas dinâmicas próprias, webhooks, endpoints e páginas que não aceitam barra precisam de tratamento específico.

O teste de ponto no caminho é uma heurística, não uma identificação real do tipo de arquivo. Ele deixa /app.css intacto, mas também ignora uma página como /versao-1.2. Ajuste ao conjunto de rotas do seu site.

Regra 2 — trocar www pelo domínio sem www

Nome sugerido: 02 — WWW para sem WWW.

Expressão de correspondência:

http.host eq "www.siterapidowp.com.br"
and http.request.method in {"GET" "HEAD"}

Expressão do destino:

concat("https://siterapidowp.com.br", http.request.uri.path)

Ela trata as requisições que não corresponderam à primeira regra, preservando o caminho e já escolhendo HTTPS.

Regra 3 — HTTP para HTTPS no host preferido

Nome sugerido: 03 — HTTP para HTTPS.

Expressão de correspondência:

http.host eq "siterapidowp.com.br"
and http.request.scheme eq "http"
and http.request.method in {"GET" "HEAD"}

Expressão do destino:

concat("https://siterapidowp.com.br", http.request.uri.path)

Essa regra cuida do protocolo quando o domínio já está correto e a primeira regra não se aplica.

Mantenha a ordem das regras

A Cloudflare usa o primeiro redirect correspondente. Por isso, mantenha a regra que corrige barra, host e protocolo antes das regras mais amplas.

As exclusões da primeira regra evitam alterar a barra de rotas especiais; elas não impedem a segunda e a terceira regras de corrigir host ou protocolo nessas rotas. Se um endpoint não puder receber nenhum redirect, exclua-o de todas as regras pertinentes.

Se o seu site usa www, adapte os destinos e inverta a condição da regra de host. Se trabalha sem barra final, use uma regra própria para remover a barra — não ative as duas direções. O padrão deve concordar com o destino que a aplicação realmente serve.

E se eu só quiser redirecionar uma página antiga?

Crie uma regra específica, antes das normalizações gerais, quando ela precisar enviar a URL antiga diretamente ao destino final.

Correspondência de exemplo:

http.host in {"siterapidowp.com.br" "www.siterapidowp.com.br"}
and http.request.method in {"GET" "HEAD"}
and http.request.uri.path in {"/post-antigo" "/post-antigo/"}

Use um destino estático, já completo:

https://siterapidowp.com.br/performance/post-atual/

Substitua os caminhos por páginas reais e equivalentes. A regra pode então resolver, em uma resposta, uma entrada HTTP com www e caminho antigo.

A escolha de preservar parâmetros depende da função deles. Marcações de campanha podem ser úteis; identificadores e parâmetros que mudam o conteúdo precisam ser avaliados. Não encaminhe indiscriminadamente todos os erros 404 para a página inicial.

Como testar o resultado

Use uma página existente para conferir protocolo, host, barra e query string. Por exemplo:

curl -I 'http://www.siterapidowp.com.br/performance?origem=teste'
curl -I 'http://siterapidowp.com.br/performance/'
curl -I 'https://www.siterapidowp.com.br/performance/'
curl -I 'https://siterapidowp.com.br/performance/'

Para as regras permanentes já validadas, o resultado esperado é:

Entrada	Resposta esperada
HTTP, www e sem barra	301 direto para HTTPS, sem www e com barra
HTTP no host preferido	301 para HTTPS
HTTPS com www	301 para o host preferido
HTTPS, host e barra corretos	Página final sem outro redirect

O parâmetro origem=teste deve permanecer no destino quando a preservação estiver habilitada. Confira também um arquivo estático real: ele não deve receber uma barra extra.

Para seguir o caminho e contar saltos:

curl -sSIL --max-redirs 10 \
  -o /dev/null \
  -w 'redirects=%{num_redirects} final=%{url_effective}\n' \
  'http://www.siterapidowp.com.br/performance?origem=teste'

Nesse cenário, o objetivo é um redirect até https://siterapidowp.com.br/performance/?origem=teste. Se aparecerem saltos adicionais, revise a ordem e as regras da origem. Esses são resultados esperados do exemplo, não um relato de teste executado no seu domínio.

Cuidados ao aplicar em WordPress

• Métodos HTTP: 301 e 302 podem fazer o cliente trocar POST por GET; 307 e 308 preservam o método. Escolha conforme a operação e teste os clientes envolvidos. Veja as configurações de status e parâmetros.
• HTTPS já configurado: o Always Use HTTPS pode cuidar da troca de protocolo. Se ele estiver ativo, revise a necessidade da terceira regra e teste a cadeia completa. Consulte a orientação de Always Use HTTPS.
• Regras de segurança: Single Redirects executam antes das Custom Rules do WAF e do Rate Limiting. Uma requisição encerrada pelo redirect não passa pelas fases posteriores nessa mesma requisição. Considere isso no desenho das regras, conforme a ordem das fases da Cloudflare.
• Conteúdo do banco: um redirect não atualiza links gravados em posts. Para isso, veja como migrar as URLs do WordPress para HTTPS.
• Logs: uma requisição atendida na borda não chega ao plugin; seus registros no WordPress não mostrarão aquele acesso.
• Cache e reversão: redirects permanentes podem ficar armazenados pelo cliente. Durante o diagnóstico, confira o resultado com uma requisição nova e registre as regras anteriores para poder revertê-las.

O uso de Cloudflare WAF no WordPress complementa a administração da borda, mas redirecionamento e proteção têm funções distintas.

Quando continuar usando o Redirection?

Mantenha o plugin quando sua rotina editorial precisar monitorar mudanças de links permanentes, administrar regras dentro do WordPress ou investigar os 404 que chegam à aplicação. Regras dependentes de dados internos do site também podem precisar permanecer nessa camada.

Para normalizações previsíveis e mapeamentos que a Cloudflare consegue decidir sozinha, executar na borda evita processamento PHP e reduz trabalho na hospedagem. Distribua as responsabilidades com clareza, teste o destino e atualize os links internos para que apontem diretamente à URL final.