Deterioro post-lanzamiento: por qué un sitio falla 6 meses después

El deterioro post-lanzamiento es la decadencia gradual de un sitio en producción tras la entrega, en la que las dependencias quedan desactualizadas, los certificados expiran, los Core Web Vitals se degradan y el contenido deja de coincidir con lo que los usuarios realmente buscan. El sitio salió a tiempo. Seis meses después, nadie está de guardia, nada está monitorizado, y los pequeños arreglos que habrían costado una hora en la primera semana ahora cuestan un cuarto del presupuesto para rehacerlo.

Es la razón más común por la que empresas medianas nos contratan en una segunda ronda sobre un sitio que en el lanzamiento funcionaba bien. El código no ha empeorado solo. El mundo alrededor ha avanzado, el sitio no.

Por qué duele más de lo que parece

Los números no son sutiles. La IEEE Computer Society estima que el mantenimiento de software representa entre el 60 y el 80 por ciento del coste total del ciclo de vida, frente a solo el 40 por ciento del desarrollo inicial. McKinsey informa que el 30 por ciento de los CIO ve más del 20 por ciento de su presupuesto tecnológico absorbido por la deuda técnica. El PKI and Digital Trust Report 2024 de Keyfactor halló que el 88 por ciento de las empresas sufrieron interrupciones no planificadas por certificados expirados en los dos años previos.

En el lado de las dependencias, el panorama es peor. Una investigación de 2025 muestra que el 80 por ciento de las dependencias de aplicaciones permanecen sin actualizar durante más de un año, incluso cuando el 95 por ciento de los componentes vulnerables ya tienen una versión parcheada disponible. Un proyecto npm medio arrastra 79 dependencias transitivas, y solo en 2025 se publicaron 454.648 paquetes npm maliciosos. Cada sitio que nadie toca está dentro de esa corriente.

Sumemos la deriva de los Core Web Vitals, la decadencia del contenido y los enlaces internos rotos, y el sitio que posicionaba al lanzamiento pierde terreno semana a semana. El algoritmo de Google no anuncia la degradación. El tráfico simplemente cae.

Por qué la solución obvia no funciona

La respuesta por defecto es volver a llamar al desarrollador original para arreglos puntuales. Parece eficiente. Lo construyó él, lo conoce. Lo hemos visto romperse de tres formas predecibles.

Primero, el precio está mal. Un acuerdo break-fix paga al desarrollador por esperar a que algo se rompa, lo contrario del incentivo que mantiene un sitio sano. Segundo, el conocimiento ya se ha evaporado. Seis meses después del lanzamiento, el desarrollador que entregó el sitio ha entregado otros cuatro. El git log es lo único que recuerda por qué existe cierto middleware. Tercero, el ciclo es demasiado largo. Cuando un stakeholder se da cuenta de que el dashboard es lento, tres meses de datos de Core Web Vitals ya se han movido en contra del sitio en Search Console.

Lo que sí funciona

Trata el sitio como un producto con un pequeño backlog recurrente

El mantenimiento no es una fase. Es una postura. En los sitios que mantenemos en retainer corremos un sprint recurrente de dos a cuatro horas cada dos semanas. El trabajo se llena solo: una PR de Renovate por fusionar, una regresión Lighthouse por investigar, una API obsoleta por reemplazar, un artículo cuyas estadísticas ya no son ciertas. Dos horas cada quince días le ganan a una reconstrucción en pánico.

Automatiza la higiene de dependencias antes de que ella te automatice

Renovate o Dependabot, configurados para abrir pull requests inmediatamente para actualizaciones de seguridad y semanalmente para versiones menores, capturan cerca del 90 por ciento de la deriva de dependencias antes de que importe. El trabajo no es fusionar cada PR. Es mirarlas cada semana. Con una suite de CI que de verdad corre, el merge es una decisión de un click. Sin ella, las actualizaciones de dependencias son un acantilado y el sitio se queda en versiones viejas durante años. El compromiso en la cadena de suministro de npm de septiembre de 2025, que afectó a chalk, debug, ansi-styles y strip-ansi (en conjunto 2,6 mil millones de descargas semanales), recordó que incluso los paquetes populares no son seguros por defecto.

Mide lo que los usuarios sienten de verdad, no lo que dice tu monitor sintético

El Real User Monitoring sobre Core Web Vitals le gana a las pruebas sintéticas siempre. La razón es la deriva del contenido. Imágenes nuevas, scripts publicitarios nuevos, etiquetas de analítica nuevas se cuelan a lo largo de los meses. Una prueba sintética sobre una página fija no ve por lo que pasa un visitante real, en un dispositivo real, con una red real. Cableamos Vercel Analytics o Cloudflare Web Analytics en cada sitio que entregamos, y configuramos alertas cuando LCP, INP o CLS cruzan los umbrales durante dos semanas consecutivas.

Audita el contenido cada 90 días

Las páginas no actualizadas en 90 días pierden citas de IA y peso de ranking. La cura es un calendario, no un pánico. Cada 90 días corremos una auditoría de contenido sobre las 20 páginas con más tráfico y las 10 con más conversión: estadísticas actuales, fuentes aún vivas, enlaces internos que apuntan a páginas que aún existen, FAQ que coinciden con lo que los usuarios realmente preguntan. La mayoría de las páginas se tocan en cinco minutos. Algunas reciben un refresh real. El efecto agregado sobre la visibilidad en buscadores es importante.

Trata certificados y DNS como fusibles

Los certificados SSL y los registros DNS son la parte más fácil de automatizar y la más cara cuando se ignoran. El apagón de Ericsson en 2018 dejó fuera de servicio la red de O2 en Reino Unido y costó alrededor de 1.400 millones de dólares en remediación, todo porque expiró un certificado. El CA/Browser Forum está reduciendo la validez pública de SSL/TLS a 200 días desde el 15 de marzo de 2026, luego a 100 días, luego a 47. La renovación manual ya no es viable. Usa Let's Encrypt con autorenew, monitoriza la expiración en cada endpoint con un servicio como Uptime Kuma o BetterStack, y configura TTL de DNS que te permitan hacer failover sin cuatro horas de caché.

Construye el runbook antes de necesitarlo

El sitio se va a romper un sábado a las 11 de la noche al menos una vez al año. La pregunta es si la respuesta toma 20 minutos o tres días. Para cada sitio que entregamos escribimos un runbook de cinco páginas: a quién llamar, dónde viven los secretos, cómo hacer rollback del último deploy, cómo levantar una página de mantenimiento estática desde el CDN, dónde está el dashboard de Sentry, cómo rotar una clave filtrada. Guardado en el gestor de contraseñas de la empresa, no en el portátil de un desarrollador.

Qué significa en la práctica

Un sitio que auditamos a comienzos de 2026 llevaba 11 meses online. El equipo original ya no estaba. Las puntuaciones de Lighthouse habían caído de 96 a 71 en móvil porque tres rondas de cambios de marketing añadieron 800KB de imágenes hero sin optimizar. Ocho dependencias estaban viejas, dos con CVE conocidos. El blog tenía 14 enlaces externos rotos, seis apuntando a competidores que en el ínterin habían cambiado de dominio. El formulario de contacto enviaba los leads a una contraseña SMTP que IT había rotado cuatro meses antes.

Ninguno de esos problemas era dramático. Juntos, habían recortado el tráfico orgánico un 38 por ciento en seis meses. La cura no fue rehacer. Fueron cuatro semanas de trabajo estructurado: Renovate, pipeline de imágenes, pasada de contenido, auditoría de enlaces, runbook. Seis meses después, el tráfico está por encima del nivel de lanzamiento y el equipo está en un retainer de dos horas cada quince días que captura la próxima ola antes de que se acumule.

El deterioro post-lanzamiento es primero una cuestión de presupuesto y después una cuestión de código. El momento más barato para arreglar un sitio es antes de que se haya estropeado. El momento más caro es después de que una deriva lenta se ha acumulado durante un año y rehacerlo está sobre la mesa. Dos horas cada dos semanas son el producto asegurador más barato de Internet.