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
- No painel do WordPress, entre em Plugins → Adicionar novo plugin.
- Pesquise por Redirection, do desenvolvedor John Godley.
- Clique em Instalar agora e depois em Ativar.
- 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
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 |
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
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
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
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-Legalcorresponda a/post-legal. - Ignorar barra final: permite que uma origem corresponda tanto a
/post-legalquanto 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
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:
- Confirme que a origem redireciona para o conteúdo esperado.
- Confira se o destino já usa HTTPS, o domínio preferido e a barra final correta.
- Verifique se a página final responde
200e se não há um ciclo entre endereços. - Atualize os links internos que você controla para apontarem diretamente ao destino final.
- 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.
