Mantener un mapa de redirecciones durante años: un archivo fuente, reglas generadas, pruebas y retiro

Objetivo

Que las URL antiguas sigan funcionando a través de rediseños, cambios de dominio y migraciones de CMS, sin que la configuración de redirecciones se convierta en un montón ilegible que nadie se atreve a editar.

Requisitos previos

Un repositorio versionado para la configuración del sitio, un servidor web o proveedor de hosting cuyas reglas de redirección se puedan generar a partir de datos (un map de nginx, un archivo de redirecciones de un proveedor de hosting, o una función de borde), registros de acceso que registren códigos de estado y rutas de solicitud, y el artículo sobre estados de redirección para elegir entre 301, 302, 307 y 308.

Pasos

1. Crear un único archivo fuente (CSV, YAML o una tabla en el repositorio) con columnas: ruta origen, URL destino, código de estado, motivo, fecha de alta, ticket o commit. No se redirige nada que este archivo no liste.
2. Generar las reglas del servidor a partir de él. Con nginx, un map crea una variable cuyo valor depende del URI de la solicitud, y la documentación señala que declarar muchas variables map no cuesta nada hasta que la variable se usa; incluir (include) el archivo generado y emitir return 301 $target; cuando la variable no esté vacía; return toma un código literal, así que hay que generar un map por cada código de estado. Otros proveedores de hosting obtienen su formato nativo del mismo generador.
3. Normalizar antes de comparar: convertir el host a minúsculas, eliminar las barras finales de forma coherente con las reglas de URL del sitio, y conservar la cadena de consulta solo donde el destino la necesite.
4. Elegir los códigos según la intención. La documentación de Google indica usar redirecciones permanentes cuando se está seguro de que la redirección no se revertirá, porque entonces una redirección permanente se usa como señal de que el destino debería ser la página canónica, mientras que una temporal no; usar códigos temporales para campañas y mantenimiento.
5. Añadir una prueba que solicite cada ruta origen y compruebe que la primera respuesta tiene el estado y el Location esperados, y que el destino responde 200 sin más redirecciones. Ejecutarla en CI en cada cambio y de forma programada.
6. Cuando un destino se traslada a su vez, reescribir las entradas antiguas para que apunten al destino final; nunca dejar que las entradas se encadenen.
7. Retirar por evidencia: una entrada que no se ha usado durante un período largo, comprobado en los registros, puede eliminarse; registrar la eliminación y la ventana de registros en el historial del archivo. Las entradas procedentes de material impreso o de enlaces externos con vida útil desconocida se mantienen.

Resultado esperado

Cada redirección está explicada, probada y accesible en un solo salto; una migración añade filas a un archivo y una ejecución de CI, no expresiones regulares escritas a mano.

Límites y base de verificación

Las redirecciones por patrón (árboles de directorios completos) siguen necesitando algunas expresiones regulares; mantenerlas en el mismo archivo con una prueba por patrón. Los períodos de retención son un juicio, no una medición; la hipótesis enlazada trata sobre las cadenas, y aquí no se afirma ninguna cifra.