El sitio está caído, y quien lo construyó ya no está.
Así se detiene la sangría primero.

Primero triaje, luego diagnóstico

Cuando un sitio está caído y no genera ventas, el instinto de arreglar todo de golpe se entiende, y suele ser el movimiento equivocado. La primera hora debería descartar las causas simples, porque son comunes y rápidas de corregir. Un dominio vencido. Un pago de hosting sin cubrir. Un certificado SSL que venció en silencio. Una actualización de plugin que se rompió según su propio calendario. Una parte sorprendente de los casos “el desarrollador desapareció y el sitio está caído” resulta ser justo esto, no un problema profundo de código.

Lo que busca una auditoría real

Si se descartan las causas simples, el siguiente paso es leer el código y el servidor mismo. Qué cambió justo antes de la caída. Qué dicen realmente los registros de error. Si el problema está en el código de la aplicación, una base de datos, una integración externa, o la configuración del servidor. Para un sitio de tamaño normal, esto suele tomar días, no semanas. Termina con una lista escrita de lo que está roto, ordenada por lo que de verdad cuesta dinero frente a lo que solo está desordenado.

Corregir sin empezar de nuevo

La mayoría de los sitios que se rompen tras la salida de un desarrollador no necesitan una reescritura. Necesitan que se corrija la parte concreta rota, y que el resto del sistema se deje en paz. Una reescritura tira todo lo que ya funcionaba, y cambia una caída conocida por meses de riesgo nuevo. Reconstruir solo tiene sentido donde la auditoría muestra de verdad que es más barato. Es una decisión con números reales, no una respuesta por defecto.

Por qué “nadie entiende el código” se resuelve

Un sitio sin documentación parece imposible de salvar, pero el código mismo casi siempre explica lo que hace, si alguien lo lee con cuidado. La estructura de la base de datos. Cómo se generan las páginas. Para qué sirve cada integración. Todo eso se descubre sin el desarrollador original, solo más lento que con sus notas. Una vez resuelta la caída, la solución real es anotar lo que se encontró, para que la siguiente persona no vuelva a empezar de cero.

Salir del modo “una persona de la siguiente caída”

Una vez el sitio en línea otra vez, corrija lo que permitió que una sola desaparición dejara fuera de línea a todo el negocio. Acceso a hosting y dominio que el negocio controla directamente. Una segunda persona que al menos pueda revisar si el sitio está vivo. Documentación de cómo está construido el sistema. Nada de esto evita cada problema futuro. Pero convierte la siguiente caída en una hora de molestia, en vez de una crisis donde nadie puede entrar.