Error 404 Not Found: qué significa y cómo solucionarlo

Qué significa este error y cómo reconocerlo

• Una página muestra 404, Not Found o un mensaje personalizado de página no encontrada mientras otras páginas del mismo sitio cargan correctamente.
• Una solicitud a una API devuelve un 404 aunque el hostname y el servidor sean accesibles.
• Una URL que antes funcionaba empieza a devolver 404 después de un despliegue, una migración, un cambio de permalinks o una actualización de la aplicación.
• Los resultados de búsqueda, marcadores o enlaces internos llevan a contenido que ya no está disponible.
• Varias rutas sin relación fallan después de un cambio en la configuración del servidor web, el reverse proxy o las reglas de rewrite.

Causas principales, ordenadas por probabilidad

Causas probables, de las más comunes a las menos comunes:

1. URL mal escrita o incompleta: Un error de escritura, un segmento de ruta ausente o un uso incorrecto de mayúsculas y minúsculas apunta a un recurso que no existe.
2. Contenido eliminado o movido: La página o el archivo se eliminó, renombró o reubicó sin una redirección relevante.
3. Enlace interno o externo roto: Un enlace todavía apunta a una URL obsoleta, a menudo después de una migración o un cambio en la estructura de URL.
4. Ruta de aplicación ausente: La aplicación desplegada no define la página o el endpoint de API solicitado, o la ruta utiliza una versión o un prefijo de API incorrectos.
5. Reglas de rewrite o permalink incorrectas: Apache, Nginx, el router de un framework o la configuración de un CMS no consigue enviar una ruta válida al handler previsto.
6. Problema de despliegue o del document root: No se desplegó un archivo, una ruta o el resultado de la compilación, o el servidor está sirviendo un directorio distinto del esperado.
7. Incompatibilidad en el reverse proxy: Un proxy o gateway envía la solicitud a la aplicación o backend equivocado, donde esa ruta no existe.
8. Diferencia en una ruta sensible a mayúsculas y minúsculas: Una URL que funciona en un entorno puede fallar en un sistema de archivos o servidor que distingue mayúsculas y minúsculas cuando su capitalización no coincide con la ruta o el nombre del archivo.

Cómo solucionarlo

Si estás visitando el sitio

1. Comprueba de nuevo la dirección, incluidos la ortografía, el uso de mayúsculas y minúsculas, los guiones, las extensiones de archivo y cada segmento de la ruta.
2. Elimina el último segmento de ruta sospechoso o navega desde la página de inicio del sitio y utiliza la búsqueda integrada para localizar la página actual.
3. Si llegaste a la página mediante un marcador o un resultado de búsqueda, busca una versión más reciente del contenido en lugar de actualizar repetidamente la misma URL.
4. Informa al propietario del sitio sobre el enlace fiable roto e incluye la URL exacta y la página donde lo encontraste.

Si administras el sitio

1. Confirma la solicitud que falla. Registra la ruta exacta, el método HTTP, el host, la cadena de consulta y la hora del fallo. Comprueba si el problema afecta a una URL, a una familia de rutas o a todo el sitio.
2. Determina si el recurso debería existir. Comprueba el registro de contenido, los archivos desplegados o la definición de la ruta de la aplicación. Un recurso eliminado deliberadamente normalmente debe seguir devolviendo 404, salvo que exista una sustitución realmente relevante.
3. Compara una ruta que falla con otra que funciona. Busca diferencias en mayúsculas y minúsculas, barras finales, extensiones de archivo, prefijos de locale, versión de API, prefijo de ruta y gestión de la query string.
4. Revisa la configuración de enrutamiento y rewrite. Examina el router de la aplicación, los permalinks del CMS, las reglas del servidor web, el document root y los mapeos del reverse proxy. Realiza cambios de configuración únicamente con la autorización adecuada, después de conservar la configuración actual y valorar su efecto en otras rutas.
5. Comprueba el despliegue. Confirma que el archivo, el resultado de la compilación, la ruta y los recursos estáticos esperados se incluyeron en la release desplegada y que el servidor activo utiliza la release prevista.
6. Revisa los logs. Utiliza los logs del servidor web, del proxy y de la aplicación para determinar qué componente generó el 404 y si la solicitud llegó al backend esperado. Elimina o anonimiza credenciales, tokens y datos personales antes de compartir los logs.
7. Corrige los enlaces o las redirecciones. Actualiza los enlaces internos para que apunten a la ruta actual. Si el contenido se movió permanentemente, configura una redirección permanente autorizada hacia el destino equivalente más cercano. No redirijas las URL inexistentes sin relación a la página de inicio.
8. Verifica la respuesta de error. Solicita la URL inexistente original y confirma que devuelve el estado HTTP 404. Una página de error personalizada puede ser útil, pero no debe convertir un recurso inexistente en una respuesta 200 exitosa y engañosa.
9. Vuelve a probar las rutas afectadas. Comprueba la URL original, la URL de sustitución si existe, rutas representativas que funcionen y los métodos de API relevantes después del cambio. Supervisa los logs de 404 posteriormente para detectar otros enlaces rotos.

Prevención y cómo verificar la solución

• Ejecuta comprobaciones de enlaces rotos antes y después de migraciones, rediseños y cambios en la estructura de URL.
• Mantén documentadas las redirecciones del contenido importante que se mueva permanentemente.
• Prueba rutas representativas de páginas, recursos y API como parte de cada despliegue.
• Trata la capitalización de las rutas, las barras finales, los prefijos de locale y las versiones de API como decisiones explícitas de enrutamiento.
• Mantén la configuración de enrutamiento del servidor web, el reverse proxy y la aplicación bajo control de cambios.
• Supervisa las rutas 404 solicitadas con frecuencia para identificar enlaces internos rotos, integraciones obsoletas y solicitudes recurrentes de los usuarios.
• Conserva URL estables para el contenido que deba seguir disponible o indexado.
• Asegúrate de que las plantillas de error personalizadas mantengan el estado HTTP correcto.

Preguntas frecuentes