Alterou um redireccionamento 301, mas o browser insiste em enviar os visitantes para o URL antigo? Uma dor de cabeça familiar para quem já configurou migrações de sites ou reestruturou links.

O problema não é do servidor nem do WordPress. O browser memoriza permanentemente um redireccionamento permanente e não volta a consultar o servidor; é assim que a especificação HTTP funciona. Até que a cache expire ou o utilizador a limpe manualmente, a regra antiga mantém-se em vigor.

Abaixo encontra uma estratégia clara: como testar redireccionamentos sem consequências, porque é que o 302 lhe poupa os nervos durante a depuração e o que fazer se a cache já estiver bloqueada para os visitantes reais.

💡 Resumo rápido:

• Comece sempre com 302 (temporário), teste e só depois mude para 301 (permanente)
• Limpe a cache do browser sempre que alterar as regras de redireccionamento
• Para o Chrome: DevTools → Network → Disable cache, ou separador Application → Clear site data
• Se um 301 já estiver em cache pelos utilizadores, só pode esperar ou alterar o URL de destino

Como o browser guarda em cache um redireccionamento 301

Quando o servidor responde com o estado 301 Moved Permanently, o browser interpreta-o literalmente: «este URL mudou-se para sempre». Ele armazena o par «URL antigo → URL novo» na sua própria cache de redireccionamentos, separada da cache de páginas e imagens.

Da próxima vez que o utilizador (ou você, o programador) abrir o mesmo endereço, o browser não envia qualquer pedido ao servidor. Ele substitui imediatamente o URL de destino guardado na cache. O servidor não vê nenhum pedido e você não vê o comportamento atual.

A especificação HTTP não define um período de retenção rigoroso para esta cache. Na prática, o Chrome, o Firefox e o Safari mantêm o 301 em cache até que seja explicitamente limpo. O cabeçalho Cache-Control do servidor pode ser ignorado pelo browser especificamente para o 301, porque «permanentemente» significa permanentemente.

Este comportamento é uma funcionalidade, não um defeito. Poupa um ciclo de ida e volta em mudanças permanentes legítimas (por exemplo, uma mudança de domínio). No entanto, durante o desenvolvimento, torna-se uma armadilha.

Porque é que isto causa problemas durante a configuração

Imagine um cenário. Está a configurar um redireccionamento do URL antigo /old-page para /new-page. Configura um 301, testa-o no browser e funciona. Uma hora depois, percebe que cometeu um erro: o URL correto é /new-page/v2.

Altera a regra no servidor e clica em «atualizar» no browser. Volta a aterrar em /new-page. Porque o browser já memorizou o primeiro par e não dá ao servidor a oportunidade de mostrar a nova regra.

Pensa que o redireccionamento não está a funcionar. Na realidade, está a funcionar, só que não é o que acabou de configurar.

Num site de testes, já passámos meia hora a percorrer regras do .htaccess até percebermos que o browser estava a mostrar a cache. Limpámos a cache e tudo funcionou imediatamente como pretendido.

A situação é pior com os visitantes. Se ativou um 301 incorreto num site de produção, todos os que o visitaram durante esses minutos receberam a regra errada na cache do browser. Corrigiu o erro no servidor em 10 minutos, mas os browsers deles continuarão a enviá-los para o URL antigo durante dias ou semanas, até que a cache seja limpa.

Nota: não pode limpar a cache de redireccionamentos do lado do utilizador. Nenhum truque de servidor consegue alcançar o browser de outra pessoa.

A estratégia 302 → 301: testar sem consequências

Uma regra que poupa horas de depuração e protege contra erros num site ativo:

Comece sempre com um redireccionamento 302 (temporário). Mude para 301 apenas quando tiver a certeza de que a regra está correta.

O browser não guarda o 302 em cache de forma agressiva; consulta o servidor novamente a cada pedido. Altere a regra no servidor e o browser adota imediatamente o novo comportamento. Sem necessidade de limpar a cache.

Abordagem passo a passo para qualquer alteração de URL:

• Configure um redireccionamento 302 no .htaccess, na configuração do Nginx ou através de um plugin do WordPress (por exemplo, Redirection).
• Abra o URL antigo em modo de navegação anónima ou com a opção «Disable cache» ativada nas DevTools.
• Confirme que aterra na página de destino correta.
• Verifique 2 a 3 URLs adicionais do mesmo grupo.
• Só quando tudo estiver testado, substitua 302 por 301 nas regras.
• Faça uma verificação final no modo normal do browser.

Na prática, esta abordagem demora exatamente dois minutos extra por grupo de redireccionamento e elimina completamente o risco de um «erro em cache» para os visitantes.

Se usar o plugin Redirection para WordPress, ele cria 301 por predefinição. Mude manualmente para 302 no menu suspenso ao criar uma regra e não se esqueça de voltar a mudar para 301 após o teste.

Como limpar a cache de redireccionamentos localmente

Quando o browser já memorizou um 301 incorreto e não consegue ver o comportamento atual, eis o que ajuda:

Chrome. Abra as DevTools (F12), vá ao separador Network e marque Disable cache. Ou faça uma reinicialização completa: Application → Clear storage → Clear site data. O método mais fiável para um site específico é chrome://settings/clearBrowserData → Cached images and files.

Firefox. Web Developer Tools → Network → Disable Cache. Para uma limpeza completa: History → Clear Recent History → Cache.

Safari. Develop → Disable Caches (o menu Develop é ativado em Settings → Advanced).

Modo de navegação anónima é uma forma rápida de verificar o comportamento atual sem limpar a cache principal. O browser usa uma sessão limpa, sem redireccionamentos guardados.

Nuance importante: fechar o browser NÃO limpa a cache de redireccionamentos 301. Ao contrário do armazenamento de sessão, a cache de redireccionamentos sobrevive aos reinícios do browser. Apenas a limpeza explícita ou o modo de navegação anónima funcionam.

O que fazer se a cache estiver bloqueada para os utilizadores

Este é o cenário mais desagradável: um 301 incorreto esteve ativo no site de produção durante algum tempo e parte da sua audiência transporta-o agora na cache do browser. Corrigiu a regra do servidor, mas estes utilizadores continuam a aterrar no local errado.

Eis o que pode fazer:

• Altere o URL de destino para um novo. Se o location antigo apontava para /page-v1 e precisa de /page-v2, basta substituir o endereço na mesma regra. Os browsers com o URL de destino antigo em cache continuarão a ir para lá (o problema). No entanto, os novos visitantes irão para o local certo. Isto não resolve o problema para quem já está «infetado», mas impede a propagação.

• Use um método de redireccionamento diferente. Se o 301 está em cache, o browser não consulta o servidor, mas a lógica do servidor continua a funcionar para novos visitantes. Adicione um redireccionamento em JavaScript na página de destino como uma camada adicional sobre o redireccionamento HTTP para aqueles que ainda aterram na página antiga.

• Reconheça honestamente: não há uma cura direta. Não pode alcançar o browser do utilizador. Se a cache já está carregada, a única forma de a repor é o utilizador limpar a cache ou visitar através de um link em modo anónimo. Felizmente, a cache de redireccionamentos não dura para sempre: a reinstalação do browser, as mudanças de dispositivo e as atualizações do sistema operativo acabam por repô-la.

Na nossa experiência, um 301 incorreto torna-se crítico apenas em dois casos: uma migração em massa (centenas de URLs) com um erro nas regras, ou um redireccionamento da página inicial. Em ambos os casos, o prejuízo de um erro em cache supera qualquer tempo poupado por saltar os testes.

301, 302, 307, 308: Quando usar cada um

Para evitar confusões, mantenha esta tabela rápida de códigos de redireccionamento à mão:

Para um site WordPress, conhecer a diferença entre 301 e 302 é suficiente na grande maioria dos casos. Os códigos 307 e 308 são ferramentas de nicho para situações em que preservar o método HTTP é crítico (por exemplo, um formulário deve permanecer um pedido POST e não transformar-se em GET durante o redireccionamento).

Resumindo: o 302 é a sua ferramenta de trabalho durante o desenvolvimento. O 301 é o carimbo final de «concluído».

Mais uma armadilha: WordPress e plugins de cache

No WordPress, o problema da cache do 301 acumula-se sobre a cache do servidor e dos plugins. Uma situação típica:

Edita um redireccionamento no plugin Redirection, clica em «guardar» e não funciona. Limpa a cache do browser e continua a aparecer a página antiga. O que está a acontecer? Um plugin de cache (WP Rocket, LiteSpeed Cache, W3 Total Cache) serviu uma versão em cache da página; o servidor nunca chegou a executar a regra de redireccionamento.

Passos para depurar redireccionamentos no WordPress:

• Limpe a cache do plugin de cache (cada plugin tem o seu próprio botão «Purge All Cache»).
• Desative a cache durante os testes (no WP Rocket, é o Development Mode).
• Limpe a cache do browser (como descrito acima).
• Só depois teste o redireccionamento.

Num site de testes, mantemos o plugin de cache desativado até que todos os redireccionamentos estejam totalmente prontos e ativamo-lo apenas após a mudança final de 302 para 301.

Este pequeno vídeo em inglês demonstra visualmente a diferença entre 301 e 302 na prática e explica porque é que a escolha do código de redireccionamento afeta o SEO:

⁉️🤔 Perguntas frequentes

Porque é que o browser guarda o 301 em cache em vez de consultar o servidor sempre?

A especificação HTTP define o 301 como «o recurso foi movido permanentemente». Consultar o servidor sempre que o URL é aberto contradiria o significado de «permanentemente» e criaria carga desnecessária. Colocar o redireccionamento em cache poupa um pedido HTTP por visitante. Numa escala de dezenas de milhares de visitas, isto acelera visivelmente a navegação. O browser guarda em cache o facto do redireccionamento em si (o par «de → para»), não o conteúdo da página. Este é um tipo de cache separado, chamado cache de redireccionamento. O Chrome armazena-a no perfil do utilizador; o Firefox armazena-a no ficheiro places.sqlite juntamente com o histórico de navegação. É por isso que limpar a cache de imagens e scripts nem sempre repõe os redireccionamentos; precisa de uma limpeza completa ou de limpar os dados do site.

É possível impedir o browser de guardar o 301 em cache do lado do servidor?

Formalmente, não. Os browsers podem ignorar o cabeçalho Cache-Control: no-store para redireccionamentos permanentes. A especificação não exige que os browsers respeitem o Cache-Control para 301/308, uma vez que um redireccionamento permanente implica que a regra não mudará. Algumas versões do Chrome e do Firefox respeitam o Cache-Control para 301, mas não pode confiar nisso em produção; o comportamento não é garantido e varia entre versões. A única forma fiável de «desfazer» a cache do browser de um 301 é usar inicialmente o 302 durante os testes. Se um 301 já estiver em cache pelo utilizador, o servidor está impotente.

Como é que o 302 difere do 307 na prática?

Ambos são redireccionamentos temporários e nenhum é guardado em cache pelo browser. A diferença reside no tratamento do método HTTP. Com o 302, o browser pode alterar um pedido POST para GET durante o redireccionamento (isto aconteceu historicamente e muitos browsers ainda o fazem). Com o 307, o método é garantidamente preservado: POST permanece POST, PUT permanece PUT. Para o WordPress e praticamente qualquer site, a diferença é insignificante, uma vez que os redireccionamentos envolvem quase sempre pedidos GET (abertura de página). O 307 só é necessário se formulários, APIs ou uploads de ficheiros passarem por um URL que está a redirecionar temporariamente.

Como posso verificar qual o redireccionamento que está em cache no meu browser?

Abra as DevTools (F12) → separador Network e marque «Disable cache» (isto é OBRIGATÓRIO, caso contrário o browser não fará um pedido ao servidor e não verá a resposta atual). Depois abra o URL antigo. Na coluna Status, verá o código de resposta real do servidor (301, 302, etc.) e o cabeçalho Location com o URL de destino. Sem «Disable cache», as DevTools mostrarão um estado 200 ou (disk cache), o que significa que o browser serviu a partir da cache e o servidor não foi consultado.

É necessário manter um redireccionamento 301 para sempre?

O Google recomenda manter os redireccionamentos permanentes durante pelo menos um ano após uma mudança. Na prática, se o URL antigo já não for promovido, não tiver links externos e não estiver indexado, o redireccionamento pode ser removido após 6 a 12 meses. No entanto, se outros sites criaram links para o URL antigo ou se este estiver presente nos índices dos motores de busca, deve manter o redireccionamento permanentemente. Remover um 301 com uma regra em cache pelos utilizadores não resolverá o problema; os browsers deles continuarão a usar o par em cache até limparem a cache.

Deve ter medo dos redireccionamentos 301?

Não, se seguir a regra do «302 primeiro». Um redireccionamento permanente é uma ferramenta fiável para mover conteúdo, mudar de domínios e limpar duplicados. Os problemas só surgem quando o 301 é configurado sem testes.

Lembre-se do ponto-chave: o 301 é uma promessa ao browser de que «não vou mudar de ideias». Não faça essa promessa até ter a certeza. Dez minutos a testar um redireccionamento 302 em modo de navegação anónima pouparão dias a limpar erros em cache para a sua audiência real.