Una mala publicación de un sitio estático casi nunca empieza como un gran incidente. Primero aparece una página en blanco, una hoja CSS que no carga, una imagen en 404, una ruta rota, un PDF equivocado o una landing page con el texto incorrecto.
El problema crece cuando el equipo intenta arreglar producción mientras el enlace ya está circulando.
Para un sitio estático, la respuesta más segura suele ser otra: volver primero a la última versión que funcionaba y revisar la publicación fallida cuando los visitantes ya no la están viendo.
El rollback sirve cuando el enlace público ya está afectado
No todo error necesita rollback. Si solo hay un acento mal puesto o una frase menor, subir una corrección puede ser suficiente.
El rollback se vuelve la primera opción cuando la versión pública actual es claramente peor que la anterior.
| Problema | Por qué ayuda volver atrás |
|---|---|
| Página en blanco | Los visitantes vuelven a ver una versión usable mientras revisas el build roto. |
| CSS, imágenes o fuentes faltantes | La versión anterior suele tener rutas de assets más confiables que una reparación improvisada. |
| Rutas rotas | Deep links, QR y URLs de campaña pueden volver a funcionar rápido. |
| Texto de campaña incorrecto | La oferta aprobada regresa mientras se corrige la nueva versión. |
| Export de IA incompleto | Placeholders, links inventados o secciones sin terminar salen de la versión en vivo. |
| PDF o descarga equivocados | El enlace público deja de apuntar a un archivo malo o inexistente. |
La regla es práctica: si la versión actual daña acceso, confianza, revisión de cliente o conversión, primero restaura una versión conocida.
Por qué los sitios estáticos pueden restaurarse bien
Un sitio estático se puede tratar como un conjunto completo de archivos: HTML, CSS, JavaScript, imágenes, fuentes, PDFs y otros assets.
Eso permite publicar por versiones, no editar una carpeta en vivo. Si cada publicación sobrescribe archivos en el mismo lugar, puedes terminar con HTML viejo, JavaScript nuevo, imágenes que faltan y caché de navegador mezclado. Con despliegues versionados, cada publicación representa un estado completo.
| Capa | Qué debería conservar | Por qué importa |
|---|---|---|
| Salida de build | Los archivos exactos de esa versión | No tienes que reconstruir el sitio anterior de memoria. |
| Registro de despliegue | Qué versión estuvo activa y cuándo | Puedes elegir un estado que sí fue verificado. |
| Mapeo de dominio | Qué versión sirve la URL pública | La recuperación puede ser un cambio de versión activa. |
| Contexto | Quién publicó y qué cambió | La investigación empieza después de contener el problema. |
Cloudflare Pages documenta el rollback como volver a un deployment de producción anterior. Vercel habla de Instant Rollback hacia un deployment previo. Netlify permite publicar un deploy anterior como producción. Los detalles cambian por plataforma, pero el modelo es el mismo: la versión anterior debe seguir disponible como objetivo publicable.
Evita reconstruir el sitio viejo durante el incidente
Si tu rollback significa buscar un ZIP viejo, compilar localmente, subir otra vez y esperar que coincida, en realidad estás haciendo un redeploy de emergencia.
Puede sacarte del paso, pero agrega riesgo cuando necesitas reducirlo:
- El código viejo puede no coincidir con el build publicado.
- Las dependencias pueden haber cambiado.
- Las variables o ajustes de build pueden no ser iguales.
- Alguien puede elegir la carpeta equivocada.
- La nueva subida puede crear otro estado roto.
La recuperación más limpia conserva despliegues exitosos y cambia cuál de ellos está activo.
Una decisión corta, no una discusión eterna
Rollback no debería convertirse en una discusión filosófica. Decide con pocas preguntas.
| Pregunta | Si sí | Si no |
|---|---|---|
| ¿El sitio en vivo está roto para visitantes reales? | Restaura una versión estable. | Tal vez basta con corregir hacia adelante. |
| ¿Es solo un texto menor? | Considera subir una corrección. | Sigue evaluando impacto. |
| ¿La versión anterior fue verificada? | Úsala como destino. | Busca el último estado realmente revisado. |
| ¿El cambio dependía de una API o datos externos? | Revisa compatibilidad antes y después. | El rollback estático probablemente alcanza. |
| ¿Hay campaña, cliente, clase o lanzamiento activo? | Contén el impacto público primero. | Puedes tener más tiempo para depurar. |
El objetivo no es que siempre gane el rollback. Es evitar que una mala versión siga visible mientras el equipo intenta adivinar.
Qué revisar inmediatamente después
El rollback no termina cuando la interfaz dice "listo". Hay que abrir el sitio.
- Abre la página de inicio en una ventana privada.
- Revisa las rutas importantes y enlaces profundos.
- Verifica CSS, JavaScript, imágenes, fuentes, PDFs y descargas.
- Prueba dominio personalizado y enlace de vista previa si ambos existen.
- Confirma que HTTPS sigue funcionando para el hostname.
- Mira visitas recientes o logs si están disponibles.
- Avisa al equipo qué versión está activa ahora.
Si el problema coincidió con cambios de dominio, revisa DNS y SSL. Restaurar archivos no corrige un CNAME mal puesto ni un certificado que todavía no se emitió. Para eso sirven la herramienta DNS y el SSL checker.
Qué no resuelve un rollback
Un rollback restaura el estado de entrega estática. No deshace automáticamente todo lo que rodea al sitio.
| Dependencia | Límite del rollback |
|---|---|
| APIs externas | La versión anterior puede esperar una respuesta que ya cambió. |
| Bases de datos | Restaurar archivos estáticos no revierte migraciones ni datos escritos. |
| CMS o contenido externo | Un build viejo puede leer contenido nuevo si depende de otra fuente. |
| Scripts de terceros | Una caída de proveedor puede afectar versión vieja y nueva. |
| DNS o certificados | La configuración de dominio va por otro camino. |
| Caché de navegador | Algunos visitantes pueden conservar assets por un tiempo. |
Esta frontera importa. El rollback es muy útil para problemas de frontend, rutas, assets y contenido publicado. No reemplaza un plan de incidentes para APIs, datos y servicios externos.
Browser upload, Git y CLI: misma idea de recuperación
El sitio puede llegar a producción por varios caminos. La lógica de recuperación se mantiene.
Subida desde navegador
Es común en carpetas HTML, exports de IA, portafolios, PDFs, páginas puntuales y vistas previas para cliente. El riesgo es que la versión anterior solo exista en la carpeta de descargas de alguien.
Los despliegues versionados ayudan porque el estado anterior vive dentro del proyecto.
Publicación desde Git
Git ayuda, pero un commit no siempre equivale al artefacto servido. Un rebuild posterior puede salir diferente si cambiaron dependencias, variables o ajustes.
En sitios estáticos, conservar el deployment exitoso sigue siendo valioso.
Despliegues por CLI
La CLI vuelve más repetible el proceso. No lo vuelve infalible. Un build válido puede publicar una ruta rota, un asset mal referenciado o una sección que nadie aprobó.
Cómo encaja DeployPages
DeployPages publica versiones estáticas en vez de obligarte a editar una carpeta viva a mano.
Puedes empezar con una subida desde navegador para obtener el primer enlace público y seguir usando el mismo proyecto cuando el sitio se vuelve más serio. Cuando las actualizaciones empiezan a importar, puedes sumar restauración de versiones, estadísticas, dominios personalizados, protección con contraseña y despliegues por CLI.
La idea del producto es simple: cada cambio importante debería dejar un camino de regreso. Si una nueva subida rompe la URL pública, el equipo no debería reconstruir el sitio de ayer mientras los visitantes esperan.
Playbook mínimo para el próximo lanzamiento
| Paso | Responsable | Listo cuando |
|---|---|---|
| Nombrar la versión | Quien publica | El equipo sabe qué cambió. |
| Revisar la vista previa | Revisor | Inicio, rutas, assets y móvil funcionan. |
| Mantener versión anterior disponible | Dueño del proyecto | Existe un estado estable para restaurar. |
| Publicar | Quien publica | La URL pública sirve la versión correcta. |
| Mirar primeras señales | Owner | Estadísticas, logs y pruebas manuales no muestran fallas obvias. |
| Restaurar si hace falta | Persona con permiso | La URL pública vuelve a un estado verificado. |
| Depurar después | Builder | La versión rota se corrige sin presión pública. |
El playbook es aburrido a propósito. Eso ayuda cuando una página pública está rota.
Cuándo el rollback deja de ser opcional
Para una vista previa descartable, tal vez no sea indispensable.
Se vuelve importante cuando:
- el sitio ya usa dominio personalizado;
- un cliente, reclutador, profesor o campaña ya tiene el enlace;
- más de una persona puede publicar;
- el error afecta reputación, ingresos, reclutamiento o soporte;
- trabajas con exports de IA o archivos entregados por terceros;
- las copias manuales en ZIP ya no son confiables.
En ese punto, el rollback no es lujo. Es lo que permite actualizar sin tratar cada publicación como un camino sin regreso.