O Redirection é um plugin gratuito para administrar redirecionamentos no WordPress, acompanhar erros 404 e monitorar mudanças nos endereços de posts e páginas. Ele ajuda quando você altera um link permanente, reorganiza o conteúdo ou precisa encaminhar visitantes de uma URL antiga para a nova.

Neste tutorial, você vai configurar uma regra 301, escolher o domínio preferido, revisar os registros e evitar redirecionamentos desnecessários. Os nomes das opções podem variar conforme a versão e a tradução do plugin.

Para melhor performance, prefira redirecionar na borda quando a regra puder ser resolvida pela Cloudflare. No funcionamento padrão pelo WordPress, o Redirection usa PHP para processar a regra quando a requisição chega à aplicação. Isso consome recursos da hospedagem e acrescenta trabalho antes da resposta. Executar o redirect diretamente na Cloudflare evita consultar a origem e acionar o PHP para essa decisão. Veja como configurar redirecionamentos na borda da Cloudflare, mantendo o plugin para as funções editoriais e os registros que você ainda precisar.

Se você administra a hospedagem, também pode configurar redirecionamentos no Nginx para WordPress, tratando HTTPS, domínio e barra final no servidor antes de carregar o PHP.

Como instalar o Redirection

  1. No painel do WordPress, entre em Plugins → Adicionar novo plugin.
  2. Pesquise por Redirection, do desenvolvedor John Godley.
  3. Clique em Instalar agora e depois em Ativar.
  4. Abra Ferramentas → Redirection e conclua a configuração inicial.

Antes de começar, confira os requisitos apresentados na página do plugin e mantenha um backup das regras existentes. Na configuração padrão, as URLs precisam chegar ao WordPress para que o plugin consiga tratá-las; ele não controla respostas que o servidor ou a CDN entrega antes dessa etapa. Consulte as instruções oficiais de instalação.

Como criar um redirecionamento 301

Na aba Redirecionamentos, adicione uma regra com a URL de origem e o destino. Para uma mudança permanente de endereço, selecione o código 301 nas opções da regra.

Campo Exemplo
URL de origem /post-antigo/
URL de destino /post-atual/
Código HTTP 301 — Movido permanentemente

A origem normalmente contém apenas o caminho, sem o domínio. O destino pode ser relativo ao site ou uma URL completa, conforme a documentação de criação de regras.

Depois de salvar, abra o endereço antigo e confirme que o navegador chega à página correta. Use um destino que substitua o conteúdo anterior; enviar qualquer erro 404 para a página inicial pode deixar o visitante sem a informação que procurava.

Se a mudança também envolve o domínio do site, veja como atualizar as URLs do WordPress com WP-CLI. A atualização dos endereços armazenados e o redirecionamento dos acessos antigos são etapas distintas da migração.

Configurações da aba Site: HTTPS e domínio preferido

As configurações canônicas ajudam a padronizar as variações do domínio. Nos exemplos abaixo, example.com representa o seu site.

Forçar HTTP para HTTPS

Confirme primeiro que o certificado está válido e que o site abre normalmente por HTTPS. Depois, ative a opção de forçar HTTPS, caso esse redirecionamento ainda não seja feito pela hospedagem ou CDN:

http://example.com/ → https://example.com/

Para revisar os endereços armazenados no banco de dados, consulte o tutorial de migração do WordPress para HTTPS.

Escolher entre www e sem www

O plugin permite manter o domínio sem preferência adicional, remover www ou adicioná-lo. Escolha o padrão que seu site já utiliza e alinhe essa escolha com as configurações da hospedagem e do WordPress.

Preferência Exemplo de resultado
Remover www https://www.example.com/ → https://example.com/
Adicionar www https://example.com/ → https://www.example.com/

As duas versões do domínio precisam estar configuradas no servidor; para acessos por HTTPS, o certificado também deve atender aos nomes utilizados. Evite regras concorrentes que acrescentem www em uma camada e o removam em outra. Veja os detalhes das opções do site no Redirection.

Como testar as quatro variações

Quatro variações de protocolo e domínio sendo verificadas para identificar o endereço preferido do site.

Para uma página existente, considere este cenário com HTTPS e sem www como destino preferido:

Endereço testado Resultado esperado neste exemplo
http://example.com/post-atual/ Redirecionar para https://example.com/post-atual/
http://www.example.com/post-atual/ Redirecionar para o mesmo destino
https://www.example.com/post-atual/ Redirecionar para o mesmo destino
https://example.com/post-atual/ Responder 200, sem outro redirecionamento

Três variações do endereço redirecionam por 301 para a URL HTTPS sem www, que responde 200.

Se as regras foram configuradas como 301, esse deve ser o código das respostas intermediárias. Uma infraestrutura também pode usar 308 para redirecionamentos permanentes; o Google reconhece ambos como sinais de mudança permanente. O objetivo é chegar ao endereço preferido com o menor número de saltos possível. Consulte a orientação do Google sobre redirecionamentos.

Você pode conferir a sequência na aba Rede/Network das ferramentas do navegador ou no comparador de cabeçalhos HTTP. Observe o código de cada resposta e o campo Location, não apenas a URL que ficou na barra de endereços.

Cabeçalhos HTTP: o que configurar com cuidado

Exemplos de X-Content-Type-Options, Referrer-Policy e X-Frame-Options apresentados em cartões explicativos.

O Redirection permite adicionar cabeçalhos ao site ou somente às respostas de redirecionamento. Escolha o local de aplicação conforme o objetivo da regra e confira se o servidor ou a CDN já envia o mesmo cabeçalho, evitando configurações duplicadas ou conflitantes.

Estes são exemplos de valores para avaliar no seu site:

X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
X-Frame-Options: SAMEORIGIN
Cabeçalho O que considerar
X-Content-Type-Options nosniff restringe a interpretação de determinados recursos com um tipo diferente do informado pelo servidor.
Referrer-Policy strict-origin-when-cross-origin controla as informações de referência enviadas em navegações e requisições.
X-Frame-Options SAMEORIGIN permite enquadramento pela mesma origem. DENY bloqueia também esse uso e deve ser escolhido conforme a necessidade de incorporar páginas do site.

O valor strict-origin-when-cross-origin pertence ao Referrer-Policy, e não ao Content-Security-Policy.

A Content Security Policy (CSP) usa diretivas próprias para controlar recursos como scripts, imagens e conexões. Ela precisa considerar o tema, os plugins e as integrações do site. Uma forma de avaliar uma política antes de bloquear recursos é usar Content-Security-Policy-Report-Only, com o tratamento adequado dos relatórios. Consulte a documentação de CSP.

O cabeçalho X-XSS-Protection está obsoleto e não deve ser ativado como uma proteção moderna contra XSS. A referência da MDN explica suas limitações.

CORS não é uma configuração geral de segurança

Diagrama que diferencia política de referência, política de conteúdo e permissão de acesso entre origens.

Cabeçalhos CORS controlam o acesso, por navegadores, a recursos solicitados por outra origem. Configure-os quando uma integração precisar desse acesso, no recurso apropriado, em vez de liberar origens e credenciais para todo o site sem necessidade.

Este exemplo ilustra a sintaxe para uma origem específica; ele não é uma configuração universal para WordPress:

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, OPTIONS

O valor da origem não leva aspas nem o marcador <origin>, e os métodos são separados por vírgulas. Habilitar credenciais exige uma avaliação própria e não pode ser combinado com uma origem curinga *. Veja as referências de Access-Control-Allow-Origin e Access-Control-Allow-Methods.

Depois das alterações, use o Security Headers para inspecionar os cabeçalhos entregues. A nota é um indicador desse teste, não uma garantia de segurança nem um resultado fixo que toda instalação receberá.

Configurações da aba Opções: registros e monitoramento

Organização dos registros de redirecionamentos e erros 404 com controles de retenção e coleta de IP.

Os registros ajudam a entender quais URLs são acessadas, quais regras entram em ação e onde aparecem erros. A documentação dos logs descreve as informações disponíveis, como origem, destino, horário e dados do cliente, conforme as opções habilitadas.

Retenção e registro de IP

Configuração Opções disponíveis
Registros de redirecionamento Desativar ou manter por um dia, uma semana, um mês, dois meses ou indefinidamente
Registros de erros 404 Ajustar a retenção separadamente dos redirecionamentos
Registro de IP Desativar, registrar o IP completo ou mascarar sua parte final

Defina uma retenção proporcional à análise que você precisa fazer. A limpeza por prazo depende do agendamento do WordPress. Revisar a coleta e a retenção também faz parte da administração dos dados do site; as informações de privacidade do plugin explicam os controles disponíveis.

Outros registros

  • Redirecionamentos externos: registra também os realizados pelo WordPress ou por outro plugin; “externos” aqui não significa apenas outro domínio.
  • Contagem de acessos e último acesso: ajuda a acompanhar o uso das regras.
  • Captura de cabeçalhos: acrescenta detalhes para diagnóstico e aumenta o volume armazenado.

Monitoramento de URLs

O plugin pode criar regras quando os links permanentes de posts, páginas e outros tipos de conteúdo mudam. Para conteúdos excluídos, as regras podem ser criadas desativadas: escolha um destino adequado antes de habilitá-las. Consulte as opções de registros e monitoramento.

Na aba 404s, examine as URLs e use Adicionar redirecionamento quando houver um conteúdo equivalente. O painel também pode mostrar tentativas de robôs e endereços que nunca existiram; cada entrada precisa ser avaliada. A documentação de acompanhamento de erros 404 mostra esse fluxo.

Correspondência de URLs e parâmetros de consulta

As opções padrão podem ser ajustadas para cada regra:

  • Ignorar maiúsculas e minúsculas: permite que /Post-Legal corresponda a /post-legal.
  • Ignorar barra final: permite que uma origem corresponda tanto a /post-legal quanto a /post-legal/.

Os parâmetros de consulta são a parte depois de ?. Veja o comportamento das três modalidades, considerando uma regra de /post-antigo para /post-atual:

Modalidade Comportamento
Correspondência exata Os parâmetros precisam corresponder aos definidos na origem, independentemente da ordem.
Ignorar todos os parâmetros A regra pode corresponder a /post-antigo?origem=email, sem repassar esse parâmetro ao destino.
Ignorar e passar os parâmetros O mesmo acesso pode chegar a /post-atual?origem=email.

Escolha conforme a função dos parâmetros: um identificador de produto pode precisar de tratamento diferente de uma marcação de campanha. Os exemplos oficiais estão na documentação de correspondência de URLs.

Como evitar cadeias de redirecionamento

Comparação entre uma cadeia de dois redirecionamentos e um caminho direto para o destino com a barra final correta.

Uma cadeia acontece quando o visitante passa por destinos intermediários antes da página final. Por exemplo, se o padrão do site termina com barra:

/post-antigo → /post-atual → /post-atual/

Configure o destino diretamente no formato que responde sem outro redirecionamento:

/post-antigo → /post-atual/

Ignorar barra final altera a correspondência da origem; não corrige a barra do destino. Desmarcar essa opção pode ajudar a testar duas origens separadamente, mas não elimina uma cadeia causada por um destino fora do padrão do site.

Depois de criar ou alterar uma regra:

  1. Confirme que a origem redireciona para o conteúdo esperado.
  2. Confira se o destino já usa HTTPS, o domínio preferido e a barra final correta.
  3. Verifique se a página final responde 200 e se não há um ciclo entre endereços.
  4. Atualize os links internos que você controla para apontarem diretamente ao destino final.
  5. Se uma regra antiga continuar aparecendo, revise o cache do navegador e as camadas de cache envolvidas, como o FastCGI Cache do Nginx, quando utilizado.

O Redirection organiza as regras, mas a validação precisa considerar também o WordPress, a hospedagem e qualquer CDN que participe do caminho.