Redirects y 404

Cuando una URL de tu site devuelve 404, usualmente es una de estas: el contenido no está publicado (o no está publicado *aún*), el modo de URL o el ruteo de idiomas cambió, un redirect no puede hacer su trabajo, o la petición fue por algo excluido a propósito de tu salida estática. Esta página recorre cada caso, y cuándo corregirlo en el admin versus la configuración del servidor.

El contenido no se construye hasta que le toca

Solo el contenido publicado y no borrado se genera. Si una página programa publicación en el futuro, o una fecha de unpublish ya pasó, la página simplemente no se construye . así que su URL es un 404 hasta el próximo build después de que se vuelva elegible. Tras cambiar el estado de publicación o una ventana de programación, haz rebuild.

Desajustes de ruteo de idiomas

El comportamiento de las URLs depende del Language URL Mode (Settings → Permalinks), que es también donde empieza una clase común de 404:

• Si configuras none (sin segmentos de idioma) pero hay más de un idioma, el builder lo anula a modo path y avisa en el build log. Si estás viendo paths inesperados estilo /en/…, revisa este setting.
• En modo subdominio, las URLs son subdominios de idioma (como es.yourdomain.com), pero los archivos todavía se construyen en directorios output/{lang}/. Tu servidor debe rutear cada subdominio a su directorio de idioma; olvidarlo hace que el subdominio dé 404 o sirva el idioma equivocado.
• Un modo de URL obsoleto en un site monolingüe . por ejemplo modo path cuando solo existe un idioma . produce 404 para los paths por defecto. Limpia el modo (o define el modo correcto) y reconstruye.

El builder imprime advertencias y notas sobre estas situaciones exactas en la salida de build, así que abre el build log primero cuando las URLs de idioma se comportan raro.

La URL raíz redirige a una página equivocada

A dónde apunta la raíz del dominio lo define home_redirect (Settings → Permalinks). Si el slug que nombras no es una página publicada, el build log advierte "no published page with this slug found.", y la redirección de la raíz deja de funcionar correctamente. Corrige el setting o publica/restaura la página destino, luego reconstruye.

Redirects que silenciosamente no aplican

Los redirects aplican solo a paths viejos que no contienen ya contenido publicado. Si una página o post todavía vive en el slug viejo, sigue sirviendo 200 esa URL y el redirect se salta . el build log igualmente lo marcará con la advertencia "old slug is still active" que el admin muestra al crear semejante redirect. Para que un redirect gane, despublica o borra primero la página vieja (o conserva el redirect y el contenido no publicado cambiando el estado de publicación).

Los redirects tienen que estar activos (el checkbox active en la pantalla de redirects). Solo los redirects activos generan salida de redirect en build time; un redirect desactivado desaparece de la salida estática hasta que lo actives (activar dispara un build).

Los formatos restrictivos ganan: los redirects simples usan el código 301/302/307 que elegiste y se aplican en la config de redirects generada del servidor; los pattern redirects (slug viejo terminado en * con sustitución $1 en el destino) funcionan solo como páginas HTML de redirect en el build estático, y se saltan en las configuraciones de servidor generadas.

Cuando el propio 404 está roto

El site estático incluye una página 404 construida. Si esa página falla al renderizar en un build, el build log registra una línea de error por ella pero continúa . el site siguió en pie, mientras que un 404 custom faltante deja la respuesta plana "Page not found" de tu servidor al mando hasta el próximo build bueno.

Los probes no reciben el 404 regular

La configuración de servidor de fábrica enruta paths comunes de probes de ataque . archivos de settings, paths de control de versiones, URLs de admin de otras plataformas . a través de un proxy que no tiene nada que ver con tu salida estática, en lugar de servir tu página normal de 404. Si ves 404s registrados para esos paths exactos, son probes, no enlaces rotos.

Por qué un 404 puede destellar brevemente durante deploys

La publicación intercambia la salida atómicamente. Cuando la ubicación del contenido vivo es un symlink, ir a vivo es un unique rename atómico . cero downtime. De lo contrario es un rename de dos pasos en el mismo filesystem, con un gap breve entre los dos renames durante el cual una petición podría golpear un directorio faltante. En cualquiera de los dos casos un swap o aterriza por completo o la salida anterior queda en su lugar . nunca un site parcialmente escrito.

A dónde ir después

Una vez que sabes que una URL debería existir pero da 404, despublica o borra la página vieja, publica la nueva, y crea un redirect desde el path registrado usando el enlace *Create redirect* por fila del monitor de 404s o la selección en bloque (Admin → Health → pestaña 404s). El log de 404 registra los paths faltantes con conteos de hits y URLs de referencia para que puedas priorizar las correcciones.