Actualizar WordPress con seguridad: copias, pruebas y rollback

#Por qué hay que actualizar WordPress

Descubre nuestros servicios de desarrollo WordPress en WPPoland.

En el ecosistema WordPress, “actualizar” suele verse como una tarea menor, algo que se hace para eliminar un aviso molesto en el panel de administración. Sin embargo, desde la perspectiva de seguridad e ingeniería, actualizar es la tarea de mantenimiento individual más importante que existe. Ejecutar una instancia desactualizada no es simplemente “poco óptimo”: es una invitación abierta a botnets automatizados que rastrean millones de sitios buscando versiones vulnerables.

La pregunta correcta nunca fue “merece la pena actualizar WordPress”. La pregunta real es “puedo permitirme el riesgo de ejecutar software con vulnerabilidades conocidas”. El coste de un sitio hackeado (penalizaciones SEO, pérdida de datos, honorarios de limpieza, daño reputacional) siempre supera los 15 a 20 minutos necesarios para gestionar las actualizaciones de forma responsable.

#Riesgos de no actualizar WordPress

Muchos propietarios de sitios temen que las actualizaciones rompan su web. Aunque esto es posible, la alternativa es una degradación garantizada. Veamos los tres riesgos principales de no actualizar.

#Explotación de vulnerabilidades conocidas

Cuando se publica un parche de seguridad, por ejemplo para una vulnerabilidad de Cross-Site Scripting (XSS) o de inyección SQL, la vulnerabilidad pasa a ser de conocimiento público. Los atacantes analizan esos diffs y alimentan con ellos bots automatizados que escanean millones de sitios buscando la versión sin parchear. Esto sucede en cuestión de horas, no de días.

WordPress es el CMS más popular del mundo y funciona en el 40,0% de todos los sitios web según W3Techs (consultado el 14 de octubre de 2026). Esto lo convierte en el objetivo número uno para ataques automatizados. Cada versión nueva incluye correcciones de seguridad que revelan exactamente dónde estaban los fallos en la versión anterior. Si no actualizas, estás exponiendo esas vulnerabilidades exactas a todo el mundo.

Los ataques más comunes contra sitios WordPress desactualizados incluyen la inyección de malware, la creación de páginas spam ocultas para SEO farmacéutico, la redirección de visitantes a sitios maliciosos y el robo de datos de formularios de contacto o de clientes WooCommerce. Un solo ataque exitoso puede tardar semanas en limpiarse por completo y costar miles de euros en trabajo especializado.

#Versiones de PHP sin soporte (EOL)

Las versiones antiguas de WordPress te obligan a permanecer en versiones de PHP que han alcanzado su fin de vida (EOL, End of Life). PHP 7.4 dejó de recibir parches de seguridad en noviembre de 2022. PHP 8.0 alcanzó su EOL en noviembre de 2023. Cada versión de PHP que queda sin soporte deja de recibir actualizaciones de seguridad, creando una cascada de fallos de seguridad.

Si tu versión de WordPress no es compatible con PHP 8.2 o superior, estás ejecutando tu sitio sobre una base que tiene agujeros de seguridad conocidos tanto en la aplicación como en el runtime. Es como construir una casa sobre cimientos que sabes que están agrietados.

Además, las ramas modernas de PHP 8.x traen mejoras en el motor y en la gestión de memoria que se notan en aplicaciones como WordPress. Al mantenerte en versiones antiguas, estás ejecutando voluntariamente código más lento cuando existe una alternativa directa y gratuita.

#Pérdida de rendimiento y compatibilidad

WordPress evoluciona constantemente. Cada nueva versión trae mejoras de rendimiento del núcleo, nuevas APIs para desarrolladores, mejor soporte para estándares web modernos y optimizaciones de la base de datos. Al no actualizar, te pierdes todas estas mejoras acumulativas.

Además, los plugins y temas más populares acaban dejando de dar soporte a versiones antiguas de WordPress. Esto significa que tus plugins tampoco se podrán actualizar, creando un efecto dominó donde cada componente de tu sitio queda progresivamente más obsoleto y vulnerable. Todo ello repercute en la experiencia de usuario y en las métricas de Core Web Vitals.

#Dónde están realmente las vulnerabilidades de WordPress

El informe anual de Patchstack sobre 2024, State of WordPress Security in 2025, contabiliza 7966 vulnerabilidades nuevas en el ecosistema WordPress durante ese año. El reparto deja claro dónde está el riesgo:

El mismo informe señala que el 33% de las vulnerabilidades no tenía parche en el momento de su divulgación pública, muchas de ellas en plugins abandonados que probablemente nunca se corregirán, y que es habitual que una vulnerabilidad empiece a explotarse en cuestión de horas tras hacerse pública.

Dos conclusiones prácticas. Primera: actualizar solo el núcleo no basta, porque casi todo el riesgo está en las extensiones. Segunda: un plugin sin actualizaciones desde hace mucho tiempo no es un plugin “estable”, sino un candidato a quedarse con una vulnerabilidad sin corregir. Revisar la fecha de la última versión de cada plugin forma parte del mantenimiento tanto como pulsar “Actualizar”.

#Qué versiones de WordPress reciben parches de seguridad

La página de seguridad de WordPress.org (About security) indica que oficialmente solo tiene soporte la última versión de WordPress. El equipo de seguridad lleva las correcciones a ramas antiguas como cortesía, para que los sitios que no han dado el salto a la última versión mayor reciban los parches críticos mediante las actualizaciones automáticas.

Dos ejemplos con fecha muestran cómo funciona:

• WordPress 6.4.3 (30 de enero de 2024) corrigió un bypass de subida de archivos PHP a través del instalador de plugins (requería privilegios de administrador) y una vulnerabilidad de cadenas POP que permitía ejecución remota de código. Incluía además 5 correcciones del núcleo y 16 del editor de bloques, y los parches se llevaron a las ramas desde la 4.1 en adelante (anuncio oficial).
• WordPress 6.5.5 (24 de junio de 2024) corrigió dos vulnerabilidades XSS (una en la HTML API y otra en el bloque Template Part) y un problema de path traversal que afectaba a sitios alojados en Windows (anuncio oficial).

En ambos anuncios, WordPress.org recuerda que en los sitios con actualizaciones automáticas en segundo plano el proceso empieza solo. Ese es el argumento más fuerte para no desactivar las actualizaciones menores: el parche llega aunque nadie entre al panel.

#Cómo actualizar WordPress sin romper tu web

El miedo a romper el sitio es válido, pero la solución no es “no actualizar”, sino “actualizar de forma segura”. Existen protocolos probados que minimizan el riesgo de cualquier actualización.

#Probar las actualizaciones en un entorno de staging

Nunca actualices versiones mayores (por ejemplo, de WordPress 6.4 a 6.5) directamente en producción. Utiliza un entorno de staging. La mayoría de los hosts modernos (Kinsta, WP Engine, SiteGround, Cloudways) ofrecen staging con un solo clic.

El proceso correcto es:

1. Clonar a staging. Crea una copia exacta de tu sitio en el entorno de staging. Esto incluye la base de datos, los archivos multimedia, los plugins y la configuración.

2. Actualizar en staging. Ejecuta todas las actualizaciones (core de WordPress, plugins, temas) en el entorno de staging. Hazlo de forma ordenada, empezando por el core.

3. Probar flujos críticos. Recorre manualmente los flujos más importantes de tu sitio: formularios de contacto, proceso de compra en WooCommerce, registro de usuarios, buscador interno, páginas de aterrizaje clave. Verifica que todo funciona correctamente.

4. Revisar la consola del navegador. Abre las herramientas de desarrollo del navegador y comprueba que no hay errores de JavaScript. Los conflictos entre plugins suelen manifestarse como errores de JS que afectan a la funcionalidad del frontend.

5. Subir a producción. Solo cuando todo funciona correctamente en staging, aplica los mismos cambios en el entorno de producción. Si tu host ofrece push de staging a producción, utiliza esa funcionalidad.

#Pruebas de regresión visual

Para sitios de negocio críticos, “echar un vistazo rápido” no es suficiente. Las herramientas de regresión visual automatizada comparan capturas de pantalla de tu sitio antes y después de las actualizaciones para detectar roturas sutiles de maquetación que una revisión rápida podría pasar por alto.

Herramientas como Percy o BackstopJS detectan cambios de píxeles en el diseño que serían invisibles para el ojo humano en una revisión superficial. Un botón que se ha desplazado 5 píxeles, un margen que ha cambiado, un color que se ha alterado: estos detalles importan cuando tu sitio genera ingresos.

La regresión visual es especialmente importante después de actualizar temas o page builders como Elementor, Divi o WPBakery, ya que estas herramientas controlan directamente la apariencia visual de cada página.

#Actualizar plugins de uno en uno

Nunca hagas clic en “Actualizar todo”. Actualiza los plugins de uno en uno, comprobando el sitio después de cada actualización. Si un plugin específico rompe el sitio, sabrás exactamente cuál es el culpable y podrás revertirlo.

El orden recomendado es:

1. Primero el core de WordPress. Actualiza WordPress antes que nada, ya que los plugins suelen actualizar su compatibilidad respecto a la última versión del core.

2. Después los plugins críticos. Plugins de caché, seguridad y SEO deben actualizarse a continuación, verificando el funcionamiento después de cada uno.

3. Luego plugins secundarios. Formularios de contacto, sliders, integraciones de redes sociales y similares.

4. Finalmente el tema. Actualizar el tema al final permite verificar que no hay conflictos con los plugins ya actualizados.

Después de cada actualización individual, abre la consola del navegador (F12) y busca errores de JavaScript. Un error de JS puede indicar un conflicto que rompe funcionalidades del frontend sin que sea visualmente obvio en un primer vistazo.

#Copias de seguridad antes de cualquier actualización

Antes de iniciar cualquier proceso de actualización, asegúrate de tener una copia de seguridad completa y verificada. Esto incluye tanto la base de datos como los archivos del servidor. Plugins como UpdraftPlus, BlogVault o Duplicator pueden automatizar este proceso.

La copia de seguridad debe ser restaurable. No basta con tener un backup si nunca has probado que funciona. Programa una restauración de prueba al menos una vez al trimestre para verificar que tus copias de seguridad son realmente funcionales.

#Qué hace WordPress cuando falla la actualización de un plugin

Desde hace algunas versiones, el propio núcleo tiene dos redes de seguridad para las actualizaciones de extensiones. Conviene saber qué cubren y qué no, porque no sustituyen a la copia de seguridad.

WordPress 6.3: restauración tras una actualización manual fallida. Según la nota de desarrollo de 6.3, antes de actualizar un plugin o un tema, WordPress mueve la versión instalada a wp-content/upgrade-temp-backup/plugins/ o wp-content/upgrade-temp-backup/themes/. Si la instalación del paquete falla (paquete vacío, imposibilidad de crear o vaciar la carpeta de destino), la versión anterior vuelve a su sitio. Si la actualización termina bien, la copia se borra. Esta función no detecta un error fatal de PHP que aparezca después de una instalación correcta, y la carpeta no sirve para volver atrás más tarde.

WordPress 6.6: reversión de actualizaciones automáticas de plugins. La guía de campo de 6.6 incluye la reversión automática de las actualizaciones automáticas de plugins al detectar errores fatales de PHP. La propuesta de integración describe el mecanismo: tras actualizar, WordPress hace una petición loopback a la portada; si detecta un error fatal, restaura la versión anterior del plugin y envía un aviso al email de administración. Durante las actualizaciones automáticas el sitio queda en modo mantenimiento, y el plugin revertido se vuelve a intentar en la siguiente comprobación.

La limitación importante es la petición loopback: si el servidor la bloquea (por ejemplo, por una regla de firewall o autenticación HTTP), la propuesta indica que se trata como un error fatal y la actualización se revierte. Un plugin que rompe solo el checkout o una página interna tampoco se detecta, porque la comprobación se hace contra la portada. Por eso las tiendas siguen necesitando pruebas manuales del proceso de compra.

#Qué pasa si no actualizo WordPress

#Escenario 1: sitio hackeado con inyección de SEO spam

Uno de los ataques más comunes contra sitios WordPress desactualizados es la inyección de páginas de SEO spam. Los atacantes crean miles de páginas ocultas dentro de tu sitio que venden productos farmacéuticos, software pirata o servicios de apuestas. Google indexa estas páginas y asocia tu dominio con spam.

El resultado puede ser una acción manual de Google o una caída fuerte del tráfico orgánico. Recuperarse requiere una limpieza técnica completa, enviar una solicitud de reconsideración a Google y esperar semanas o meses a que el buscador vuelva a confiar en tu dominio.

#Escenario 2: fuga de datos de clientes en WooCommerce

Un sitio WooCommerce sin actualizar puede tener vulnerabilidades que permitan acceder a la base de datos de clientes. Nombres, direcciones, emails e incluso datos parciales de pago pueden quedar expuestos. Además de las obligaciones legales bajo el RGPD (con multas de hasta el 4% de la facturación anual mundial), el daño reputacional es difícil de cuantificar.

#Escenario 3: sitio totalmente inoperativo

En el peor de los casos, un atacante puede tomar el control total de tu servidor, eliminando archivos críticos y dejando el sitio completamente fuera de servicio. Sin una copia de seguridad reciente, la reconstrucción puede llevar días o semanas, con la pérdida completa de contenido, configuraciones y datos de clientes.

#Actualizaciones automáticas vs. manuales

WordPress ofrece la posibilidad de configurar actualizaciones automáticas tanto para el core como para plugins y temas. La pregunta es cuándo tiene sentido automatizar y cuándo es mejor mantener el control manual.

#Cuándo activar las actualizaciones automáticas

Las actualizaciones menores de seguridad (por ejemplo, de WordPress 6.5.1 a 6.5.2) son candidatas ideales para la automatización. Estas versiones se centran en parches de seguridad y correcciones de bugs menores, con un riesgo mínimo de romper la compatibilidad.

Para sitios pequeños como blogs personales, portfolios o sitios informativos sin funcionalidad de ecommerce, las actualizaciones automáticas de plugins pueden ser aceptables, siempre que tengas un sistema de backup automático funcionando en paralelo.

#Cuándo actualizar WordPress manualmente

Los sitios de ecommerce con WooCommerce, los sitios con integraciones personalizadas vía API, los sitios con plugins premium que modifican funcionalidades del core y cualquier sitio que genere ingresos directos deben gestionarse con actualizaciones manuales supervisadas.

Las versiones mayores de WordPress (de 6.4 a 6.5, por ejemplo) siempre deben aplicarse de forma manual y en staging primero, ya que pueden incluir cambios significativos en APIs, funciones obsoletas eliminadas o cambios en el comportamiento del editor de bloques.

#Cómo configurar las actualizaciones automáticas de WordPress

La documentación oficial (Upgrading WordPress) explica que las actualizaciones automáticas en segundo plano llegaron con WordPress 3.7 y distingue cuatro tipos: núcleo (de desarrollo, menores y mayores), plugins, temas y archivos de traducción.

Los valores por defecto son estos:

• Las actualizaciones menores del núcleo y las traducciones están activadas por defecto.
• Desde WordPress 5.6, las instalaciones nuevas reciben también las versiones mayores de forma automática, salvo que se detecte un checkout de control de versiones.
• Los plugins y temas solo se actualizan solos en casos especiales que decide la API de WordPress.org, o cuando el administrador lo activa.

Ese interruptor por plugin y por tema llegó con WordPress 5.5, publicado el 11 de agosto de 2020: desde entonces se activan o desactivan las actualizaciones automáticas de cada extensión en las mismas pantallas de Plugins y Temas (anuncio de 5.5).

Para fijar la política en código, wp-config.php admite estas constantes:

// Solo actualizaciones menores del núcleo (de seguridad y mantenimiento)
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

// true: desarrollo, menores y mayores; false: ninguna de las tres
// define( 'WP_AUTO_UPDATE_CORE', true );

// Desactiva todas las actualizaciones automáticas (no recomendado)
// define( 'AUTOMATIC_UPDATER_DISABLED', true );

Para un control más fino existen los filtros auto_update_plugin y auto_update_theme, y para el núcleo allow_major_auto_core_updates y allow_minor_auto_core_updates. Una configuración razonable para una tienda: WP_AUTO_UPDATE_CORE en 'minor', actualizaciones automáticas solo en plugins de bajo riesgo y todo lo que toca pagos o pedidos en manual tras staging. Desactivar todo con AUTOMATIC_UPDATER_DISABLED deja el sitio sin los parches que el equipo de seguridad distribuye precisamente por esa vía.

#Cada cuánto actualizar WordPress

La frecuencia ideal de actualizaciones depende del tipo de sitio y los recursos disponibles:

Parches de seguridad críticos: inmediatamente, dentro de las primeras 24 a 48 horas desde su publicación. Estas son las actualizaciones que cierran vulnerabilidades activamente explotadas.

Actualizaciones menores de WordPress: dentro de la primera semana. Estas versiones suelen ser estables y se centran en correcciones de bugs.

Actualizaciones de plugins: cada dos semanas es una buena cadencia para sitios de tamaño medio. Permite acumular varias actualizaciones y probarlas juntas en staging.

Versiones mayores de WordPress: esperar entre 1 y 2 semanas después del lanzamiento es prudente. Esto permite que la comunidad detecte problemas iniciales y que los desarrolladores de plugins publiquen actualizaciones de compatibilidad.

Actualizaciones de temas premium: verificar la lista de cambios (changelog) antes de actualizar. Los temas con constructores visuales integrados pueden cambiar el comportamiento de componentes existentes.

#Qué versión de PHP usar con WordPress en 2026

La página de requisitos de WordPress recomienda PHP 8.3 o superior, MySQL 8.0 o MariaDB 10.11 o superior, y HTTPS. El mínimo técnico es más bajo: la API de versiones de WordPress.org ofrece WordPress 7.1.3 con un mínimo de PHP 7.4. Que WordPress arranque en PHP 7.4 no significa que ese PHP sea seguro: el calendario oficial de PHP (versiones soportadas y ramas sin soporte) es este:

En octubre de 2026 eso significa que PHP 8.1 ya no recibe parches y que PHP 8.2 los recibe solo hasta final de año. Un sitio que hoy funciona en 8.2 debería planificar ya el salto a 8.3 o 8.4 en staging. El orden práctico es: actualizar WordPress, plugins y tema a versiones que declaren compatibilidad, probar en staging con la nueva versión de PHP y solo después cambiar PHP en producción.

La versión crítica de seguridad de PHP del 21 de octubre de 2026 se explica en la guía de hardening de WordPress, y los pasos para el propietario del sitio están en qué hacer con PHP2Shell en un sitio WordPress.

#Qué han añadido las versiones recientes de WordPress

Quien se queda varias versiones atrás no solo pierde parches. Algunos cambios con fecha y fuente oficial:

• WordPress 6.5 (2024) añadió soporte para imágenes AVIF: se pueden subir, editar, redimensionar y guardar si la librería de imágenes del servidor (Imagick o GD) lo admite, y Site Health indica si está disponible (nota de desarrollo).
• WordPress 6.6 (16 de julio de 2024) incorporó la reversión automática de actualizaciones automáticas de plugins descrita más arriba.
• WordPress 6.8 (2025) activó la carga especulativa en el frontend: el núcleo hace prefetch de las URLs con eagerness conservadora, salvo para usuarios conectados o sitios sin enlaces permanentes bonitos, y el comportamiento se ajusta con el filtro wp_speculation_rules_configuration (nota de desarrollo).
• WordPress 6.9 (diciembre de 2025) introdujo la Abilities API, un registro en el que el núcleo y los plugins declaran qué acciones pueden ejecutar, con esquemas y comprobación de permisos (presentación oficial).

Los plugins modernos empiezan a depender de estas APIs. Un sitio anclado en una versión antigua acaba sin poder actualizar esos plugins, y con ello sin sus parches de seguridad.

#El impacto en SEO de no actualizar

Google ha confirmado que la experiencia de página, incluida la velocidad, forma parte de sus señales de posicionamiento. Las versiones antiguas de WordPress ejecutándose sobre PHP obsoleto son más lentas. Esto afecta a las métricas de Core Web Vitals, especialmente LCP (Largest Contentful Paint) e INP (Interaction to Next Paint).

Además, un sitio hackeado por no estar actualizado puede recibir una marca de “sitio comprometido” en los resultados de búsqueda de Google, lo que hunde el CTR. Los navegadores modernos también muestran advertencias de seguridad cuando detectan malware, lo que ahuyenta a los visitantes antes de que lleguen a interactuar con tu contenido.

Mantener WordPress actualizado es una de las acciones de SEO técnico más sencillas y de mayor impacto que puedes realizar.

#Cómo actualizar varios sitios WordPress a la vez

Si gestionas varios sitios WordPress, actualizar manualmente cada uno es inviable. Existen herramientas que centralizan la gestión de actualizaciones:

ManageWP permite gestionar actualizaciones de decenas o cientos de sitios desde un solo panel, con backups automáticos antes de cada actualización y verificaciones visuales después.

MainWP es una alternativa autoalojada que funciona como plugin en un sitio WordPress central, controlando las actualizaciones de todos tus sitios satélite.

InfiniteWP ofrece funcionalidades similares con un enfoque en agencias que gestionan grandes volúmenes de sitios.

Estas herramientas permiten programar actualizaciones, aplicar actualizaciones selectivas, generar informes para clientes y revertir cambios si algo sale mal.

#Checklist para actualizar WordPress paso a paso

Para asegurar un proceso limpio y repetible, sigue este protocolo cada vez que actualices:

1. Verificar backup reciente. Confirma que tienes una copia de seguridad completa del sitio (base de datos y archivos) que no tenga más de 24 horas.

2. Revisar changelogs. Lee las notas de la versión de WordPress, plugins y temas antes de actualizar. Busca cambios que puedan afectar a funcionalidades críticas de tu sitio.

3. Clonar a staging. Si tu host lo permite, clona el sitio a un entorno de pruebas.

4. Actualizar core primero. Aplica la actualización de WordPress antes que cualquier plugin o tema.

5. Actualizar plugins uno a uno. Verifica el funcionamiento después de cada plugin.

6. Actualizar el tema. Si hay actualización disponible del tema, aplícala al final.

7. Probar flujos críticos. Navega por las páginas principales, prueba formularios, prueba el proceso de compra si aplica.

8. Revisar consola JS. Abre DevTools y comprueba que no hay errores de JavaScript nuevos.

9. Aplicar en producción. Si todo funciona, replica el proceso en el sitio en vivo.

10. Monitorizar 24-48 horas. Vigila los logs del servidor, las estadísticas de tráfico y los reportes de errores durante los dos días siguientes.

#Conclusión

La pregunta “merece la pena actualizar WordPress” no debería existir en 2026. Actualizar es un requisito mínimo de mantenimiento, no una opción. El coste de no actualizar es mucho mayor que el coste de mantener un protocolo de actualizaciones ordenado.

Las actualizaciones protegen contra vulnerabilidades conocidas, mantienen la compatibilidad con versiones de PHP que aún reciben parches, mejoran el rendimiento del sitio, aseguran la compatibilidad con plugins y temas actualizados y contribuyen a un mejor posicionamiento en buscadores.

El riesgo de romper algo durante una actualización existe, pero se reduce mucho con un protocolo adecuado: staging, backups verificados, actualizaciones individuales y pruebas de regresión visual. El riesgo de no actualizar no tiene mitigación posible, solo consecuencias.