Las actualizaciones de WordPress son esenciales para mantener un sitio web seguro, pero también son una de las mayores fuentes de ansiedad para las agencias web. Pedimos a Sébastien Cavaillé, Product Marketing Manager en OVHcloud, que explicara cómo se diseñó Smart Automatic Updates para resolver este dilema.
Cualquier agencia que gestione sitios web de WordPress sabe lo difícil que es equilibrar la necesidad de hacer actualizaciones con la falta de tiempo y recursos para llevarlas a cabo. Por un lado, las actualizaciones no pueden esperar: según el último informe anual del especialista en seguridad de WordPress Patchstack, se registraron 11 334 nuevas vulnerabilidades en 2025, el 91% de ellas en plugins, el 9% en temas y solo seis en el núcleo de WordPress. Y los atacantes actúan rápido: casi la mitad de las vulnerabilidades de alto impacto se explotan en las 24 horas siguientes a su publicación. Un plugin desactualizado es uno de los puntos de entrada más habituales para un atacante, y cuanto más tiempo se posponga una actualización, más tiempo estará expuesto el sitio web.
Pero, por otro lado, cada actualización conlleva un riesgo: un plugin incompatible, un tema que ya no se visualiza correctamente, una página que de repente devuelve un error. Para evitar asumir ese riesgo a ciegas, muchas agencias revisan cada sitio manualmente. Eso requiere una cantidad considerable de tiempo cuando gestionas decenas o incluso cientos de sitios web. Y cuando el tiempo es escaso, las actualizaciones se posponen, a veces durante semanas o meses.
Para resolver este dilema, los equipos de OVHcloud han desarrollado Smart Automatic Updates, una funcionalidad incluida en Managed Hosting for WordPress. Para entender mejor este problema, hablamos con Sébastien, quien trabajó en el proyecto.
¿De dónde surgió la idea del proyecto?
Surgió directamente de nuestros clientes. En nuestra plataforma de hosting compartido, alojamos alrededor de 6 millones de sitios web, y el 80% de ellos funciona con WordPress. Esto nos aporta mucha información, y había una necesidad que surgía una y otra vez: la gente sabe que tiene que mantener sus sitios actualizados, pero muchos ya han pasado por una actualización que salió mal, y no tienen tiempo para revisar cada sitio a mano.
Las actualizaciones automáticas tradicionales resuelven el problema de seguridad, pero crean otro, porque a menudo te enteras de que un sitio está roto cuando un cliente llama. Buscábamos una automatización que comprobara todo antes de aplicar los cambios.
Hay una historia en particular que se nos quedó grabada. Un desarrollador web freelance dirigía una agencia unipersonal y gestionaba él solo decenas de sitios de WordPress para sus clientes. Se hizo pública una vulnerabilidad en un plugin que usaban muchas de esas webs y, simplemente, no tuvo tiempo de actualizarlas todas antes de que un atacante se le adelantara. En poco tiempo, 36 de los sitios web de sus clientes habían sido hackeados y redirigían a los visitantes a sitios web maliciosos.
Limpiar las webs fue solo una parte; lo más difícil fue dar la cara ante sus clientes. Todos habían confiado en él para proteger sus webs, y todos descubrieron que sus visitantes habían sido redirigidos a páginas peligrosas. Para un freelance cuyo negocio depende de la reputación y el boca a boca, ese tipo de daño a su credibilidad tarda mucho más en repararse que los propios sitios web.
Desde entonces, ha trasladado los sitios de sus clientes a Managed Hosting for WordPress y nos ha cedido el trabajo de mantenerlos actualizados. Su historia es exactamente el tipo de situación que queríamos evitar: no porque hiciera nada malo, sino porque nadie puede mantener actualizados manualmente decenas de sitios, semana tras semana.
¿Cómo se prueban las actualizaciones de WordPress?
El principio es no probar nunca una actualización directamente en el sitio en producción.
¿Cuáles son las cuatro etapas de prueba?
Cada día, comprobamos si hay nuevas actualizaciones disponibles. Cada actualización se prueba entonces siguiendo cuatro pasos.
Primero, se realiza un snapshot del sitio tal y como funciona en ese momento. Un rastreador empieza desde la página de inicio y sigue los enlaces de forma recursiva: si la página de inicio enlaza a la página A, que enlaza a la página B, que enlaza a la página C, entonces la página C también se analiza. Analizamos hasta 50 páginas por sitio. Para cada página, registramos el código de estado HTTP devuelto por el servidor, que muestra si la página se carga normalmente o devuelve un error, junto con una captura de pantalla de página completa a una resolución de 1920×1080.
A continuación, clonamos el sitio en un entorno de pruebas aislado. En ese clon, y solo en ese clon, es donde aplicamos las actualizaciones a WordPress, los temas y los plugins.
En tercer lugar, analizamos el clon exactamente de la misma manera que el sitio original, con las mismas páginas, los mismos códigos de estado HTTP y las mismas capturas de pantalla.
Por último, comparamos ambos. Esa comparación decide si la actualización se puede aplicar a producción.
¿Qué hace que una actualización sea válida?
Se deben cumplir tres condiciones:
- Los códigos de estado HTTP son idénticos. Si una página que funcionaba antes ahora devuelve un error, la actualización se bloquea.
- Las capturas de pantalla coinciden, con una pequeña tolerancia para las diferencias visuales.
- Cada actualización de tema y plugin se ha instalado sin errores.
La comparación visual es muy estricta, por diseño. Un píxel se considera diferente en cuanto cualquiera de sus valores rojo, verde o azul cambia aunque sea una sola unidad. No hay ninguna tolerancia de color. Lo que sí toleramos es una pequeña proporción de píxeles cambiados: hasta el 5% de la página. Así que el umbral mide cuánto ha cambiado la página, no cuánto ha cambiado cada píxel.
Antes de realizar cada captura de pantalla, esperamos unos segundos para dejar que terminen las animaciones de carga y efectos similares.
¿Cómo se evitan las falsas alarmas?
Muchos sitios tienen carruseles, animaciones o contenido que cambia constantemente. Ese fue uno de los problemas más interesantes que tuvimos que resolver. En las primeras pruebas, nos sorprendió la cantidad de actualizaciones que se marcaban como fallos, a pesar de que nada parecía roto cuando revisábamos los sitios manualmente. Cuando analizamos las capturas de pantalla, los culpables eran casi siempre los mismos: deslizadores de la página de inicio que habían pasado a la siguiente imagen, temporizadores de cuenta atrás en sitios de eventos, widgets de «últimas publicaciones» o feeds de redes sociales integrados que se habían actualizado entre dos capturas. Las actualizaciones estaban bien; las páginas simplemente estaban vivas.
La solución fue tomar varias capturas de pantalla de cada página con unos segundos de diferencia. Si la página cambia por sí sola entre dos capturas de pantalla, el sistema la marca como dinámica y la excluye de la comparación visual. Sin embargo, estas páginas no se quedan sin revisar: sus códigos de estado HTTP se siguen comparando, por lo que una página dinámica que empiece a devolver un error seguirá bloqueando la actualización. Una vez que añadimos ese paso, las falsas alarmas disminuyeron drásticamente y pudimos volver a confiar en la comparación visual.
¿Hasta dónde llega el análisis?
Nos centramos en lo que más importa: las páginas que tus visitantes ven realmente. En la práctica, eso cubre el núcleo de la mayoría de los sitios web: la página de inicio, las secciones principales y las páginas clave por las que navegan los visitantes.
Las páginas a las que no se puede acceder desde la página de inicio, ni siquiera indirectamente, no forman parte del análisis. Es algo intencionado: si una página no está enlazada, los usuarios tampoco podrán acceder a ella navegando por el sitio, así que un error de actualización no afectaría a la experiencia del visitante.
La misma lógica se aplica a las áreas detrás de un inicio de sesión, como las cuentas de cliente o el panel de administración. Cada sitio gestiona la autenticación a su manera, así que decidimos concentrarnos en las páginas públicas, donde podemos realizar comprobaciones fiables y coherentes a gran escala.
La idea no es reemplazar la experiencia de una agencia, sino encargarnos de las comprobaciones repetitivas que, de otro modo, harían a mano, sitio tras sitio. Eso les libera tiempo para dedicarse al trabajo que solo ellos pueden hacer.
Cuando una prueba se supera o falla
¿Qué pasa cuando la validación falla?
No pasa nada en el sitio en producción, y ese es precisamente el objetivo. Si algún criterio no se cumple, las actualizaciones no se aplican. El sitio sigue funcionando exactamente igual que antes.
Entonces el cliente recibe un correo electrónico explicando por qué falló la validación. Hay cuatro causas posibles:
- Los plugins o temas no pudieron actualizarse completamente en el sitio de prueba.
- La página de inicio devolvió un error 4xx o no estaba accesible, por lo que la prueba no pudo realizarse.
- Las respuestas HTTP difieren entre el sitio original y el clon.
- Las capturas de pantalla difieren entre ambas.
El correo también te da acceso al sitio clonado, donde se han aplicado las actualizaciones. La agencia puede ver el problema, arreglarlo directamente en el clon y luego activar la actualización de producción ellos mismos una vez que todo esté en orden.
Fuimos firmes en este punto: la automatización se encarga del trabajo repetitivo, pero nunca toma una decisión arriesgada en nombre de la agencia. Ante la duda, un humano mantiene el control.
¿Cómo se publica una actualización validada?
Una vez que la actualización ha sido validada, se aplica a producción poco después y se notifica al cliente.
No hay una reversión automática como tal, ya que la actualización ya ha sido probada antes de publicarse. Pero si aparece un problema después, puedes restaurar una copia de seguridad con un solo clic desde el Área de cliente de OVHcloud. Las copias de seguridad se hacen sitio por sitio en lugar de para todo el plan de alojamiento, por lo que una agencia puede restaurar el sitio de un cliente sin tocar ninguno de los otros.
¿Se pueden excluir plugins de las actualizaciones?
No, y es una decisión deliberada. Cuando alguien quiere excluir un plugin, suele ser por miedo a que la actualización rompa el sitio web. Asegurarnos de que no se rompa nada es precisamente nuestro trabajo.
Algunos casos requieren un tratamiento especial, y nosotros nos encargamos de ellos. Pongamos el ejemplo de WooCommerce: si un sitio utiliza WooCommerce y además una extensión premium cuya licencia ha caducado, esa extensión deja de recibir actualizaciones. Actualizar WooCommerce por separado supondría el riesgo de romper la web, ya que una versión reciente de WooCommerce no es compatible con una versión obsoleta de la extensión. En esa situación, no actualizamos WooCommerce. Cada vez que Smart Automatic Updates detecta casos similares, también nos encargamos de resolverlos.
¿Qué ocurre con los plugins y temas premium?
La norma es sencilla: si puedes hacer clic en «Actualizar» para un plugin o tema en tu panel de administración de WordPress, nosotros lo actualizamos. Si no puedes, por ejemplo porque una licencia ha caducado, no lo hacemos. En ese caso, avisamos al cliente en su Área de cliente de OVHcloud de que el plugin necesita ser actualizado, para que la actualización no pase desapercibida.
¿Qué cambios conlleva esto para las agencias?
Yo diría que tres cosas.
Primero, la seguridad. Las actualizaciones ya no se acumulan porque nadie haya tenido tiempo de revisarlas. Cada sitio web se mantiene actualizado periódicamente, lo que reduce el tiempo durante el cual una vulnerabilidad conocida permanece expuesta.
Segundo, tranquilidad. La agencia ya no tiene que preguntarse si una actualización ha roto un sitio. O bien la actualización se validó y se aplicó, o bien la producción permaneció intacta y se les ha explicado exactamente por qué. Y si alguna vez algo sale mal, el sitio de cada cliente puede restaurarse individualmente con un solo clic, sin afectar a los demás.
Tercero, ahorro de tiempo. Una agencia nos contó que el mantenimiento de sus sitios le ocupa hasta el 30% de su tiempo. Smart Automatic Updates se encarga de las comprobaciones repetitivas, para que las agencias puedan dedicar más tiempo a lo que aporta más valor a sus clientes.
Smart Automatic Updates están incluido en todos nuestros planes de Managed Hosting for WordPress, por lo que cada actualización de WordPress se prueba antes de que llegue a los sitios de tus clientes. Descubre más sobre cómo ayudamos a agencias y freelancers a gestionar sus sitios de WordPress, o lee por qué hemos diseñado managed WordPress hosting de esta manera.
La documentación de Managed Hosting for WordPress explica la configuración y el proceso de actualización con más detalle.