404 Not Found: enlaces rotos, 404 suaves y cuándo usar 410

Qué te dice y qué no te dice un 404

Según el RFC 9110, un 404 significa que el servidor de origen no encontró una representación actual para el recurso solicitado, o no está dispuesto a revelar que existe una. De esa redacción se siguen dos detalles.

Primero, un 404 es deliberadamente evasivo sobre la permanencia. No promete que la URL vaya a seguir muerta, por eso los rastreadores siguen reintentando las URLs 404 durante mucho tiempo. Segundo, el 404 se puede cachear por defecto según el RFC 9111, así que un proxy de caché o una CDN puede guardar el error y seguir sirviéndolo después de que hayas arreglado el problema de fondo. Purga siempre la caché tras arreglar un 404 y vuelve a probar.

Un 404 también es una respuesta normal y sana. Todos los sitios devuelven algunos. Los que merecen tu tiempo son los de URLs que deberían funcionar, o los de URLs que la gente está intentando alcanzar.

¿Enlace roto o eliminación genuina?

Estos dos casos se ven idénticos en un código de estado y necesitan respuestas opuestas.

Un enlace roto significa que el contenido existe pero la URL está mal. Las causas habituales son una errata en un enlace interno, un slug editado después de publicar, un desajuste de mayúsculas/minúsculas, una diferencia en la barra final, una migración de sitio que cambió el esquema de URL, o un despliegue que dejó de generar un archivo. La solución es restaurar la URL o redirigirla.

Una eliminación genuina significa que el contenido ha desaparecido y no va a volver: una oferta de empleo caducada, un producto descontinuado, la página de una cuenta eliminada. Aquí un 404 es honesto pero perezoso, porque deja a los rastreadores reintentando y a los visitantes sin nada.

Una forma práctica de distinguirlos: ¿existe hoy una página equivalente en algún sitio del sitio? Si sí, redirige. Si no, decide entre 404 y 410.

410 Gone, la alternativa honesta

410 dice que el recurso estuvo disponible y se ha eliminado a propósito, y se espera que la situación sea permanente. Donde 404 significa "no encontrado", 410 significa "eliminado a propósito, deja de preguntar".

Usa 410 cuando retiras deliberadamente contenido y no tienes ningún reemplazo. Es la señal correcta para ofertas caducadas, páginas de producto retiradas y contenido eliminado por motivos legales o editoriales. Los buscadores por lo general tratan el 410 como una señal de eliminación más fuerte y rápida que el 404, aunque los dos acaban descartando la URL. Como el 404, el 410 se puede cachear por defecto.

No uses 410 para nada que puedas restaurar, y no lo uses como manejador general para URLs desconocidas. Si existe una página de reemplazo adecuada, una redirección es mejor que cualquiera de los dos códigos, y la elección de redirección importa: consulta 301 frente a 302 para elegir la correcta.

404 suaves y por qué se les escapan a los monitores

Un 404 suave es una página que devuelve 200 OK mientras su contenido dice que el recurso no está. Ocurre cuando una aplicación atrapa su propia condición de no-encontrado y renderiza una plantilla amistosa de "página no encontrada" sin fijar el código de estado, o cuando una ruta general sirve la página de inicio para cada URL sin coincidencia.

Los buscadores y los monitores de uptime leen entonces la misma página en sentidos opuestos. Google inspecciona el contenido renderizado, reconoce el patrón de contenido ausente y lo clasifica como 404 suave en Search Console, así que la URL no se indexa pero el presupuesto de rastreo se sigue gastando en ella y la señal queda confusa. Un monitor que compara códigos de estado ve un 200 y reporta la página como sana, que es cómo una sección entera puede servir un texto de "no encontrado" a cada visitante mientras el panel se mantiene en verde.

La solución en el sitio es devolver un 404 real con la página de error, lo que no cuesta nada y satisface a los dos lectores. La solución en la monitorización es hacer una aserción sobre el contenido además del estado: comprueba que una frase conocida de la página real está presente, para que una página que devuelve 200 con el cuerpo equivocado siga fallando la comprobación.

Cómo arreglar los 404 en el orden correcto

1. Confirma el código real, no la página visible. Una pantalla de error amistosa no demuestra nada:

   curl -sS -o /dev/null -w "%{http_code}\n" https://example.com/missing-page

   Si eso imprime 200 para una página que dice "no encontrado", tienes un 404 suave.
2. Encuentra qué URLs se están pidiendo. Los registros de acceso del servidor y Search Console listan ambos las URLs 404 con su volumen. Arregla por tráfico, no por orden alfabético.
3. Arregla primero los enlaces internos. Un 404 al que se llega desde tu propia navegación está enteramente bajo tu control y es la corrección de mayor valor.
4. Redirige donde exista un equivalente real. Asigna la URL antigua a la página actual más cercana, una URL cada vez. Evita redirigir todo a la página de inicio, que los buscadores también tratan como un 404 suave.
5. Devuelve 410 para las eliminaciones deliberadas sin reemplazo, para que los rastreadores dejen de reintentar.
6. Haz útil la página de 404. Una búsqueda, la navegación principal y los enlaces populares recuperan visitantes que pierde una página de error desnuda.
7. Purga las cachés y vuelve a probar. Como el 404 se puede cachear, verifica la URL corregida desde fuera de tu red, no solo desde el origen.

Comprobar el código y el contenido juntos

Un cambio de slug, una actualización de plugin o un cambio de enrutamiento rompe un conjunto de URLs mientras la página de inicio sigue cargando, así que nada avisa y nadie lo nota hasta que caen el tráfico o las conversiones. Una comprobación HTTP programada sobre tus URLs importantes compara tanto el código de estado como el contenido esperado de la página, lo que detecta por igual un 404 real y uno suave. Para la familia más amplia de códigos del lado del cliente, y para distinguir un error genuino del cliente de una mala configuración del servidor, consulta el resumen de la familia 4xx.