¿Se puede actualizar un sitio web sin dejarlo fuera de servicio?

Muchas actualizaciones pueden aplicarse mientras el sitio web actual sigue disponible. Esto suele ser viable para cambios de contenido y diseño, páginas nuevas y versiones de software preparadas con cuidado.

No es una garantía válida para cualquier cambio. Una actualización que afecte a pedidos en curso, cuentas de usuario, versiones de software incompatibles, infraestructura o un servicio externo puede requerir una ventana de mantenimiento definida. La pregunta útil no es solo si el sitio estará en línea. Hay que saber qué seguirá funcionando, cómo se comprobará el cambio y qué ocurrirá si no funciona como se esperaba.

¿Qué actualizaciones se pueden hacer con el sitio en funcionamiento?

Las correcciones de texto, los cambios de imágenes, los artículos y páginas nuevos y los ajustes visuales aislados suelen poder prepararse y publicarse sin desconectar todo el sitio. También se pueden desplegar cambios de software pequeños cuando el sitio y el proceso de publicación lo permiten.

El tipo de actualización por sí solo no resuelve la cuestión. Un cambio de contenido habitual puede afectar a los menús, la búsqueda, las páginas en caché o los archivos generados de un sitio, y modificar una sola página en otro. Incluso una tarea conocida debe evaluarse dentro del sistema donde se realiza.

«En línea» también debe tener un significado práctico. Que la página de inicio cargue correctamente no demuestra que funcionen las consultas, los pagos, los inicios de sesión, las búsquedas o la administración. Las partes importantes para la empresa necesitan comprobaciones propias.

¿Qué protege un sitio de pruebas?

Un sitio de pruebas es un entorno separado donde se prepara y revisa un cambio antes de mostrarlo a los visitantes. Puede evitar que aparezcan en el sitio público diseños incompletos, textos sin terminar o fallos funcionales evidentes durante el trabajo.

Las pruebas reducen la incertidumbre, pero no la eliminan. La copia de pruebas puede tener otros datos, tráfico, configuración, credenciales, servicios conectados o recursos de servidor. Una prueba satisfactoria aporta información útil, pero no garantiza que producción se comporte igual.

El plan de publicación todavía debe indicar qué se comprobará después de aplicar el cambio al sitio público.

¿Cómo puede sustituirse una versión por otra sin mostrar una página en blanco?

Una opción consiste en preparar la versión nueva por separado mientras la actual sigue atendiendo a los visitantes. El tráfico se cambia solo después de probar la versión preparada. Si surge un problema grave, se puede devolver el tráfico a la versión anterior.

Este método suele llamarse despliegue blue-green. AWS lo describe como el traslado del tráfico entre dos entornos que ejecutan distintas versiones de una aplicación. Busca que la interrupción sea casi nula y que el retorno al entorno anterior sea más rápido.

El despliegue blue-green no es la única forma de publicar una actualización. Algunos sistemas sustituyen archivos de forma atómica, actualizan un servidor cada vez, envían solo parte del tráfico a la nueva versión o activan una función ya terminada cuando todo lo que necesita está listo. El método adecuado depende del sitio, el alojamiento, los datos y las consecuencias de un fallo.

¿Por qué son distintos los cambios en la base de datos?

Una base de datos puede contener pedidos actuales, cuentas, reservas, envíos de formularios, existencias, membresías o contenido publicado. Durante una publicación, puede que tanto la versión antigua como la nueva del sitio deban funcionar con esos datos.

Si cambia la estructura de la base de datos de forma que solo una versión del software la entienda, volver a la versión anterior puede dejar de ser sencillo. Los cambios prolongados también pueden competir con la actividad normal del sitio. Por eso algunos despliegues separan la preparación de la base de datos de la actualización de la aplicación, mantienen la compatibilidad entre estructuras antiguas y nuevas durante un tiempo o trasladan los datos en lotes controlados.

La guía pública de GitLab para migraciones de bases de datos muestra el nivel de detalle que puede requerir esta planificación. Distingue migraciones normales, posteriores al despliegue y en segundo plano, y contempla tiempos, reversibilidad, transacciones y contención de bloqueos. Esos métodos concretos no sirven para todos los sitios, pero el principio general sí: los cambios en datos activos necesitan su propio plan de publicación y recuperación.

¿Una copia de seguridad equivale a volver atrás?

No. Una copia de seguridad es una copia conservada de datos o archivos que se puede restaurar. Volver atrás es un procedimiento preparado para regresar a un estado conocido y funcional después de una publicación fallida.

Restaurar una copia puede llevar tiempo y sobrescribir pedidos, consultas, ediciones o cambios de cuenta válidos que se hayan realizado después de crearla. El código del sitio puede revertirse rápidamente, pero eso no necesariamente deshace un cambio en la base de datos ni una operación ya completada por un servicio externo de pagos, reservas o correo electrónico.

Un plan responsable define qué se puede revertir, qué debe corregirse mediante una nueva modificación y qué hacer con los datos creados durante el cambio. Las recomendaciones de AWS para cambios fallidos aconsejan preparar la recuperación antes del despliegue y usar la supervisión para decidir si el cambio ha funcionado.

¿Por qué alguien puede seguir viendo la página anterior?

El sitio puede mantenerse disponible durante toda la actualización y, aun así, mostrar brevemente versiones distintas de una página o archivo a diferentes visitantes. Los navegadores, las redes de distribución de contenido, las cachés de servidor y las páginas generadas pueden conservar contenido anterior hasta que caduque, se vuelva a validar o se elimine de forma deliberada.

Eso es distinto de una interrupción. Aun así, importa cuando la actualización modifica precios, condiciones, detalles de una campaña, disponibilidad u otra información sujeta a plazos.

También conviene limitar la limpieza de caché a lo necesario. Cloudflare recomienda, siempre que sea posible, purgar elementos concretos porque vaciar toda la caché hace que las siguientes solicitudes vuelvan al servidor de origen hasta reconstruirla. El plan debe identificar las páginas y archivos modificados, en vez de tratar todas las cachés como un único bloque desechable.

¿Cuándo es responsable programar una ventana de mantenimiento?

Puede ser adecuado hacerlo cuando mantener toda la actividad del sitio suponga más riesgo que una interrupción breve y comunicada. Por ejemplo, si:

• los datos en curso no se pueden modificar de forma segura durante la actualización;
• las versiones antigua y nueva no pueden funcionar con la misma estructura de datos;
• hay que cambiar la infraestructura o el encaminamiento de red en un único paso controlado;
• un proveedor externo exige una interrupción o no ofrece una vía de prueba en paralelo;
• aún no se conoce suficientemente el sitio actual para modificarlo en directo con seguridad;
• la recuperación sería más clara y rápida si se pausara la actividad durante un periodo definido.

La ventana debe tener una razón, un alcance, una duración prevista, un criterio de recuperación y un plan de comunicación. Para una empresa que depende de consultas, pedidos, reservas o acceso de miembros, no basta con decir «el sitio no estará disponible por mantenimiento».

¿Qué deberíamos preguntar antes de aprobar la actualización?

• ¿Qué páginas y funciones cambiarán?
• ¿Qué podrán seguir haciendo visitantes y personal durante el trabajo?
• ¿Se preparará el cambio en un entorno separado del sitio público?
• ¿Cómo se protegerán las consultas, los pagos, las reservas, los cambios de cuenta y otros datos en curso?
• ¿Qué comprobaciones confirmarán que la publicación ha funcionado?
• ¿Cuál es el plan de recuperación si falla alguna comprobación?
• ¿Se puede revertir el software sin deshacer datos nuevos válidos?
• ¿Influyen en el calendario el alojamiento, los pagos, el correo, la identidad, las reservas u otros servicios externos?
• ¿Quién decide si se continúa, se repara o se vuelve atrás?
• ¿Cómo y cuándo se informará a los usuarios afectados?

Las respuestas no tienen que describir cada comando técnico. Deben dejar claro el efecto para la empresa.

¿Cómo aborda LINK-V las actualizaciones web?

Cuando evaluamos o mantenemos un sitio, revisamos el sitio web, el alojamiento, el CMS, la base de datos, las integraciones, las copias de seguridad, los accesos y los riesgos operativos antes de decidir cómo publicar el trabajo. El método adecuado depende del cambio y del sistema existente.

Buscamos que las actualizaciones habituales sean tranquilas y proporcionadas, y explicamos claramente cuándo un cambio requiere una interrupción controlada. Si su sitio permite ventas diarias, consultas, reservas, membresías o publicaciones, podemos evaluar su configuración de mantenimiento y cuidado continuo.