Actualizar el núcleo de WordPress suele ser lo más predecible del proceso de mantenimiento, el equipo de WordPress prueba exhaustivamente cada versión. Los plugins y los temas son harina de otro costal: miles de desarrolladores distintos, con distintos niveles de calidad y de pruebas antes de publicar cada actualización.
Esta guía se centra específicamente en cómo gestionar esa parte del mantenimiento, la que más incidencias genera en la práctica.
Para el proceso general de actualización, parte de Cómo actualizar WordPress sin romper tu web.
Por qué los plugins y temas son el punto más frágil
A diferencia del núcleo de WordPress, que mantiene un único equipo con procesos de prueba consistentes, cada plugin y cada tema los desarrolla un equipo distinto, con sus propios estándares de calidad. Algunos prueban exhaustivamente antes de publicar; otros publican actualizaciones con errores que se corrigen días después en un parche de emergencia.
Cómo priorizar qué actualizar primero
No todos los plugins tienen el mismo riesgo si fallan. Prioriza según impacto:
| Tipo de plugin | Prioridad de prueba antes de actualizar |
|---|---|
| Plugin de pagos o checkout (WooCommerce, pasarelas) | Máxima: probar el proceso completo antes de aplicar |
| Plugin de seguridad | Alta: puede bloquear acceso si se configura mal |
| Plugin de formularios | Alta: probar el envío tras cada actualización |
| Plugin de SEO | Media: revisar que no cambian configuraciones existentes |
| Plugin decorativo (sliders, iconos) | Baja: impacto visual limitado si falla |
Qué revisar antes de actualizar un plugin concreto
- Lee las notas de la versión buscando menciones a cambios de estructura de base de datos, cambios de compatibilidad con otros plugins, o si requiere una versión mínima de PHP distinta a la que usas.
- Revisa si el plugin declara compatibilidad con tu versión actual de WordPress: algunos desarrolladores tardan en actualizar esa compatibilidad declarada aunque el plugin funcione bien igualmente, y otros sí reflejan un problema real de compatibilidad.
- Comprueba la fecha de la actualización anterior: si hay meses de diferencia y de repente se publican varias actualizaciones seguidas en pocos días, puede indicar que se está corrigiendo un problema descubierto recientemente, y conviene esperar a la versión más estable antes de aplicar.
Actualizar temas: el riesgo de las personalizaciones perdidas
El error más costoso al actualizar un tema es perder personalizaciones hechas directamente sobre sus archivos. Si has editado el código del tema directamente (no a través de un child theme), una actualización sobrescribe esos archivos y elimina tus cambios sin previo aviso.
La solución: child themes
Un child theme es un tema “hijo” que hereda toda la funcionalidad del tema principal, pero permite hacer personalizaciones que sobreviven a las actualizaciones del tema padre. Si tu web tiene personalizaciones de código directamente en el tema principal, migrar esas personalizaciones a un child theme antes de la próxima actualización mayor es una inversión que evita perder ese trabajo de golpe.
<?php
// functions.php del child theme
add_action('wp_enqueue_scripts', 'cargar_estilos_padre_e_hijo');
function cargar_estilos_padre_e_hijo() {
wp_enqueue_style('estilo-padre', get_template_directory_uri() . '/style.css');
wp_enqueue_style('estilo-hijo', get_stylesheet_directory_uri() . '/style.css', array('estilo-padre'));
}Este fragmento básico de un child theme carga primero los estilos del tema padre y después los del hijo, permitiendo que las personalizaciones del hijo sobrescriban solo lo que necesites sin perder el resto de la funcionalidad del tema original.
Un child theme necesita además su propio style.css con una cabecera que declare de qué tema hereda. El campo Template es el que hace la magia, y también el error más común: tiene que coincidir exactamente con el nombre de la carpeta del tema padre, no con su nombre visible. Si el padre vive en /wp-content/themes/mitema/, la cabecera es:
/*
Theme Name: Mi Tema Child
Template: mitema
*/Si Template no coincide con el nombre de la carpeta, WordPress muestra el child theme como “roto” y no lo deja activar. Con esos dos archivos (style.css y functions.php) el child theme ya es funcional; a partir de ahí, cualquier plantilla que copies del padre a la carpeta del hijo tiene prioridad sobre la original y sobrevive a las actualizaciones del padre.
Qué hacer si una actualización de plugin cambia una función que usabas
A veces una actualización no rompe nada visiblemente, pero elimina o cambia el comportamiento de una función que dependía de tu configuración específica (por ejemplo, un plugin de formularios que cambia cómo se procesan los archivos adjuntos). Esto suele aparecer en las notas de la versión bajo el apartado de “cambios importantes” o “breaking changes”: la lectura previa de esas notas, aunque parezca un paso que se puede saltar, es precisamente lo que detecta este tipo de sorpresas antes de que ocurran en tu web real.
Cuándo NO actualizar de inmediato
Hay situaciones donde esperar unos días es la decisión correcta:
- Cuando la actualización es una versión mayor recién publicada (los primeros días son cuando aparecen la mayoría de reportes de incompatibilidad de otros usuarios).
- Cuando tienes un evento importante próximo (un lanzamiento, una campaña) y prefieres no arriesgarte a una incompatibilidad justo antes.
- Cuando el changelog no está disponible o es muy escueto, y no puedes evaluar el riesgo real del cambio.
Cómo probar compatibilidad antes de aplicar en toda tu instalación
Más allá de leer el changelog, hay una comprobación práctica que reduce mucho el riesgo: activa la actualización solo en staging y navega específicamente por las páginas que usan las funciones de ese plugin concreto, no solo la home. Si es un plugin de formularios, prueba el formulario; si es un plugin de SEO, revisa que las metaetiquetas se sigan generando correctamente; si es un plugin de caché, purga y vuelve a comprobar que las páginas cargan bien.
Esta comprobación dirigida es más eficiente que una revisión genérica de “parece que todo funciona”, porque va directamente a la función que el plugin actualizado podría haber cambiado.
Actualizar de una en una o en bloque: cuándo cada opción
Con una web con veinte plugins, actualizar de uno en uno es lento pero tiene una ventaja enorme: si algo se rompe, sabes exactamente qué lo rompió. Actualizar todo de golpe es rápido, pero si aparece un fallo te deja sin saber cuál de los cambios fue el culpable. La regla práctica que usamos: los plugins críticos (pagos, seguridad, formularios) van de uno en uno, verificando entre cada uno; los de bajo riesgo pueden ir en tandas pequeñas.
Si te manejas con la línea de comandos, WP-CLI hace este proceso mucho más controlable que el panel. Primero mira qué hay pendiente sin tocar nada:
wp plugin list --update=availablePuedes simular la actualización antes de aplicarla para ver qué versiones se instalarían:
wp plugin update --all --dry-runY actualizar un plugin concreto (el crítico que quieres controlar por separado) en lugar de todos:
wp plugin update woocommerceLa ventaja de hacerlo así en staging es que cada comando queda registrado: tienes la traza exacta de qué se cambió y en qué orden, que es justo lo que necesitas si luego hay que revertir algo.
Cómo revertir una actualización que salió mal
Aunque hagas todo bien, alguna actualización acabará causando un problema que solo se ve en producción. Tener claro de antemano cómo revertir marca la diferencia entre un susto de diez minutos y una tarde perdida. Hay tres vías, de menos a más drástica:
-
Reinstalar la versión anterior del plugin. Si sabes qué versión funcionaba, WP-CLI la reinstala forzando la sobrescritura:
wp plugin install woocommerce --version=8.5.2 --forceOjo: esto revierte los archivos del plugin, pero no deshace los cambios que la versión nueva haya podido hacer ya en la base de datos. Por eso funciona bien para plugins que solo tocan código, y peor para los que migran datos al actualizar.
-
Restaurar desde el backup previo a la actualización. Es la vía segura cuando la actualización tocó la base de datos, precisamente porque devuelve también los datos a su estado anterior. Requiere tener un backup inmediatamente anterior al cambio, otra razón para hacer siempre un backup justo antes de actualizar, no “el de esta mañana”.
-
Desactivar el plugin y buscar alternativa. Si la versión rota es la única disponible y no hay a dónde volver, a veces la salida menos mala es desactivar temporalmente esa función mientras se resuelve.
El error clásico es descubrir el problema y ponerse a improvisar sin plan. Si antes de cada actualización de riesgo te preguntas “¿cómo volvería atrás si esto falla?” y la respuesta es clara, la mitad del riesgo ya está gestionado. La otra mitad es tener un backup verificado al que volver de verdad.
Un caso real: una actualización de tema que casi cuesta el diseño personalizado
Un cliente con varios años de personalizaciones visuales hechas directamente sobre el código de su tema (sin child theme) recibió el aviso de una actualización mayor del tema con mejoras de rendimiento notables. Antes de aplicarla, migramos primero esas personalizaciones a un child theme recién creado, un proceso de varias horas de trabajo, pero que garantizó que la actualización del tema no eliminara ese trabajo previo.
Al aplicar la actualización con el child theme ya en su lugar, el tema principal se actualizó sin ningún problema, y las personalizaciones (colores de marca, ajustes de espaciado, una sección personalizada en el pie de página) sobrevivieron intactas. Sin ese paso previo, la actualización habría sobrescrito meses de ajustes visuales acumulados, obligando a rehacerlos desde cero.
Preguntas Frecuentes
¿Debo actualizar un plugin aunque no use ninguna de sus funciones nuevas? Sí, especialmente si la actualización incluye correcciones de seguridad, estas se aplican independientemente de si usas o no las nuevas funciones añadidas.
¿Qué es un child theme y cuándo lo necesito? Es un tema que hereda del tema principal pero permite personalizaciones que no se pierden al actualizar. Lo necesitas en cuanto empieces a modificar directamente el código del tema principal.
¿Puedo crear un child theme si ya llevo tiempo con personalizaciones directas en el tema? Sí, aunque requiere trasladar manualmente esas personalizaciones al nuevo child theme, es más trabajo hacerlo después que desde el principio, pero sigue siendo mejor que perderlas en la próxima actualización.
¿Cómo sé si un plugin es compatible con mi versión de WordPress antes de actualizar? La página del plugin (si es del repositorio oficial) muestra la compatibilidad probada con las versiones más recientes de WordPress. Si tu versión no aparece cubierta, conviene extremar la precaución.
¿Actualizar el tema afecta al contenido ya publicado? No debería afectar al contenido en sí, pero sí puede afectar a cómo se muestra visualmente si el tema cambia su estructura de plantillas.
¿Qué hago si un plugin deja de recibir actualizaciones del desarrollador? Es una señal de riesgo creciente de seguridad. Busca una alternativa activamente mantenida y planifica la migración con tiempo, no cuando ya sea urgente.
¿Debo probar cada actualización de plugin en staging aunque parezca menor? Para plugins de bajo riesgo (decorativos, sin impacto en funciones críticas), puedes ser más flexible. Para plugins de pagos, seguridad o formularios, probar siempre es la recomendación, sin excepciones.
¿Las actualizaciones de tema suelen ser más o menos arriesgadas que las de plugins? Depende del tema, pero en general los temas premium bien mantenidos son más predecibles que plugins de nicho con menos usuarios y menos pruebas antes de publicar.
¿Necesito un child theme incluso si nunca he tocado el código del tema? No es imprescindible si no tienes personalizaciones directas, pero es una buena práctica preventiva tenerlo listo desde el principio, por si en el futuro decides hacer algún ajuste puntual.
¿Puedo revertir una actualización de plugin si algo sale mal? Depende del plugin, algunos permiten volver a una versión anterior directamente desde el repositorio; otros requieren restaurar desde un backup previo a la actualización si no existe esa opción de reversión directa.
¿En qué orden debería actualizar: núcleo, plugins o tema primero? Lo habitual es núcleo primero, luego plugins y por último el tema, porque plugins y tema suelen declarar compatibilidad con una versión de WordPress concreta. Aun así, si un plugin crítico avisa de que su nueva versión requiere una versión de WordPress que aún no tienes, ese orden se ajusta caso a caso. Lo importante no es la secuencia rígida, sino verificar después de cada paso antes de dar el siguiente.
¿Reinstalar la versión anterior de un plugin deshace también sus cambios en la base de datos? No necesariamente. Reinstalar una versión anterior revierte los archivos del plugin, pero si la versión nueva ya migró o modificó datos en la base de datos, esos cambios pueden quedarse. Por eso, para plugins que tocan la base de datos al actualizar, la reversión segura es restaurar desde un backup previo, no solo cambiar la versión del plugin.
¿Es seguro usar la actualización automática de plugins que ofrece WordPress? Para plugins de bajo riesgo puede ahorrarte trabajo, sobre todo para parches de seguridad menores. Pero activarla en plugins críticos (pagos, seguridad, formularios) elimina justo el paso de probar en staging antes de aplicar, que es lo que evita las roturas caras. La recomendación es activarla solo donde el coste de un fallo sea bajo.
¿Cada cuánto debería revisar si hay actualizaciones de plugins pendientes? Semanal o quincenal es un ritmo razonable para la mayoría de webs, con la excepción de los parches de seguridad críticos, que conviene aplicar en cuanto se publican aunque sea fuera de ese calendario. Dejar que se acumulen durante meses es lo que convierte una tarea de rutina en una actualización masiva y arriesgada.
Conclusión
Actualizar plugins y temas con seguridad no es cuestión de suerte, es cuestión de priorizar según impacto real, revisar las notas de cada versión, y proteger tus personalizaciones con un child theme en lugar de editar directamente el código del tema principal.
Si prefieres no tener que evaluar el riesgo de cada actualización de plugin tú mismo, en Avantys revisamos y probamos cada una dentro de la gestión continua en Gestión WordPress.
Artículos relacionados
- Cómo actualizar WordPress sin romper tu web
- Mantenimiento y actualizaciones de WordPress sin sustos
- Staging en WordPress: cómo montarlo paso a paso
- Errores críticos de WordPress y cómo solucionarlos
- Cómo reducir el impacto de los plugins en la velocidad de WordPress
¿Y si tu WordPress lo lleváramos nosotros?
Actualizaciones, seguridad, backups verificados, staging y rendimiento, gestionado de forma continua por una persona que responde, donde ya lo tengas o te lo montamos. Auditoría gratuita de tu web actual.
