Redirecciones

Cuando renombras una página o post, no quieres que los enlaces viejos se rompan. Chinaski mantiene las URLs viejas funcionando con redirects, y esta página explica cómo se crean, cómo se comportan y los formatos de exportación para tu host.

Cómo funcionan los redirects

Tu site publicado es HTML estático, así que Chinaski implementa los redirects de dos maneras:

1. En la URL vieja, el site entrega una página diminuta que le dice al navegador "este contenido se movió" y manda al lector directo a la nueva ubicación, con un enlace apropiado cuando JavaScript está apagado. Los motores de búsqueda ven un enlace canonical apuntando a la URL nueva, así que las páginas viejas no compiten con las nuevas en los resultados.
2. Un archivo de reglas de redirect: generado en cada build: que tu proxy de hosting puede leer (ver formatos de exportación abajo), para que los servidores modernos puedan responder con un redirect apropiado en lugar de la página de fallback.

Los redirects son por idioma: cada slug viejo pertenece a un idioma específico, y apunta al destino en ese mismo idioma.

El contenido vivo siempre gana: si ya existe una página o post publicados en el slug viejo, no se genera ningún redirect para él: el contenido mismo se sirve.

Lo que pasa automáticamente

Normalmente no gestionas los redirects a mano:

• Renombrar el slug de una página o post publicados crea un redirect para la URL vieja automáticamente.
• Cambiar el prefijo de URL de los posts del blog (por ejemplo mover /journal/ a /blog/) redirige automáticamente cada post publicado desde su ruta de prefijo vieja.
• La raíz del site redirige a tu índice del blog o a tu página de inicio elegida si no existe una página raíz.
• Canonicalización del dominio: si tu site URL es example.com, se genera una regla que manda el tráfico de www.example.com (o viceversa): correcto para que los motores de búsqueda solo indexen una ortografía de tu dominio.

Crear un redirect manualmente

La sección Redirects del área de administración te permite añadir uno manualmente. Lo que suministras:

• El slug viejo y el slug nuevo (donde deben aterrizar los enlaces viejos).
• El idioma al que aplica.
• El tipo: página o post.
• Notas opcionales, un flag de activo y un código de estado (301/302/307).

La validación te respalda:

• Slug viejo, slug nuevo e idioma son requeridos, y un redirect no puede apuntar a sí mismo.
• No puedes crear dos redirects para el mismo slug viejo en el mismo idioma.
• Las cadenas se colapsan: si el destino de tu nuevo redirect ya tiene su propio redirect, tu redirect se reescribe al destino final: así los lectores no rebotan por varios saltos. Si esto devolvería al slug viejo, el redirect se rechaza como circular.

Antes de guardar, puedes probar un par candidato de slug-viejo/slug-nuevo: la prueba reporta el destino final, la cadena completa de redirects que recorrería, si forma un bucle, y si la URL vieja tiene actualmente contenido vivo.

Redirecciones por patrón

Para migrar una sección entera de una vez, usa un redirect de patrón: un slug viejo terminando en (como products/) coincide con cada slug de contenido con ese prefijo. Un placeholder $1 en el slug nuevo pasa el resto coincidente: por ejemplo, products/* → catalogue/item-$1 mapea products/red-sweater a catalogue/item-red-sweater. Los patrones funcionan en la salida del site estático; aparecen solo ahí y en el editor de redirects, no en los archivos de exportación del host (la sintaxis de patrones de cada host difiere).

Acciones en lote en el área de administración

Desde la lista de redirects puedes seleccionar varias entradas y eliminarlas, activarlas o desactivarlas en una sola acción; el site se reconstruye después para que los redirects surtan efecto.

El 404 log sirve también como fuente de redirects: las rutas que han estado ausentes del site (según el log de 404 agregado) pueden convertirse en redirects en lote: llena el destino de cada fila, envía, y los duplicados se marcan al instante mientras las filas válidas se crean (y se registran en el audit log). Luego se dispara un rebuild.

Gestionar redirects puede estar restringido por tu cuenta: un editor sin "redirects" entre sus tipos de contenido permitidos no obtiene acceso de gestión a esta sección.

Formatos de exportación

Cada build con una site URL establecida escribe dos archivos en la raíz de la salida construida:

• _redirects (formato Netlify): una regla por línea: ruta de origen, URL de destino completa y código de estado. Los hosts y gateways que entienden el formato Netlify pueden servirlos directamente, evitando el rebote de meta-refresh.
• _redirects.caddy (snippet de Caddy): directivas redir listas para incluir en el bloque de site de tu Caddyfile.

Ambos respetan las mismas reglas: solo se exportan los redirects activos, el contenido vivo en el slug viejo se omite, y los cambios de prefijo del blog se incluyen con estado permanente. El forzado del dominio canónico (mandar el host alternativo www/apex a tu dominio canónico) se agrega a _redirects como su propio bloque etiquetado, reescrito limpio en cada build para que builds repetidos nunca dupliquen reglas.

Un matiz: el código de estado que elijas aplica a los servidores que leen los archivos de exportación. La página estática de meta-refresh siempre avanza al instante: el host estático no puede establecer un código de estado personalizado en un archivo HTML plano. Usa un proxy que consuma las exportaciones cuando los códigos exactos (como movimientos temporales, 302/307) importen a los motores de búsqueda.