Actualizar WordPress sin romper nada (y para qué sirve un clon de pruebas)

Resumen: Actualizar WordPress es imprescindible por compatibilidad y por seguridad, pero hacerlo todo de golpe y sin pensar es la causa más común de webs caídas. La forma segura: copia de seguridad antes; leer qué cambia y esperar entre una semana y 10 días, salvo que sea de seguridad; actualizar de una en una, de menos a más riesgo (plugins, tema y, al final, WordPress); probar las grandes en un clon de pruebas, mejor que un staging; dejar las automáticas solo para las versiones menores de WordPress y poco más; y saber volver atrás (rollback o copia) si algo falla.

Hay dos tipos de webs WordPress: las que nunca se actualizan por miedo a romperlas y las que se actualizan todo de golpe con un clic. Las primeras acaban hackeadas; las segundas, con un error crítico un viernes por la tarde. Hay un término medio.

Por qué hay que actualizar WordPress y sus plugins

Hay dos motivos principales:

1. Compatibilidad. Todo en internet evoluciona: los navegadores, PHP, WordPress, el tema y los plugins. Cada pieza depende de las demás, así que tienen que ir a la par para que nada se rompa.
2. Seguridad. WordPress es de código abierto y cada cambio de WordPress, de los temas y de los plugins queda público en su registro de cambios (el changelog): cualquiera puede ver qué se ha corregido en cada versión, incluidos los arreglos de seguridad (en el registro suelen aparecer como security fix o «vulnerabilidad»). Eso incluye a quien tiene malas intenciones: hay bots que recorren internet buscando las webs que aún no han corregido un fallo conocido.

Qué hay que actualizar

• El núcleo de WordPress.
• Los plugins: suelen ser la mayoría de actualizaciones y la mayoría de problemas.
• El tema (y el tema hijo, si lo hay, se mantiene aparte).
• PHP, la versión del servidor, de vez en cuando. Te lo explicaré en otro artículo.

Cuándo actualizar: no el mismo día

No conviene darle a actualizar nada más ver la actualización. Lo mejor es dejar pasar entre una semana y 10 días. A veces sale una actualización que choca con otro plugin o con el tema que aún no están preparados. Si esperas, otras personas lo habrán notado, lo habrán comunicado y el desarrollador habrá sacado una versión de arreglo. Quien está en la comunidad probando novedades puede actualizar al instante; si tu negocio depende de tu web, mejor ser prudente.

Ten especial cuidado con los plugins grandes, que tocan o dependen de muchas otras piezas, como WooCommerce o Elementor.

Lee antes qué cambia la actualización:

• Si solo son mejoras, añadidos o arreglos, puede esperar.
• Consejo de seguridad: si pone security fix, «vulnerabilidad» o «seguridad», actualiza ya, después de hacer la copia de seguridad. Tiene más peso que no te hackeen que el riesgo de que algo se rompa por una incompatibilidad.

Qué te dice el número de versión

WordPress numera sus versiones (por ejemplo, 6.5.1), y ese número te da una pista de cuánto conviene esperar:

• Versión mayor (cambia el primer o el segundo número, como de 6.5 a 6.6): trae novedades y cambios importantes, y por eso es la más arriesgada. Aquí es donde más sentido tiene dejar pasar unos días, hacer copia y comprobar que tus plugins estén preparados (suelen adaptarse semanas antes). Además, las versiones mayores pueden venir con un tema nuevo de WordPress para probar las mejoras y los cambios.
• Versión menor (cambia el último número, como de 6.5.1 a 6.5.2): son arreglos sobre la versión mayor, los errores que han ido encontrando quienes la han probado, y suelen incluir arreglos de seguridad. Son las más seguras de actualizar pronto y, en WordPress, conviene dejarlas automáticas.

Esto vale para WordPress. En los plugins y los temas no hay una norma: cada desarrollador numera como quiere, y una versión «pequeña» puede traer cambios grandes. Por eso, en un plugin, no te fíes solo del número: lee siempre qué cambia en esa actualización.

Cómo actualizar sin romper nada

1. Copia de seguridad completa justo antes.
2. Lee qué cambia (ver arriba): si es de seguridad, no esperes; si no, deja pasar unos días.
3. Prueba en un clon de la web las actualizaciones grandes: del constructor de páginas, de WooCommerce, del tema (más abajo, cómo se hace).
4. Actualiza por partes, no todo de golpe: cuantas más cosas actualizas a la vez, más incompatibilidades pueden aparecer. Si vas poco a poco y algo falla, sabrás qué ha sido.
5. Revisa la web después: portada, formularios, tienda y proceso de compra.

TIP: En una tienda, no actualices WooCommerce ni la pasarela de pago en plena campaña. Elige un momento tranquilo y prueba una compra después.

En qué orden

Si tienes que actualizarlo todo, mi criterio es empezar por los plugins, luego el tema y por último WordPress: de menos a más riesgo. Es un tema donde hay opiniones distintas (hay quien empieza por WordPress y sigue con plugins y tema), y casi todos coinciden en lo importante: copia antes y actualizar de una en una, nunca con «actualizar todo». Y dentro de los plugins, por los que menos daño harían a la web si fallan, no por los que pesan menos:

• Bajo riesgo: un plugin de copias de seguridad, uno que oculta el login o uno como Safe SVG. Si fallan, la web sigue funcionando para tus visitantes; solo pierdes una herramienta tuya.
• Riesgo alto: WooCommerce (lleva la tienda), Elementor (toca todo el diseño) y los formularios. Si uno falla, se rompe la experiencia del visitante, por ejemplo la página de contacto.

Saber cuánto pesa cada plugin en tu web (qué toca, si usa la base de datos, de qué depende) se aprende con la experiencia.

Con los temas

El tema hijo no recibe actualizaciones del tema: solo cambia cuando tú entras a modificar sus archivos. El tema principal se actualiza después de la copia y con los plugins ya al día.

Evita los temas prefabricados de plantillas premium (los de sitios como Envato o Monster Templates): algunos traen plugins dentro, y para actualizar esos plugins tienes que actualizar antes el tema. Justo al revés del orden recomendado.

Clon de pruebas o staging: dónde probar antes de tocar la web real

Antes de una actualización grande, lo más tranquilo es probarla en una copia de tu web que los visitantes no ven. Hay dos formas de tenerla, y se parecen, pero no son lo mismo:

• Clon de pruebas: una copia independiente de tu web, en otra dirección. Lo que haces en ella no vuelve solo a la web real. Si funciona, lo repites a mano en la principal. Es lo que hago yo.
• Staging: también es una copia, pero enlazada a la web real, con un botón para enviar los cambios de la copia a la web de verdad (en inglés, push to live). Muchos hostings lo crean con un clic.

Por qué prefiero el clon

Una web son dos cosas: los archivos (tema, plugins, código) y la base de datos (páginas, ajustes, pedidos, usuarios, comentarios, stock). Al enviar cambios desde un staging, no siempre viaja solo lo que quieres. Y si se sustituye la base de datos, se pierde todo lo que ha pasado en la web real desde que hiciste la copia: pedidos, usuarios nuevos, comentarios o cambios de stock. En una tienda, es un riesgo serio. Las herramientas te dejan elegir qué enviar, pero hay que entender muy bien qué se envía y qué no.

Con un clon no hay nada que sincronizar: pruebas, compruebas que funciona y repites lo mismo en la web real. Con las actualizaciones es fácil: repetirlas es volver a darle al botón.

Cuándo sí tiene sentido un staging

En webs con poco movimiento (una corporativa sin tienda) y en rediseños grandes. Aun así, con cuidado: elige qué enviar y, si hay tienda, pon la web en mantenimiento mientras lo haces para no perder pedidos.

Cómo crear uno

• En tu hosting: hostings como Kinsta, WP Engine o SiteGround traen staging, normalmente con un clic. Mira en su panel si lo incluye tu plan.
• Con un plugin: WP Staging, por ejemplo. Enviar los cambios a la web real solo está en su versión de pago.
• Con un gestor: Modular DS puede restaurar la copia de seguridad de una web en otra web, que es justo un clon, y tiene también una opción para crear un staging a partir de una copia.

Que la copia no se indexe en Google

Es lo más importante de cualquier copia, sea un clon o un staging: si Google la indexa, tienes dos webs iguales compitiendo entre sí y la copia puede acabar posicionando en lugar de la real. Para evitarlo:

• Protégela con contraseña (muchos hostings lo hacen con un clic). Es lo más seguro: ni Google ni nadie entra.
• Activa «Disuadir a los motores de búsqueda de indexar este sitio», en Ajustes > Lectura. Es una petición educada, no una barrera, así que no basta sola.
• Comprueba que no se indexa buscando site:direccion-de-la-copia en Google.
• En un staging, ojo al enviar: esa opción vive en la base de datos, y si envías la base de datos a la web real puedes dejar tu web de verdad pidiendo a Google que no la indexe. Revisa esa casilla después de cada envío.

TIP: Comprueba también que la copia no envíe correos ni cobros reales. Una copia de una tienda que manda emails a tus clientes es un susto que se evita fácil.

¿Actualizaciones automáticas, sí o no?

Por defecto, no, salvo en estos casos:

• Versiones menores de WordPress: sí, son de mantenimiento y seguridad.
• Plugins desactivados que dejas a propósito: si los necesitas por algún motivo, que se actualicen solos. No rompen nada porque no están activos, pero sus archivos siguen en el servidor y podrían tener una vulnerabilidad. Y si no los necesitas, bórralos.
• Plugins que conoces muy bien: si llevas mucho tiempo usándolos y nunca han dado problemas.

El resto, a mano y revisando antes: WooCommerce, el constructor de páginas, el tema y cualquier plugin que toque la tienda o los formularios.

Cómo activarlas o quitarlas

• Plugins y temas: desde WordPress 5.5 puedes elegirlo uno a uno. En Plugins > Plugins instalados hay una columna «Actualizaciones automáticas» con un enlace para activarlas o desactivarlas en cada plugin. En los temas, está en la ventana de detalles del tema (Apariencia > Temas).
• WordPress: las versiones menores se instalan solas por defecto. Quitarlas del todo exige tocar el archivo wp-config.php (la constante WP_AUTO_UPDATE_CORE), y la documentación oficial lo desaconseja, porque son las de seguridad. Si lo haces, que sea sabiendo que a partir de entonces tendrás que actualizar tú, a mano y a tiempo.

Qué hacer si una actualización falla

Si la web se cae

WordPress te manda un correo («tu sitio tiene problemas técnicos») en modo de recuperación. Dice qué plugin o tema falla, el error e incluso la línea concreta, y trae un acceso temporal y seguro para que puedas desactivarlo, borrarlo o volver atrás.

Volver a la versión anterior (rollback)

Una actualización fallida no siempre tumba la web: a veces algo simplemente deja de funcionar. En los dos casos puedes volver a la versión que no daba problemas, o instalar una versión específica, hasta que el desarrollador saque el arreglo:

• Plugins y temas gratuitos (o con versión gratuita): instala WP Rollback, que te deja elegir la versión exacta. Funciona porque el repositorio oficial de WordPress guarda todas las versiones anteriores.
• WordPress, a una versión específica: existe un plugin, WP Downgrade, pero su propia ficha avisa de que lleva tiempo sin probarse con las últimas versiones. Para WordPress es más seguro restaurar la copia de antes de actualizar.
• Plugins de pago como Elementor o WP Rocket: traen su propio rollback (en Elementor, en Herramientas > Control de versiones; en WP Rocket, en su pestaña de herramientas).
• Si nada de esto basta, restaura la copia de antes de actualizar.

Si el fallo no es evidente

A veces algo deja de funcionar sin error claro: hay una incompatibilidad. Se va descartando:

1. Desactiva todos los plugins menos el que da el problema. Si se arregla, es un choque con otro plugin: ve activándolos uno a uno hasta dar con él y avisa a los dos desarrolladores.
2. Si sigue fallando, prueba con otro tema. Si se arregla, el problema es el tema.
3. Si no, revisa la versión de WordPress (aunque llegados a este punto yo ya me plantearía cambiar de plugin).
4. Por último, mira el servidor: la versión de PHP. La página de detalles de cada plugin dice qué versión necesita.

Si cuidas muchas webs: el modo seguro

Cuando tienes muchas webs, ir una a una es lento y se te escapan cosas. Para eso existen gestores como Modular DS, que tiene un modo seguro: antes de actualizar, hace una copia de seguridad instantánea y una «foto» de cómo se ve la web. Actualiza, vuelve a mirar y, si la web ha cambiado de forma notable, vuelve atrás a esa copia (un rollback automático) para que decidas con calma.

Aun así, la regla de siempre se mantiene: de pocas en pocas, porque lanzar muchas actualizaciones a la vez es la mejor forma de que fallen. Y lo que vale dentro de una web vale también entre webs: empieza por las más sencillas, las que no tienen tienda ni plugins tan gordos, y deja para el final las más delicadas. Si una tienda comparte plugins con esas webs, ya habrás comprobado antes que esas actualizaciones no dan problemas, y te llegarás a ella con las incompatibilidades ya descartadas.