Guía
Cada cuánto hay que actualizar un sitio web
Actualizar todo apenas aparece el aviso es tan riesgoso como no actualizar nunca. Esta guía explica qué frecuencia corresponde a cada tipo de actualización, cómo distinguir las urgentes y qué hacer para que una actualización no te deje el sitio caído.
- Por qué las actualizaciones no son todas iguales
- Cada cuánto conviene aplicar cada una
- Cómo distinguir una urgente de una que puede esperar
- Qué hacer para que una actualización no te deje caído
- Señales de alarma
- Cómo lo hacemos nosotros
Hay dos formas de romper un sitio con las actualizaciones: no aplicarlas nunca y aplicarlas todas apenas aparecen. La primera acumula vulnerabilidades conocidas; la segunda te deja el sitio caído un martes a la mañana.
El criterio que separa una cosa de la otra no es técnico: es saber qué tipo de actualización estás mirando.
Por qué las actualizaciones no son todas iguales
Un sitio moderno combina piezas de autores distintos: el sistema base, las extensiones, la plantilla de diseño, y por debajo el lenguaje que corre en el servidor. Cada una avanza por su cuenta y ninguna coordina con las demás.
Eso produce dos clases de actualización con lógicas opuestas. Una corrige una vulnerabilidad ya publicada: cuanto antes se aplique, mejor, porque la publicación de la falla es exactamente lo que dispara los escaneos automáticos que la buscan. La otra cambia cómo funciona una pieza: cuanto más se apure, más riesgo, porque los problemas de una versión recién salida los descubre quien la instala primero.
Tratar a las dos igual es lo que hace que la gente termine en uno de los dos extremos.
Cada cuánto conviene aplicar cada una
- Correcciones de seguridad del sistema base — el mismo día. Sin excepción
- Correcciones de seguridad de una extensión — el mismo día, y si no hay parche disponible, desactivar la extensión hasta que lo haya
- Versiones nuevas de extensiones sin urgencia — en una tanda mensual, después de unos días de reposo
- Versiones mayores del sistema base — a las pocas semanas de publicadas, con prueba previa
- La plantilla de diseño — mensual, y con más cuidado que el resto: es donde más suele haber personalizaciones que se pierden
- La versión del lenguaje del servidor — una o dos veces por año, con prueba previa obligatoria
- Revisión de extensiones abandonadas — trimestral. Una sin actualizar en más de un año hay que reemplazarla, no esperarla
Cómo distinguir una urgente de una que puede esperar
No hace falta leer código. Alcanza con mirar tres cosas.
Qué dice la nota de la versión. Si menciona una corrección de seguridad, es urgente. Los autores serios lo indican de forma explícita, y en general con un número de referencia público.
Qué tan usada es la extensión. Cuanto más popular, antes aparecen los ataques automatizados una vez publicada la falla, porque hay más sitios donde probar.
Qué hace la extensión. Las que reciben datos de visitantes —formularios, comentarios, carritos, subida de archivos— son las que más conviene mantener al día. Las decorativas pueden esperar unos días.
Si después de mirar esas tres cosas seguís con dudas, aplicala. El riesgo de actualizar una corrección de seguridad es siempre menor que el de no hacerlo.
Qué hacer para que una actualización no te deje caído
- Copia de seguridad verificada antes de tocar nada. No la de anoche: una hecha ahora y que sepas que restaura
- Probar en una copia del sitio, no en el publicado. Un entorno de prueba no es un lujo de proyectos grandes; es lo que separa un susto de una caída
- Actualizar de a una cuando son piezas críticas, para saber cuál rompió qué si algo falla
- Revisar después, no solo antes. Que la portada cargue no alcanza: hay que probar el formulario, el buscador y, si vende, el proceso de compra completo
- Tener el camino de vuelta claro. Saber cómo restaurar la copia, y en cuánto tiempo, antes de necesitarlo
El punto 5 es el que convierte todo lo anterior en algo manejable. Si volver atrás lleva diez minutos, una actualización fallida es una molestia. Si nadie sabe cómo volver, es una crisis.
Señales de alarma
El contador de pendientes pasa de diez. Hace meses que nadie mira el sitio.
Hay extensiones sin actualizar hace más de un año. Están abandonadas por su autor y no van a recibir correcciones.
El sitio corre una versión del lenguaje sin soporte. Las correcciones de seguridad ya no llegan, por más que actualices todo lo demás.
Nadie se anima a actualizar por miedo a romper algo. Es una situación real y muy común, y significa que falta lo anterior: copias verificadas y un entorno donde probar. El miedo es razonable; lo que falta es la red.
Las actualizaciones automáticas están activadas y no hay monitoreo. Si una rompe el sitio un sábado, nadie se entera hasta el lunes.
Cómo lo hacemos nosotros
- Revisamos qué cambia cada versión antes de aplicarla, y separamos las de seguridad de las demás
- Aplicamos las de seguridad el mismo día, con copia verificada previa
- Agrupamos el resto en una tanda mensual, después de unos días de reposo
- Probamos en una copia del sitio antes de tocar el publicado
- Verificamos después: formularios, buscador y, en tiendas, el proceso de compra
- Informe mensual de qué se actualizó y qué se revisó
Si hace tiempo que nadie actualiza tu sitio, el diagnóstico te dice en qué estado está antes de tocar nada. Y si una actualización ya te dejó el sitio con problemas, mirá qué hacer cuando una actualización rompió el sitio.
Preguntas frecuentes
Si tu duda no está acá, escribinos y te respondemos sin compromiso.
Hacer una consultaAtención personalizada las 24 horas
¿Cada cuánto hay que actualizar WordPress?
Las correcciones de seguridad, el mismo día en que se publican. El resto conviene agruparlo en una tanda mensual, después de dejar pasar unos días para que los problemas de la versión nueva salgan a la luz. Un sitio con una decena de extensiones recibe entre veinte y cuarenta actualizaciones por mes.
¿Puedo dejar las actualizaciones automáticas activadas?
Para las de seguridad del núcleo, en general sí y conviene. Para las extensiones es más discutible: una actualización automática que rompe algo lo hace sin que nadie esté mirando, y el sitio puede quedar caído durante horas. Si están activadas, hace falta monitoreo que avise cuando el sitio deja de responder.
¿Qué pasa si no actualizo nunca?
Las vulnerabilidades corregidas se publican, y esa publicación es lo que usan los ataques automatizados para buscar sitios sin actualizar. No es que el sitio se degrade solo: es que la lista de puertas conocidas crece cada mes mientras el sitio se queda donde estaba.
¿Por qué una actualización rompe el sitio?
Porque un sitio combina piezas de autores distintos que evolucionan a ritmos distintos. Cuando una cambia su forma de funcionar, otra que dependía de la anterior deja de entenderse con ella. No es un error de nadie en particular: es la consecuencia de un sistema con muchas partes.
¿Conviene actualizar la versión de PHP?
Sí, pero con prueba previa. Es la actualización que más beneficio da en velocidad y seguridad, y también la que más cosas puede romper si el sitio usa extensiones viejas. Se prueba en una copia antes de aplicarla al sitio publicado.
¿Querés que le echemos un vistazo?
Mandanos la URL de tu sitio y te decimos qué le pasa. El diagnóstico no se cobra y no te compromete a nada.
- Diagnóstico gratis en menos de 2 horas hábiles
- Presupuesto cerrado antes de tocar nada
- Pagás contra trabajo terminado y verificado