Qué significa un error 404, y por qué los peligrosos son invisibles

Un 404 es el único error de esta lista que normalmente está funcionando bien. El servidor entendió la petición perfectamente, buscó lo que le pidió, y allí no había nada. Nada se estrelló y nada está mal configurado. Pidió una cosa que no existe, y él lo dijo.

Por eso un 404 en la barra de direcciones rara vez merece que lo persiga. El enlace era viejo, la página se movió, alguien escribió mal. Es el fallo más aburrido de la web.

Los interesantes no llegan nunca a la barra de direcciones.

El 404 que ve frente al 404 que no ve

Cuando escribe una dirección y le sale un 404, el navegador le enseña una página y la historia se acaba. Sabe exactamente qué pasó.

Cuando la página en la que ya está pide algo en segundo plano y recibe un 404, nada se lo dice. Una hoja de estilos que no llega deja la maquetación con aspecto roto pero renderizada. Un script que da 404 significa que una función no hace nada en silencio. Un fetch de datos devuelve un cuerpo 404 que el código intenta analizar como JSON, y lo que sale a la superficie es un TypeError, a varios pasos del problema real.

Esta es la versión que produce el informe que todo desarrollador ha leído: “la página se ve rara”, o “el botón no hace nada”. Ningún mensaje de error, porque no hubo página de error. El fallo ocurrió en el registro de red, y nadie estaba mirando el registro de red.

Doscientas peticiones pueden componer una página moderna. Cualquiera de ellas puede dar 404 sin detener a las otras ciento noventa y nueve.

Por qué un 404 en segundo plano suele significar un despliegue

Un 404 en la barra de direcciones es el enlace de alguien. Un 404 en un recurso que la propia página pidió es casi siempre el build.

Un archivo renombrado o con huella. Los pipelines de assets meten un hash del contenido en el nombre del archivo. Si el HTML está cacheado y apunta al hash viejo mientras el despliegue nuevo envió otro, el navegador pide un archivo que de verdad ya no existe. Esto se aclara solo para casi todos al recargar y persiste para quien tenga una página cacheada, que es por lo que tantas veces lo reporta una persona y nadie más lo reproduce.

Un archivo que nunca se subió. Un paso del build que falló en silencio, un asset excluido por un cambio de configuración, una ruta que funciona en local por sistemas de archivos que ignoran mayúsculas y falla en un servidor Linux porque Logo.svg no es logo.svg.

Una ruta de API que se movió. El front y el back se desplegaron con un poco de desfase, y durante unos minutos uno pide un endpoint que el otro ya renombró.

Los tres son invisibles desde la página. Los tres son una línea en un registro de red.

Los soft 404, que son peores que los 404

Un soft 404 es una página que le dice a un humano que no encontró nada mientras le dice a toda máquina que todo va bien: un amable “lo sentimos, aquí no hay nada” servido con un 200 OK.

Esa combinación es dañina de una manera en que un 404 de verdad no lo es. Los buscadores la indexan como página que funciona, así que el contenido que falta se queda en los resultados. La monitorización no salta nunca, porque la monitorización cuenta códigos de estado. Y cualquier código que compruebe response.ok antes de analizar toma la página de error como datos y falla más adelante, con un mensaje sobre la forma del JSON en vez de sobre que la página no está.

Si se lleva una cosa de esta página: una página de error tiene que devolver un estado de error. Un mensaje que un humano pueda leer y un código de estado veraz no son alternativas.

El 404 frente a los códigos con los que se confunde

404 Not Found

La petición estaba bien y no hay nada en esa dirección. No dice nada sobre si alguna vez lo hubo

410 Gone

Aquí había algo y se ha eliminado deliberada y permanentemente. Los buscadores lo descartan antes

403 Forbidden

Existe y usted no tiene permiso. Algunos sitios devuelven 404 en su lugar, a propósito, para que nadie pueda mapear lo que existe a base de probar

400 Bad Request

El servidor no pudo analizar la petición en absoluto, así que nunca llegó a mirar

Esa tercera fila merece la pena saberla cuando depura la API de otro: un 404 sobre un recurso que está bastante seguro de que existe puede ser un 403 disfrazado, que esconde la existencia de la cosa a quien llama sin autorización. Compruebe si está autenticado antes de dar el registro por desaparecido.

Si el sitio es suyo

Arreglar el 404 que tiene delante es la mitad fácil. El trabajo útil es encontrar los que nadie reporta.

El log de acceso del servidor tiene todos y cada uno con la URL y el referrer, y el referrer es la parte que la gente se salta. Le dice cuál de sus propias páginas enlaza a algo que falta, lo que convierte una lista de 404 en una lista de bugs. Search Console hace lo mismo con todo lo alcanzable desde fuera.

Luego decida qué debe ser cada uno. Una página movida quiere una redirección a lo que la sustituyó, no a la portada, que los buscadores tratan como soft 404 y los lectores viven como que los ignoran. Algo borrado de verdad quiere un 410. Una errata que nadie enlaza no quiere nada: los 404 son normales, y un sitio sin ninguno es un sitio redirigiendo cosas que no debería.

Por qué los invisibles son difíciles de reportar

Un 404 en segundo plano deja a quien lo ve sin nada que describir. Tiene una página con mal aspecto, ningún mensaje de error, y ninguna razón para pensar que un archivo no cargó. Así que el informe es “se ve roto en mi máquina”, y el desarrollador abre la página, la ve funcionar, y cierra el ticket.

El registro de red es toda la diferencia aquí. Un 404 sobre una petición que hizo la página es invisible en pantalla y evidente en el registro, así que un informe que lo lleve convierte “se ve raro” en un nombre de archivo y un número de línea. Eso suele ser toda la investigación.

En un párrafo

Un 404 significa que el servidor le entendió y no tiene nada en esa dirección, lo que lo convierte en el único error que normalmente se está comportando bien. Los de la barra de direcciones son el enlace caduco de alguien y rara vez importan. Los que importan son las peticiones que una página hace en segundo plano, donde una hoja de estilos, un script o una ruta de API que faltan producen una página con mal aspecto y sin ningún mensaje de error, y casi siempre se remontan a un despliegue: un nombre de archivo con huella, un archivo que nunca se subió, o una ruta que se movió. Sirva los 404 de verdad con un estado 404 en vez de con un amable 200, porque un soft 404 engaña a los buscadores y a la monitorización a la vez. Y si está persiguiendo uno, el referrer de su log de acceso es lo que convierte una lista de URLs que faltan en una lista de páginas que enlazan a ellas.