Publicaste una nueva página de marketing, alguien pegó el enlace en Slack y ahora cada clic termina en un callejón sin salida. No un callejón elegante. El 404 por defecto del servidor con un frío “Not Found”, como una puerta cerrada sin letrero ni pomo.
Esto es lo pequeño que cuesta dinero real: los usuarios rebotan, los tickets de soporte se acumulan, los motores de búsqueda se confunden y tu persona de guardia recibe una alerta porque un pico de 404 parece exactamente una caída. Una buena página 404 no es “simpática”. Es prevención de incidentes envuelta en UX.
Para qué sirve realmente una página 404 (y qué no es)
Una página 404 es soporte al cliente, navegación y telemetría en una sola respuesta. Trátala como una superficie operativa, no como arte decorativo de error.
Cuando alguien llega a una URL perdida, te está diciendo una de cuatro cosas:
- Siguió un enlace roto (interno, externo o caché obsoleto).
- Escribió algo parecido (error humano, autocompletado o “juro que antes existía”).
- Un bot está sondeando (crawlers normales, escáneres de seguridad, tonterías oportunistas).
- Tu enrutamiento o despliegue está mal (reglas de reescritura mal configuradas, activos faltantes, despliegue parcial, comportamiento erróneo del CDN).
La tarea del 404 es clasificar esos casos rápidamente: recuperar al usuario si es posible y darte suficientes datos para arreglar la causa raíz. Lo que no debe hacer es pretender que todo está bien. Devolver 200 con un mensaje de error es una trampa para SEO y caché, y complica la resolución porque el “éxito” en métricas oculta el fallo en la realidad.
También hay un contrato social aquí. Un usuario que cae en un 404 está algo avergonzado, incluso si es culpa tuya. No amplifiques eso con un tono pasivo-agresivo. Sé directo, útil y ayúdales a seguir adelante.
Hechos e historia que siguen importando en 2025
Esto no es trivia por la trivia. Cada punto explica por qué ciertas decisiones sobre 404 siguen siendo sorprendentemente importantes.
- HTTP 404 se define como “Not Found”, lo que significa que el servidor no tiene una representación actual para el recurso solicitado. Ese término “actual” importa: no afirma que el recurso nunca existió, solo que no está disponible ahora.
- 410 Gone es distinto. 410 es una declaración explícita de que el recurso fue eliminado de forma intencional y permanente. Los motores de búsqueda suelen eliminar URLs con 410 más rápido que con 404.
- Los motores de búsqueda acuñaron “soft 404” para describir páginas que parecen errores pero devuelven 200 OK, o redirigen todo a la página de inicio. Eso puede perjudicar la confianza y la calidad del indexado.
- Los servidores web antiguos venían con páginas de error mínimas porque el ancho de banda y la CPU eran caros y las plantillas dinámicas eran menos comunes. Esa herencia sigue marcando los valores por defecto: muchas pilas envían HTML mínimo para 404 a menos que lo sobrescribas.
- Los CDN popularizaron el manejo de errores en el edge. Un 404 puede ser cacheado en el borde igual que un 200, y eso puede ser tu mejor amigo (rendimiento) o tu peor enemigo (páginas faltantes obsoletas después de un despliegue).
- Navegadores y proxies tratan 404 de manera distinta a 200. Por ejemplo, las cachés pueden almacenar 404 con heurísticas distintas y el código cliente a menudo comprueba códigos de estado para ramificar la lógica.
- A los escáneres de seguridad les encantan las superficies 404. Muchas cadenas de explotación empiezan con descubrimiento: peticiones a rutas de administrador comunes, endpoints de plugins antiguos o backups mal configurados. Tus encabezados y tiempos de respuesta de 404 pueden filtrar detalles de la pila si eres descuidado.
- Las SPAs hicieron confuso el enrutamiento 404. Los routers del lado cliente a menudo quieren “servir index.html para rutas desconocidas”, que es correcto para rutas de la app pero incorrecto para contenido realmente inexistente. La distinción importa para SEO y claridad del usuario.
- Históricamente, un enlace roto era “problema de otro”. Hoy, la analítica y las herramientas de Search Console lo hacen medible, así que ignorar los 404 es una elección—por lo general una mala.
Principios de diseño: hacer que el 404 funcione
1) Confirma lo que pasó, sin drama
Di la verdad en palabras simples: “No encontramos esa página.” Luego proporciona unas pocas acciones siguientes. No culpes al usuario. No sugieras que el sitio está caído a menos que lo esté. Un 404 suele ser una única URL faltante, no una caída general.
2) Ofrece dos o tres salidas de alta calidad
Una buena página 404 es intencionalmente pequeña. No estás reconstruyendo la navegación; estás ofreciendo válvulas de escape:
- Inicio (sí, pero no confíes solo en esto).
- Búsqueda (la mejor herramienta de recuperación universal).
- Tareas principales de tu producto (precios, docs, estado, contacto, inicio de sesión—elige lo que tus usuarios realmente hacen).
Mantén entre 5 y 8 enlaces. Demasiados enlaces se convierten en un encogimiento visual y los usuarios se van igual.
3) Conserva el contexto cuando puedas
Si sabes de dónde vino el usuario, úsalo. “Volver” no es un enlace; es una función del navegador y los usuarios la conocen. Dales un enlace real: “Volver a la página anterior” (basado en referrer), o muestra sugerencias “Quizá quisiste decir…” derivadas de la ruta faltante.
Un truco simple que funciona: analiza los segmentos de la ruta URL y ofrece una ruta padre más amplia si existe (por ejemplo, /docs/storage/… → /docs/storage/).
4) No reveles internos
Tu página 404 la ve todo el mundo, incluidos bots que recopilan tus errores. Evita:
- Cadenas de versión de frameworks en encabezados o HTML.
- Traza de pila, IDs de depuración que mapeen a sistemas internos, o mensajes de excepción sin procesar.
- Reflejar contenido de URL no confiable en la página sin escapar.
5) Haz que la página sea barata de servir
Los 404 son variables. Cuando algo falla—un enlace de blog popular, un cambio de nombre de producto, un despliegue que elimina un endpoint—tu tasa de 404 puede dispararse 10–100×. Si tu página 404 depende de llamadas lentas al backend o paquetes pesados del cliente, conviertes un error de contenido en un incidente de disponibilidad.
6) Instrumentala como un endpoint de producción
Quieres saber:
- Qué URLs faltantes son las más calientes.
- Referentes que generan el tráfico roto.
- Agentes de usuario que indiquen escáneres vs humanos.
- Si los 404s se correlacionan con despliegues, cambios de CDN o cambios de DNS.
Texto y humor: una ceja levantada, no un show de comedia
Escribe el texto como escribirías una actualización de incidente: calmado, claro y orientado a los siguientes pasos.
Haz: “Esa página no está aquí. Prueba con la búsqueda o ve a Precios.”
No hagas: “¡Upsie! ¡Algo salió mal!!!” (No pasó. Faltaba un enlace.)
El humor está permitido, pero debe ser ligero y opcional—como el condimento. Si el usuario está atascado, los chistes parecen que te ríes de él. Si el usuario puede recuperarse rápido, una pequeña sonrisa está bien.
Chiste #1: La página que pediste está en su pausa para el café y no dejó dirección de reenvío.
Fíjate qué no hace ese chiste: no se burla del usuario, no menciona “errores de servidor” y no implica que el sitio sea inestable. Es un pequeño momento humano, y luego volvemos al trabajo.
Chiste #2: Buscamos por todas partes—incluso debajo de la caché—pero esta URL aún no es real.
Dos chistes. Eso basta. Si necesitas más humor, lo que en realidad necesitas es mejor IA, redirecciones e higiene de enlaces.
El cuadro de búsqueda: rápido, seguro y útil
El cuadro de búsqueda es la función de mayor impacto en una página 404. Convierte “callejón sin salida” en “continúa la tarea”. Pero solo si funciona rápido y devuelve resultados relevantes.
Opciones de UX de búsqueda que importan
- Autoenfoca el input en escritorio. En móvil, ten cuidado: el autoenfoque puede abrir el teclado y molestar a la gente. Hazlo condicional.
- Prefill con la ruta faltante como sugerencia, no como consulta forzada. La gente a menudo quiere un término relacionado, no “docs-v2-final-final”.
- Acepta consultas simples. No requieras sintaxis avanzada. Esta es una herramienta de recuperación, no una consola para usuarios avanzados.
- Devuelve resultados rápidamente. Si tu backend de búsqueda es lento, degradar con gracia: muestra enlaces curados y una forma de navegar categorías.
Controles de seguridad y abuso
Los endpoints de búsqueda atraen scrapers. Tu página 404 puede amplificar el tráfico de búsqueda si los bots lanzan URLs al azar y respondes con llamadas de búsqueda pesadas.
Controles que no arruinan la UX:
- No ejecutes la búsqueda automáticamente solo porque ocurrió un 404. Espera a una acción del usuario (submit) o haz una lista de sugerencias muy barata desde un índice local.
- Limita la tasa de peticiones de búsqueda por IP y/o sesión. Mantén la página 404 desacoplada de la parte cara.
- Tiempo límite para las llamadas de búsqueda con un límite estricto, y luego vuelve a enlaces curados. Una búsqueda lenta es peor que ninguna búsqueda.
- Escapa la entrada y evita reflejar cadenas de consulta crudas en HTML. Esto es higiene XSS estándar, y los 404 son objetivos comunes porque reflejan la ruta solicitada.
Realidad operativa: la búsqueda es una dependencia
Si tu página 404 llama al backend de búsqueda, acabas de convertir “enlace perdido” en dependiente de tu sistema más complejo. Esa es una inversión de dependencias. Una regla aburrida que sigo: la página 404 debe renderizarse completamente sin llamadas a upstream. La búsqueda puede ser un enlace a una página de búsqueda, o una caja embebida que envíe a un endpoint separado. La respuesta 404 en sí debe seguir siendo barata.
La ingeniería de confiabilidad tiene un principio claro aquí. Parafraseando una idea de John Gall: “Sistemas complejos que funcionan usualmente evolucionaron de sistemas más simples que funcionaban.” Tu 404 debería ser una de las páginas más simples que sirves.
Enlaces útiles que no parecen un volcado de sitemap
Una página 404 con 40 enlaces es simplemente otro tipo de “no encontrado”. Curar.
Cómo elegir los enlaces correctos
Elige enlaces basados en la intención, no en la estructura organizativa. En sitios corporativos, el organigrama suele filtrarse en la navegación. Resístelo. A los usuarios no les importa qué VP posee “Soluciones”. Les importa hacer algo.
Buenos valores por defecto para muchos productos:
- Inicio
- Búsqueda (o un enlace a búsqueda)
- Precios (o Planes)
- Documentación (o Centro de ayuda)
- Estado (si lo tienes; si no, no lo finjas)
- Contactar soporte
- Iniciar sesión (si aplica)
Sugerencias con contexto
Las sugerencias contextuales vencen a las genéricas. Ejemplos que funcionan bien:
- Si la ruta empieza con
/docs/, ofrece “Inicio de Docs” y “Referencia de API.” - Si la ruta empieza con
/blog/, ofrece “Últimos posts” y “Temas.” - Si la ruta parece un activo (
.js,.css,.png), muestra un mensaje corto dirigido a desarrolladores: “Parece un archivo estático faltante. Si estás desplegando, revisa la canalización de assets y la caché del CDN.”
Un enlace para reportar el problema (sin convertirlo en tu nueva manguera de tickets)
Una opción “Reportar este enlace roto” puede ser oro, pero solo si la implementas con sensatez:
- Prefill la URL faltante y el referrer.
- Requiere esfuerzo mínimo (un clic para abrir un formulario).
- No pidas login a menos que tu producto sea exclusivamente autenticado.
- Enrútalo a triage (no directamente a páginas de ingeniería). Si no, entrenarás a la gente a usarlo como botón de queja general.
Semántica HTTP y SEO: evita las trampas de “soft 404”
Regla opinada: devuelve 404 para contenido que no existe. No redirijas todo a la página de inicio. No devuelvas 200 con un mensaje amistoso. Ahí es donde terminas con un índice de búsqueda lleno de basura y un sistema de monitorización lleno de mentiras.
Opciones de código de estado
- 404 Not Found: por defecto para páginas o recursos faltantes.
- 410 Gone: úsalo para contenido eliminado intencionalmente cuando estés seguro de que no volverá.
- 301 Moved Permanently: úsalo cuando haya una URL de reemplazo clara. No 301 a “algo parecido”.
- 302/307: para movimientos temporales durante migraciones o experimentos.
Guía de canonical e indexado
Una página 404 no debería indexarse como contenido. Usualmente harás:
- Devolver un verdadero estado 404.
- Incluir meta
noindex(cinturón y tirantes; el estado ya indica a la mayoría de crawlers qué hacer). - Evitar etiquetas canonical que apunten a páginas reales a menos que estés haciendo algo muy deliberado.
Por qué “redirigir a la página de inicio” es un mal hábito
Se siente útil. No lo es. Oculta enlaces rotos, confunde los embudos de analítica y enseña a los crawlers que tu sitio no respeta el significado de las URLs. A los usuarios también les disgusta: hicieron clic en una página específica y quedaron arrojados al vestíbulo sin instrucciones.
SPAs: separa “ruta desconocida” de “contenido faltante”
Las SPAs suelen servir index.html para cualquier ruta para que el router cliente renderice la vista correcta. Eso está bien para rutas válidas de la app. Pero cuando la ruta realmente no existe, aún quieres un 404—no un 200 con un componente “página no encontrada”.
Enfoque práctico: mantiene una lista blanca de rutas del lado servidor para SPA, o hace que la aplicación devuelva 404 a nivel de API para contenido desconocido y que el servidor devuelva 404 para rutas de activos desconocidas.
Registro, monitorización y alertas: los 404 como señales
Los 404 no siempre son “errores” en el sentido operacional. Los bots sonarán. Los enlaces antiguos existirán. Pero los picos y patrones son accionables, y si los ignoras pasarás más tiempo después haciendo arqueología forense.
Qué registrar para un 404
- Ruta y cadena de consulta solicitada (con medidas de privacidad).
- Referrer.
- Agente de usuario (o una clasificación hasheada/parseada).
- Cabecera Host (importa en sitios multi-tenant).
- Tiempo de respuesta y tiempo upstream (debería ser cercano a cero upstream para un buen 404).
- Estado de caché (HIT/MISS/BYPASS) si está detrás de un CDN o proxy inverso.
Sobre qué alertar
Alerta sobre cambios de tasa, no valores absolutos. Un sitio con mucho contenido de cola larga siempre tendrá algunos 404.
- Pico de tasa de 404 relativo a la línea base.
- URL top 404 de repente caliente (a menudo indica un enlace interno roto o un error tipográfico en una campaña de marketing).
- 404s para assets estáticos (puede indicar despliegue roto, artefactos faltantes o problemas de purga en CDN).
- 404 alto + latencia alta (tu manejador de 404 está haciendo demasiado trabajo).
Realidad de privacidad y cumplimiento
No registres datos personales a la ligera. Las cadenas de consulta a menudo incluyen correos, tokens o términos de búsqueda. Aún puedes ser útil siendo cuidadoso:
- Elimina o hashea parámetros sensibles conocidos.
- Mantén retención corta para logs crudos; conserva métricas agregadas por más tiempo.
- Clasifica agentes de usuario en lugar de almacenar cadenas completas si puedes.
Rendimiento y fiabilidad: tu 404 está en la ruta crítica
La mayoría de equipos piensa en rendimiento en la página de inicio y flujos clave del producto. Mientras tanto, los 404 silenciosamente se convierten en un vector de negación de billetera porque son fáciles de activar y a menudo están mal cacheados.
Mantén el payload pequeño
Una página 404 debería ser mayormente HTML y un poco de CSS. Si envías un enorme bundle JS para decir “no encontrado”, mereces la factura que recibes.
Cachea con estrategia
Cachear 404s es útil pero matizado:
- Cachea respuestas 404 para sondas de bots obvias (por ejemplo, rutas de exploits comunes) por un TTL corto, en el edge si es posible.
- Sé cauteloso cachando 404 para contenido que puede aparecer pronto. Si cacheas un 404 para una URL que existirá después del siguiente despliegue, creas incidentes autoinfligidos “funciona en origen pero no en el edge”.
- Usa TTLs distintos por prefijo de ruta. Los 404 de assets estáticos pueden ser cacheados por más tiempo; las rutas de contenido dinámico podrían necesitar TTLs más cortos.
Hazlo resistente a caídas de backend
Una de mis victorias silenciosas favoritas es servir 404s completamente desde la capa del proxy inverso, sin dependencia de la app. Cuando la app está caída, el proxy aún puede responder correctamente a rutas faltantes y evitar saturar las colas upstream.
Guía de diagnóstico rápido
Este es el flujo “tengo 15 minutos y un stakeholder impaciente”. El objetivo es identificar si el cuello de botella es contenido, enrutamiento, caché o despliegue.
Primero: confirma códigos de estado y alcance
- ¿Es un verdadero 404 desde el origen, o un 404 del CDN/WAF, o un 200 con contenido “no encontrado”?
- ¿Es una URL o todo un prefijo?
- ¿Es solo en una región/POP, o en todas partes?
Segundo: encuentra el referrer y la fuente de la verdad
- ¿Enlace interno? Arréglalo inmediatamente y despliega.
- ¿Enlace externo? Añade una redirección si es popular y el destino es obvio.
- ¿Ruido de bot? Limítalo o cachealo; no te asustes.
Tercero: revisa cambios de despliegue y enrutamiento
- ¿Cambió una regla de reescritura?
- ¿Una regla de fallback de SPA accidentalmente absorbió 404 reales?
- ¿La build dejó de publicar assets (mismatch de hash, artefacto faltante)?
Cuarto: revisa comportamiento de caché
- ¿El CDN está cacheando 404s con demasiada agresividad?
- ¿El origen envía cabeceras de caché que no pretendías?
- ¿Hay una configuración de edge obsoleta?
Quinto: valida la propia página 404
- ¿El manejador de 404 es lento o llama a servicios upstream?
- ¿Está generando errores (500) bajo carga?
- ¿Carga JS/CSS pesados desde URLs de assets faltantes (404 dentro del 404)?
Tareas prácticas: comandos, salidas y decisiones
Estas tareas están diseñadas para depuración real en producción. Cada una incluye un comando, una salida representativa, lo que significa y la decisión a tomar a continuación.
Task 1: Verify the status code is a real 404 (not a soft 404)
cr0x@server:~$ curl -s -D- -o /dev/null https://www.example.com/definitely-missing-page
HTTP/2 404
date: Mon, 29 Dec 2025 10:15:21 GMT
content-type: text/html; charset=utf-8
cache-control: max-age=60
Qué significa: El servidor devuelve un 404 real. Buen comienzo. Cache-Control indica que puede cachearse por 60 segundos.
Decisión: Si los usuarios informan “existe pero recibo 404”, sospecha de caché o despliegue. Si realmente falta, pasa al análisis de referers.
Task 2: Detect a soft 404 (200 with “not found” content)
cr0x@server:~$ curl -s -D- https://www.example.com/definitely-missing-page | head -n 12
HTTP/2 200
date: Mon, 29 Dec 2025 10:16:02 GMT
content-type: text/html; charset=utf-8
<!doctype html>
<html>
<title>Page not found</title>
Qué significa: Esto es un soft 404. Tu monitorización, caché y SEO empeorarán.
Decisión: Arregla el enrutamiento para que el contenido faltante devuelva 404. Para SPAs, implementa lista blanca del lado servidor o manejo de estado correcto.
Task 3: Check whether the CDN is the one returning the 404
cr0x@server:~$ curl -s -D- -o /dev/null https://www.example.com/definitely-missing-page | egrep -i 'server:|via:|x-cache:|cf-cache-status:|x-served-by:'
server: cloudflare
cf-cache-status: HIT
Qué significa: La respuesta la sirve el CDN y está cacheada (HIT). El origen puede que no esté involucrado.
Decisión: Si la página empezó a existir recientemente, purga o baja el TTL para 404s en esa ruta. Si realmente falta, considera cachearla más tiempo para rutas con mucho tráfico de bots.
Task 4: Confirm origin behavior by bypassing the CDN (where possible)
cr0x@server:~$ curl -s -D- -o /dev/null --resolve www.example.com:443:203.0.113.10 https://www.example.com/definitely-missing-page
HTTP/2 404
date: Mon, 29 Dec 2025 10:18:12 GMT
server: nginx
Qué significa: Directo al origen también devuelve 404, así que el CDN no está inventando el error.
Decisión: Trátalo como contenido faltante o error de enrutamiento en el origen. Pasa a los logs para ver referers y patrones.
Task 5: Find top 404 paths in NGINX access logs
cr0x@server:~$ awk '$9==404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head
842 /wp-login.php
311 /docs/storage/zfs-tuning
207 /assets/app.8f3c1d.js
98 /favicon.ico
Qué significa: Tienes tanto sondas de bots (/wp-login.php) como probablemente un enlace roto real (/docs/storage/zfs-tuning) y un asset faltante.
Decisión: Sonda de bot: cacheo corto y/o regla WAF. Enlace de docs: añade redirección o arregla enlaces internos. Asset faltante: trátalo como un problema de despliegue/CDN inmediatamente.
Task 6: Identify who is sending users to the missing URL (referrer analysis)
cr0x@server:~$ awk '$9==404 {print $11}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head
126 "https://www.example.com/docs/storage/"
88 "https://www.example.com/blog/introducing-zfs"
41 "-"
Qué significa: Una página de docs y un post de blog están enlazando a objetivos faltantes. “-” indica sin referrer (escrito/marcador/bot).
Decisión: Arregla las páginas origen primero. Las redirecciones ayudan, pero corregir enlaces internos evita 404s repetidos.
Task 7: Confirm whether the missing asset exists on disk (static build sanity)
cr0x@server:~$ ls -lh /var/www/html/assets/ | head
total 12M
-rw-r--r-- 1 www-data www-data 92K Dec 29 09:57 app.91a2ce.js
-rw-r--r-- 1 www-data www-data 31K Dec 29 09:57 app.91a2ce.css
Qué significa: El asset referenciado en logs (app.8f3c1d.js) no está presente; existe otro hash. Probablemente un HTML que referencia un build obsoleto o un despliegue parcial.
Decisión: Revisa artefactos de despliegue y asegúrate de que HTML y assets se desplieguen atómicamente. Si usas CDN, purga el HTML viejo o ajusta el caché para evitar servir bundles descoordinados.
Task 8: Check NGINX config for 404 handling and SPA fallbacks
cr0x@server:~$ sudo nginx -T 2>/dev/null | egrep -n 'error_page|try_files|location /' | head -n 20
45: error_page 404 /404.html;
78: location / {
79: try_files $uri $uri/ /index.html;
80: }
Qué significa: El servidor usa try_files para hacer fallback a /index.html. Eso está bien para rutas SPA, pero puede crear soft 404s si index.html devuelve 200 para rutas faltantes.
Decisión: Asegura que el router SPA devuelva 404 para rutas cliente desconocidas, o implementa una distinción del lado servidor para rutas SPA conocidas vs desconocidas.
Task 9: Validate the 404 page is lightweight (TTFB and size)
cr0x@server:~$ curl -s -o /dev/null -w "status=%{http_code} ttfb=%{time_starttransfer} size=%{size_download}\n" https://www.example.com/definitely-missing-page
status=404 ttfb=0.038241 size=6142
Qué significa: TTFB rápido y payload pequeño. Eso es lo que quieres.
Decisión: Si TTFB es alto, la ruta 404 está haciendo trabajo de backend. Arregla sirviendo un 404 estático en el edge/proxy.
Task 10: Verify cache headers for 404 responses
cr0x@server:~$ curl -s -D- -o /dev/null https://www.example.com/definitely-missing-page | egrep -i 'cache-control|expires|age'
cache-control: public, max-age=3600
age: 2540
Qué significa: El 404 está cacheado por una hora y ya lleva cacheado 42 minutos. Eso puede ser correcto para sondas de bots, peligroso para contenido recién publicado.
Decisión: Reduce el TTL para rutas tipo contenido, mantén TTL más largo para rutas de basura obvia. Separa por bloques de ubicación o reglas del CDN.
Task 11: Check whether redirects exist for known legacy paths
cr0x@server:~$ curl -s -D- -o /dev/null https://www.example.com/docs/storage/zfs-tuning | head -n 8
HTTP/2 404
date: Mon, 29 Dec 2025 10:24:19 GMT
Qué significa: No hay redirección. Si esto es un error común (ver Task 5), estás perdiendo usuarios.
Decisión: Añade un 301 al mejor reemplazo, o restaura la página si fue removida por accidente. Si fue removida intencionalmente, considera 410.
Task 12: Identify whether 404s correlate with deploy time
cr0x@server:~$ journalctl -u nginx --since "2025-12-29 09:30" --until "2025-12-29 10:30" | egrep -i 'reload|signal|start'
Dec 29 09:58:01 web-1 nginx[1321]: signal process started
Dec 29 09:58:02 web-1 nginx[1321]: signal process started
Qué significa: NGINX recargó alrededor del momento en que cambiaron los assets. Combinado con el hash de asset faltante, esto sugiere un problema de despliegue.
Decisión: Inspecciona la canalización de despliegue para atomicidad; verifica que el HTML referencia el hash de asset correcto y que las cachés se purgan de forma coherente.
Task 13: Spot a 404 storm driven by a single bot UA
cr0x@server:~$ awk '$9==404 {print $12,$7}' /var/log/nginx/access.log | head -n 3
"Mozilla/5.0" /wp-login.php
"SomeScanner/1.2" /admin.php
"SomeScanner/1.2" /.git/config
Qué significa: Un escáner está sondeando rutas previsibles. Estos deberían ser baratos de servir y idealmente bloqueados o ralentizados en el edge.
Decisión: Añade reglas WAF o limitación de tasa en NGINX para patrones abusivos. Cachea estos 404s por más tiempo con un body mínimo para ahorrar recursos del origen.
Task 14: Confirm the 404 page isn’t itself causing more 404s (missing CSS/JS)
cr0x@server:~$ curl -s https://www.example.com/404.html | egrep -o 'href="[^"]+|src="[^"]+' | head
href="/assets/app.8f3c1d.css
src="/assets/app.8f3c1d.js
Qué significa: Tu página 404 depende de assets que podrían faltar (como se vio antes). Eso crea un segundo modo de fallo: “la página 404 se muestra rota” y genera más ruido 404.
Decisión: Incrusta CSS mínimo para la página 404 o referencia assets estables y versionados que garantices que existen. Mantenla independiente del bundle principal de la app.
Tres mini-historias corporativas (anonimizadas, dolorosamente plausibles)
Mini-historia 1: El incidente causado por una suposición equivocada
La empresa estaba en rebrand, lo que significó que las URLs cambiaban. Un product manager pidió “no enlaces rotos” y alguien tradujo eso por “redirigir todas las rutas desconocidas a la página de inicio”. Sonaba amigable para el cliente y silenció el gráfico de 404. Todos tomaron el silencio como éxito.
Dos semanas después, las conversiones de búsqueda pagada bajaron. No se desplomaron—solo se hundieron. El equipo de marketing culpó al targeting de anuncios. El equipo web culpó al tracking. La analítica mostraba tráfico sano y una tasa de 404 sospechosamente baja, lo que parecía evidencia contra “enlaces rotos”.
El problema real: los usuarios llegaban a enlaces profundos desde anuncios y contenido viejo, eran 302’d a la página principal y luego se iban. Las sesiones parecían “exitosas” en dashboards básicos porque la página de inicio era 200. El embudo estaba roto porque la intención de la landing se destruyó.
Cuando el SRE on-call finalmente tiró de logs crudos, fue obvio: un pequeño conjunto de URLs antiguas de alta intención se redirigían a “/” a gran volumen. Arreglarlo fue aburrido: implementar 301 específicos a las páginas nuevas correctas, restaurar 404 reales para URLs desconocidas y añadir monitorización para anomalías de redirección a la home.
La suposición equivocada fue “a los usuarios les molestan los 404, así que elimínalos.” A los usuarios les molestan los callejones sin salida. Un 404 veraz con caja de búsqueda es mejor que mentir con una redirección a la página de inicio.
Mini-historia 2: La optimización que salió mal
Un equipo quería reducir la carga del origen. Decidieron cachear 404s agresivamente en el edge: Cache-Control: public, max-age=86400 para todo lo que devolviera 404. Funcionó de inmediato para el ruido de bots y sondas aleatorias. El volumen de solicitudes al origen cayó. Alguien declaró victoria.
Luego un partner publicó un enlace de alto tráfico a una página que aún no existía, porque el calendario de lanzamiento se desplazó un día. Durante la primera ola de tráfico, la página devolvió 404 correctamente. El CDN lo cacheó por un día. Cuando la página se puso en vivo unas horas después, los usuarios aún recibían 404 desde el edge.
El incidente fue brutal porque parecía “la página está desplegada pero sigue faltando”. Las pruebas en origen pasaban. Solo algunas regiones estaban afectadas. Se emitieron purgas, pero la propagación no fue instantánea y no todas las cachés se limpiaron consistentemente.
El postmortem no fue “nunca cachees 404”. Fue “cachea 404s con intención”. Introdujeron TTLs por ruta: TTL corto para rutas tipo contenido que puedan aparecer, TTL largo para rutas de exploits obvios, y bypass inmediato para prefijos críticos durante lanzamientos.
Optimizar no es sinónimo de “poner un TTL largo”. Optimizar es elegir en qué te puedes permitir equivocarte.
Mini-historia 3: La práctica aburrida pero correcta que salvó el día
Otra compañía tenía una regla que sonaba poco glamorosa: cada 404 debe incluir un request ID interno, y las 20 rutas top 404 deben revisarse semanalmente. No “cuando tengamos tiempo”. Semanalmente. La revisión rotaba entre el equipo web y soporte.
Un lunes, el informe mostró un nuevo 404 caliente: una ruta en la sección de facturación. El referrer era interno: un enlace en una plantilla de email de onboarding. Nadie había tocado la app de facturación. La plantilla de email la gestionaba marketing.
Porque la página 404 incluía el request ID y los logs estaban estructurados, lo rastrearon en minutos. La URL tenía un guion faltante—un simple error humano. La solución también fue aburrida: actualizar la plantilla de email y añadir una redirección desde la URL equivocada a la correcta por seguridad.
Lo mejor: esto nunca se volvió un “outage del sitio”. Se mantuvo como una pequeña molestia operativa que se limpió antes de empeorar. Sin culpas. Sin drama. Solo un pequeño hábito semanal rindiendo frutos.
Los procesos aburridos están subestimados. El truco es escoger procesos aburridos que realmente conecten con el dolor del usuario.
Errores comunes: síntomas → causa raíz → solución
1) Síntoma: “Nuestra página 404 aparece en resultados de Google”
Causa raíz: Soft 404 (estado 200), o manejo incorrecto de canonical/noindex, o un CDN que reescribe códigos de estado.
Solución: Devuelve 404 verdadero para páginas faltantes. Añade meta noindex en la plantilla 404. Verifica con curl -D- que el estado sea 404 end-to-end (incluyendo CDN).
2) Síntoma: “Los usuarios ven la página de inicio cuando hacen clic en enlaces antiguos”
Causa raíz: Regla catch-all de redirección para rutas desconocidas.
Solución: Elimina redirecciones catch-all. Añade 301 dirigidos para URLs legacy conocidas y mantiene 404 verdadero para URLs desconocidas.
3) Síntoma: “Pico de 404 tras despliegue, mayormente assets”
Causa raíz: Despliegue no atómico de HTML + assets con hash; HTML obsoleto cacheado más tiempo que los assets; orden de purga incorrecto.
Solución: Despliega assets primero, luego HTML, o despliega en directorios versionados y cambia el puntero de forma atómica. Alinea cachés: TTL corto para HTML, TTL largo para assets inmutables con hash.
4) Síntoma: “La página 404 es lenta y dispara timeouts bajo carga”
Causa raíz: El handler 404 llama a servicios de aplicación (búsqueda, personalización, experimentos), o renderiza con plantillas server-side pesadas.
Solución: Sirve una 404 estática en proxy/edge. Manténla independiente de dependencias upstream. Pon límite de tiempo a llamadas opcionales y falla a estático.
5) Síntoma: “No podemos reproducir el 404; usuarios en una región sí pueden”
Causa raíz: Caché CDN de 404s, purgas inconsistentes o despliegues divididos.
Solución: Revisa cabeceras de caché y estado de caché. Prueba pasando el CDN para testear origen. Purga URLs específicas y ajusta TTL de 404 por ruta.
6) Síntoma: “Soporte recibe spam de reportes de enlaces rotos”
Causa raíz: El enlace de reportar carece de fricción y enrutamiento; los bots lo activan; los usuarios lo usan como feedback general.
Solución: Añade controles básicos de abuso (limitación de tasa, CAPTCHA solo si es necesario), incluye campos estructurados y enrútalo a triage con selección clara de categoría.
7) Síntoma: “Seguridad se queja de que la 404 filtra detalles de la pila”
Causa raíz: Firmas de servidor por defecto, encabezados de framework, salida de debug o input reflejado.
Solución: Elimina/sobrescribe tokens de servidor, desactiva debug, escapa todas las cadenas reflejadas y asegura que las plantillas de error no incluyan detalles del entorno.
8) Síntoma: “La monitorización no muestra el problema; los usuarios se quejan igual”
Causa raíz: Soft 404s contados como éxito, o dashboards que solo rastrean 5xx, o redirecciones que ocultan errores.
Solución: Rastrea tasas de 404 y 3xx por separado. Alerta sobre cambios. Registra referers. Monitoriza las rutas faltantes top.
Listas de verificación / plan paso a paso
Checklist A: Construir una página 404 que ayude a los usuarios a recuperarse
- Escribe texto claro: “No podemos encontrar esa página.” Sin culpas, sin pánico.
- Añade un cuadro de búsqueda que envíe a un endpoint de búsqueda dedicado (no llamarlo automáticamente al renderizar).
- Curar 5–8 enlaces a tareas principales. Manténlo conciso.
- Ofrece contexto: muestra la ruta solicitada, escapada de forma segura, y un enlace “volver” si existe referrer.
- Añade una opción de reporte solo si puedes triagearla. Prefill la URL faltante y el referrer.
- Hazla accesible: encabezados apropiados, manejo del foco y contraste legible.
Checklist B: Hacerlo correcto para SEO y caché
- Devuelve HTTP 404 para recursos faltantes. Valida en el edge.
- Usa 410 selectivamente para páginas intencionalmente removidas.
- Añade noindex a la plantilla 404.
- No redirijas URLs desconocidas a la página de inicio. Usa redirecciones dirigidas únicamente.
- Configura cabeceras de caché sensatas: TTL corto para 404 tipo contenido, TTL largo para sondas de bots obvias.
Checklist C: Instrumentación y operaciones
- Registra 404s con estructura: ruta, estado, referrer, clase UA, request ID, estado de caché.
- Crea un reporte top-404 (diario o semanal) y asigna responsabilidad.
- Alerta en picos, no por existencia. Los 404 son normales; los cambios súbitos no lo son.
- Separa 404s de assets de 404s de páginas.
- Ejecuta un chequeo de enlaces internos rotos como parte del CI para docs/contenido.
Checklist D: Seguridad en migraciones y rediseños
- Inventaria URLs de alto tráfico antes de cambiar la arquitectura de información.
- Planifica redirecciones para los reemplazos obvios; evita redirecciones “más o menos”.
- Mantén URLs antiguas vivas por un período con 301s, especialmente para docs y posts de blog.
- Vuelve a probar tras cambios en CDN: códigos de estado, caché y comportamiento de purga.
Preguntas frecuentes
¿Debe una página 404 devolver 404 o 200?
Devuelve 404. Un 200 con contenido “no encontrado” es un soft 404 que rompe señales SEO, precisión de analítica y visibilidad operacional.
¿Cuándo deberíamos usar 410 Gone en lugar de 404?
Usa 410 cuando estés seguro de que el contenido fue eliminado intencionalmente y no volverá. Es una señal más fuerte para crawlers y ayuda a reducir rastreos repetidos de URLs muertas.
¿Está bien redirigir páginas faltantes a la página de inicio?
No, no como regla general. Oculta enlaces rotos y perjudica la intención del usuario. Usa redirecciones dirigidas solo cuando exista un reemplazo real.
¿Debería la página 404 incluir un menú de navegación global?
Generalmente no. Proporciona un pequeño conjunto de enlaces de alto valor en su lugar. La navegación completa fomenta “vagar hasta rendirse” y aumenta el peso de la página.
¿Necesitamos un cuadro de búsqueda en la página 404?
Si tienes más de un puñado de páginas, sí. Es la herramienta de recuperación más rápida. Pero no hagas que el renderizado del 404 dependa de una llamada al backend de búsqueda.
¿Cómo prevenimos que los bots causen respuestas 404 costosas?
Sirve 404s de forma económica, cachea rutas de sondas obvias y limita la tasa de patrones abusivos. Mantén el handler 404 estático y evita dependencias de backend.
¿Por qué vemos muchos 404s para /wp-login.php si no usamos WordPress?
Eso es ruido de fondo común de escáneres. Trátalo como oportunidad para ahorrar dinero: devuelve un 404 mínimo cacheado y considera reglas WAF.
¿Cómo sabemos si el CDN está cacheando 404s incorrectamente?
Revisa encabezados como Age y el estado de caché del CDN. Compara comportamiento edge vs origen pasando el CDN (cuando sea posible) y revisando la política cache-control por ruta.
Nuestra SPA siempre sirve index.html. ¿Cómo manejamos 404 correctamente?
Mantén el fallback de SPA solo para rutas de la app conocidas. Las rutas desconocidas deberían devolver 404 en el servidor, o el router cliente debe renderizar una vista 404 mientras el servidor devuelve 404 cuando sea factible.
¿Deberíamos incluir un botón “reportar enlace roto”?
Solo si puedes triagearlo de forma fiable y defenderlo del abuso. Si lo añades, prefilla URL faltante + referrer y enrútalo a una cola que se revise.
Conclusión: pasos prácticos siguientes
Una página 404 sin vergüenza no es un ejercicio de marca. Es una pequeña característica de fiabilidad que mantiene a los usuarios en movimiento y mantiene a tu equipo informado. Bien hecha, reduce la carga de soporte, protege el SEO y convierte lo “no encontrado” en “accionable”.
Haz esto ahora, en orden:
- Haz que los códigos de estado sean veraces: elimina los soft 404 y las redirecciones catch-all a la página de inicio.
- Haz que el 404 sea barato: respuesta estática, assets mínimos, sin llamadas al backend requeridas.
- Añade herramientas de recuperación: un cuadro de búsqueda (basado en submit) y una lista corta de enlaces a tareas principales.
- Instrumenta y revisa: registra referers, sigue las URLs faltantes top y configura alertas por picos.
- Arregla las fuentes: enlaces internos rotos primero, luego redirecciones dirigidas para misses externos populares.
Si solo haces una cosa: deja de tratar al 404 como un callejón sin salida. Es un endpoint de diagnóstico con un usuario delante.