Manter um mapa de redirecionamentos ao longo dos anos: um arquivo-fonte, regras geradas, testes e aposentadoria

Objetivo

Fazer com que URLs antigas continuem funcionando após redesigns, trocas de domínio e migrações de CMS, sem que a configuração de redirecionamento vire um amontoado ilegível que ninguém tem coragem de editar.

Pré-requisitos

Um repositório versionado para a configuração do site; um servidor web ou uma hospedagem cujas regras de redirecionamento possam ser geradas a partir de dados (map do nginx, um arquivo de redirecionamentos do provedor de hospedagem ou uma edge function); logs de acesso que registrem códigos de status e caminhos das requisições; e o artigo sobre status de redirecionamento, para escolher entre 301, 302, 307 e 308.

Passos

1. Crie um único arquivo-fonte (CSV, YAML ou uma tabela no repositório) com as colunas: caminho de origem, URL de destino, código de status, motivo, data de inclusão e ticket ou commit. Nada é redirecionado se não estiver listado nesse arquivo.
2. Gere as regras do servidor a partir dele. No nginx, um map cria uma variável cujo valor depende da URI da requisição, e a documentação observa que declarar muitas variáveis de map não tem custo até que a variável seja usada; use include no arquivo gerado e emita return 301 $target; quando a variável não estiver vazia. Como return aceita apenas um código literal, gere um map por código de status. Outras hospedagens recebem o formato nativo delas a partir do mesmo gerador.
3. Normalize antes de comparar: converta o host para minúsculas, remova as barras finais de acordo com as regras de URL do site e preserve a query string apenas onde o destino precisar dela.
4. Escolha os códigos pela intenção. A documentação do Google diz para usar redirecionamentos permanentes quando você tem certeza de que o redirecionamento não será revertido, pois um redirecionamento permanente passa a ser usado como sinal de que o destino deve ser a página canônica, o que não acontece com um temporário; use códigos temporários para campanhas e manutenção.
5. Adicione um teste que requisite cada caminho de origem e verifique se a primeira resposta tem o status e o Location esperados e se o destino responde 200, sem novos redirecionamentos. Execute-o no CI a cada alteração e também em intervalos programados.
6. Quando um destino for movido, reescreva as entradas antigas para apontar para o destino final; nunca deixe as entradas formarem cadeias.
7. Aposente com base em evidências: uma entrada que não recebe acessos há muito tempo, conferida nos logs, pode ser removida; registre a remoção e o período de logs analisado no histórico do arquivo. Entradas vindas de material impresso ou de links externos com vida útil desconhecida permanecem.

Resultado esperado

Todo redirecionamento é explicado, testado e alcançável em um único salto; uma migração passa a significar novas linhas em um arquivo e uma execução do CI, não expressões regulares escritas à mão.

Limites e base de verificação

Redirecionamentos por padrão (árvores inteiras de diretórios) ainda exigem algumas expressões regulares; mantenha-as no mesmo arquivo, com um teste por padrão. Os períodos de retenção são uma questão de julgamento, não de medição; a hipótese relacionada trata de cadeias, e aqui não se afirma nenhum número.