Como degradar WordPress? (Plugin, FTP, WP-CLI)

Haces clic en “Actualizar”, esperas un momento, y de repente ves la “Pantalla Blanca de la Muerte” o un error crítico de PHP. Tu sitio está caído, y el clientes está llamando.

No entres en pánico. En WordPress, casi siempre puedes revertir los cambios. En esta guía, te mostraré tres métodos para hacer un Downgrade, desde el más fácil hasta el más avanzado.

Antes de eso, un paso que casi todo el mundo se salta con las prisas: averiguar qué se rompió de verdad. Revertir a ciegas suele empeorar las cosas.

#Cómo saber qué actualización rompió WordPress

La tentación es revertir la última cosa que tocaste y rezar. En la práctica, cinco minutos de diagnóstico te ahorran una hora de reversiones a ciegas. El objetivo es aislar la causa: el núcleo, un plugin, el tema o un cambio de versión de PHP en el servidor.

Activa los registros de depuración. Edita wp-config.php (por FTP o por el gestor de archivos de tu hosting) y, justo encima de la línea /* That's all, stop editing! */, añade:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Con esto, WordPress escribe cada aviso y error fatal en wp-content/debug.log sin mostrarlos a los visitantes. Descarga ese archivo y busca la última línea Fatal error: normalmente incluye la ruta del archivo que provocó el fallo, y esa ruta te dice si el culpable está en wp-content/plugins/, en wp-content/themes/ o en el núcleo (wp-admin/ o wp-includes/).

Cruza el dato con los logs del servidor. El debug.log de WordPress no lo ve todo. En el panel de tu hosting (la mayoría de proveedores españoles lo exponen en un clic) busca el registro de errores de PHP o el error_log de Apache o nginx. Un error 500 sin rastro en debug.log casi siempre es memoria de PHP agotada o una incompatibilidad de versión de PHP, no un plugin.

Aísla al culpable desactivando plugins. Si aún entras al panel, desactiva todos los plugins y comprueba si el sitio revive. Reactívalos de uno en uno hasta que vuelva el fallo: el último que actives es el sospechoso. Si no entras al panel, renombra por FTP la carpeta wp-content/plugins a plugins-off; WordPress los desactivará todos de golpe. Para descartar el tema, activa temporalmente un tema por defecto como Twenty Twenty-Four.

Solo cuando sepas si fue el núcleo, un plugin, el tema o PHP tiene sentido elegir método de reversión. La tabla de más abajo cruza justamente esas dos variables: qué se rompió y qué acceso tienes.

#Método 1: revertir un plugin con WP Rollback

Si aun tienes acceso al Dashboard (wp-admin), estás salvado. La mejor herramienta para revertir plugins y temas es el plugin gratuito WP Rollback.

1. Instala y activa WP Rollback.
2. Ve a Plugins > Plugins instalados.
3. Un nuevo enlace “Rollback” aparecerá junto a cada plugin.
4. Haz clic y elige la versión a la que quiere volver (ej. de 5.4 a 5.3).
5. Confirma. Listo!

Nota: La versión gratuita de WP Rollback trabaja, según su página en WordPress.org, con plugins y temas de WordPress.org; los plugins premium requieren la versión de pago Pro. No revierte el núcleo. Para el núcleo existe un plugin aparte, Core Rollback, de Andy Fragen, que aparece en Herramientas.

#Método 2: degradar WordPress con WP-CLI

Si tienes acceso SSH (consulta nuestra guía de SSH), este es el método más rápido y seguro.

Para degradar WordPress Core:

wp core update --version=7.0.7 --force

El parámetro --force fuerza la instalación incluso si tienes una versión más nueva, según la documentación de WP-CLI. Escribe la opción tal cual, --version: WP-CLI no reconoce nombres de opciones traducidos.

Para degradar un plugin (ej. WooCommerce):

wp plugin install woocommerce --version=8.5.0 --force

Para degradar un tema:

wp theme install nombre-tema --version=2.1.0 --force

Aquí --force pertenece a wp plugin install y wp theme install: según la documentación, sobrescribe cualquier versión instalada sin pedir confirmación. wp plugin update no tiene esa opción, aunque también acepta --version.

#A qué versión de WordPress hacer rollback

No toda versión antigua es un destino seguro. WordPress.org publica el estado de seguridad de cada versión del núcleo en la API stable-check, y el plugin Core Rollback usa la misma lista: según su descripción, solo ofrece la última versión y versiones antiguas pero seguras. El 14 de octubre de 2026 la API marca 7.1.3 como latest, la última versión de mantenimiento de cada rama anterior (7.0.7, 6.9.10, 6.8.11, etc.) como outdated y todas las versiones de mantenimiento previas de esas ramas como insecure. La 6.4.3 que esta guía usaba como ejemplo hasta esta actualización está en la lista de inseguras.

La regla, por tanto: vuelve a la última versión de mantenimiento de la rama que funcionaba, no al número exacto que tenías antes. Si la 7.1.x rompió el sitio, el destino es 7.0.7, no 7.0.2. Comprueba el estado antes de lanzar el comando:

curl -s https://api.wordpress.org/core/stable-check/1.0/ | grep '"7.0.7"'

La segunda comprobación es PHP. La tabla de compatibilidad del equipo del núcleo indica con qué versiones de PHP se probó cada versión, y un rollback puede sacarte de ella:

Si el hosting ya pasó el servidor a PHP 8.5, un rollback a 6.8 cae en una combinación que el equipo del núcleo nunca listó como soportada. El límite también funciona al revés: WordPress 7.0 dejó de dar soporte a PHP 7.2 y 7.3, así que en un servidor así la versión más reciente que puede ejecutar es la 6.9. Elige el destino que pase las dos comprobaciones: seguro según stable-check y listado para la versión de PHP de tu servidor. wp eval 'echo PHP_VERSION;' muestra la versión que WordPress ve realmente.

#Cómo comprobar que la degradación funcionó

Después de ejecutar el comando, verifica que todo funciona:

## Verificar la versión instalada
wp core version
wp plugin get woocommerce --field=version

## Verificar integridad de archivos
wp core verify-checksums

## Verificar si hay errores en la base de datos
wp db check

#Método 3: instalar una versión anterior de WordPress por FTP

Si no tienes acceso al panel ni a SSH, solo queda la “cirugía a corazón abierto” vía FTP.

Esto es riesgoso. Haz backup de tu base de datos antes de empezar!

1. Ve a WordPress.org Releases y descarga la versión antigua de WP (zip). Si tienes WP-CLI en tu ordenador, wp core download --version=7.0.7 --skip-content --path=wp-7.0.7 descarga esa misma versión sin los temas y plugins por defecto (documentación).
2. Descomprime en tu computadora.
3. ELIMINA la carpeta wp-content y el archivo wp-config-sample.php de la carpeta descomprimida.
   • ¿Por qué? Para no sobrescribir accidentalmente tus fotos, temas y configuración!
4. Conecta vía FTP (FileZilla).
5. Sube los archivos restantes (wp-admin, wp-includes, archivos raíz) al servidor, eligiendo “Sobrescribir”.

Después de subir, intenta acceder a wp-admin. Si WordPress muestra Es necesaria una actualización de la base de datos, confirma con Actualizar la base de datos de WordPress.

#Cómo restaurar WordPress desde una copia del hosting

Antes de operar a corazón abierto por FTP, mira si tu hosting ya tiene la solución hecha. Casi todo el alojamiento gestionado guarda puntos de restauración diarios y ofrece una restauración con un clic que devuelve archivos y base de datos al estado de ayer, sin que toques una sola línea.

En el mercado español lo tienes de serie: SiteGround incluye copias diarias y restauración selectiva en su panel; Webempresa y Raiola Networks generan backups automáticos que restauras desde el área de cliente o pidiendo al soporte que revierta a un punto concreto; los hostings con cPanel suelen traer JetBackup, donde eliges la fecha y restauras solo la base de datos, solo los archivos o ambos.

La ventaja frente al FTP manual es doble: recuperas también la base de datos (imprescindible cuando una actualización migró el esquema, como veremos ahora) y evitas sobrescribir archivos equivocados. La pega es la granularidad: un punto de restauración devuelve el sitio entero a esa fecha, así que perderás los pedidos o entradas creados después. Antes de restaurar, exporta la base de datos actual por si necesitas recuperar algo a mano.

Regla práctica: si el fallo llegó con una actualización de hace minutos y aún no ha entrado tráfico nuevo, la restauración del hosting es el camino más limpio. Si el sitio recibe pedidos cada pocos minutos, calcula qué pierdes antes de revertir el conjunto.

#Cómo revertir una actualización de WordPress según tu acceso

No hay un método universal. La elección depende de dos cosas: a qué tienes acceso y qué componente falló. Esta tabla resuelve la mayoría de casos:

La última fila es la trampa: cuando la actualización tocó la base de datos, ningún método que solo mueva archivos sirve. Lo vemos en detalle a continuación.

#Por qué no basta revertir un plugin que migró la base de datos

Conoce más sobre los servicios de seguridad WordPress en WPPoland.

A veces degradar archivos no es suficiente, y este es el error que más sitios de tienda tumba. La razón es que muchos plugins no solo cambian su código al actualizar: ejecutan una migración de la base de datos. Añaden columnas, crean tablas propias o mueven datos de un formato a otro. Cuando eso ocurre, el código y el esquema quedan atados a la nueva versión.

El caso de manual es WooCommerce con HPOS (High-Performance Order Storage, el almacenamiento de pedidos en tablas propias wp_wc_orders en lugar de en wp_posts). Al actualizar, WooCommerce puede migrar todos los pedidos al nuevo esquema. Si después reviertes los archivos a la versión anterior pero dejas la base de datos ya migrada, el código antiguo busca los pedidos donde ya no están: la tienda muestra pedidos vacíos, errores fatales o un panel de administración inaccesible. Lo mismo pasa con plugins de membresía, LMS o reservas que mantienen sus propias tablas y las versionan.

Por eso revertir código contra un esquema ya migrado no es una reversión: es dejar el sitio a medio camino entre dos versiones incompatibles. La única solución limpia es restaurar una copia completa (archivos y base de datos juntos) del momento anterior a la actualización, de modo que código y esquema vuelvan a coincidir. Un backup solo de archivos no vale aquí.

#Cómo evitar errores al actualizar plugins

1. Staging: Nunca actualices “en vivo”. Clona el sitio en una copia de pruebas, aplica la actualización allí y comprueba el checkout, los formularios y las páginas clave antes de tocar producción.
2. WP_DEBUG en staging: Deja WP_DEBUG y WP_DEBUG_LOG activados en el entorno de pruebas para cazar avisos y errores fatales antes de que lleguen a los clientes.
3. Actualiza en lotes pequeños: Un plugin cada vez, no veinte de golpe. Si algo falla, sabes exactamente qué fue sin tener que aislar entre decenas de cambios.
4. Lee los changelogs: Antes de actualizar, revisa las notas de la versión. Un aviso de “database migration” o “breaking change” es la señal para hacer copia completa y probar en staging sin excepción.
5. Backups automáticos con restauración probada: Configura copias del hosting cada 24 horas, pero además prueba una restauración de vez en cuando. Un backup que nunca ha restaurado no es un backup, es una suposición.

Recuerda: Las actualizaciones son importantes para la seguridad, pero la estabilidad es más importante para el negocio.

#Cómo bajar la versión de PHP en el hosting

No todo rollback es de WordPress. A veces el sitio se rompe porque el hosting subió la versión de PHP (de 8.1 a 8.3, por ejemplo) y un plugin o tema antiguo no es compatible con la nueva. El síntoma típico es un error fatal que aparece sin que hayas actualizado nada del propio WordPress.

En ese caso no hay que degradar WordPress, sino la versión de PHP. Casi todos los hostings españoles ofrecen un selector de PHP en el panel (cPanel lo llama “MultiPHP Manager”; Plesk, “Ajustes de PHP”). Baja a la versión con la que el sitio funcionaba, confirma que el error desaparece y aprovecha para actualizar el plugin o tema incompatible a una versión que sí soporte el PHP nuevo.

Trata el downgrade de PHP como algo temporal: las versiones antiguas dejan de recibir parches de seguridad. Es un puente mientras actualizas el componente incompatible, no un estado en el que quedarse.

#Cómo actualizar WordPress de forma segura

Para evitar necesitar degradaciónes en el futuro, sigue esta estrategia:

1. Antes de actualizar: Crea un backup completo y documenta las versiones actuales de todos los plugins.
2. Entorno de staging: Clona tu sitio de producción y aplica las actualizaciones allí primero.
3. Actualizaciones graduales: Actualiza un plugin a la vez, no todos simultáneamente.
4. Monitoreo post-actualización: Verifica funcionalidad crítica después de cada actualización.
5. Plan de rollback: Ten documentado el proceso de reversión antes de empezar.

#Script WP-CLI para comprobar antes de actualizar

## Script de verificación pre-actualización
#!/bin/bash
echo "=== Verificacion pre-actualización ==="

## Backup de base de datos
wp db export backup-pre-update-$(date +%Y%m%d).sql
echo "Backup de BD creado"

## Listar versiones actuales
echo "=== Versiones actuales ==="
wp core version
wp plugin list --fields=name,version,update_version
wp theme list --fields=name,version,update_version

## Verificar integridad
wp core verify-checksums
echo "=== Verificacion completa ==="

#Resumen

La prevención siempre es mejor que la curación. Invierte en un flujo de trabajo de staging y backups automatizados para que las degradaciónes sean la excepción, no la regla.

Conoce más sobre los servicios de mantenimiento WordPress y el desarrollo WordPress en WPPoland.

#Fijar versiones de WordPress con Composer y WP-CLI

En infraestructuras empresariales, ejecutar un downgrade manual vía FTP o panel de control es una mala práctica inaceptable:

• Ejecución con WP-CLI: El comando wp core update --version=7.0.7 --force fuerza la descarga e instalación de los archivos del núcleo de una versión anterior en segundos. Inmediatamente después, wp core update-db --dry-run compara las versiones de la base de datos sin modificar nada.
• Bloqueo determinista de versiones con Composer: Administrar el núcleo y las extensiones a través de un archivo composer.lock garantiza que cualquier reversión sea estrictamente reproducible en todos los entornos (local, staging y producción). Al revertir el commit en Git y desplegar mediante pipelines automatizados, se elimina cualquier discrepancia entre servidores.
• Incompatibilidades del esquema de base de datos MySQL: Cuando una actualización mayor de WordPress ya migró el esquema (el valor de wp option get db_version es más alto que el que espera el código revertido), la simple sustitución de archivos PHP puede provocar errores fatales. La restauración obligatoria del snapshot de la base de datos anterior a la actualización es la única garantía de integridad relacional.

#Qué hacer después de un rollback de WordPress

Una vez completada la vuelta atrás en producción para restaurar la facturación del negocio:

• Reproducción del error en un subdominio aislado: Clona el entorno averiado a un servidor de staging para diagnosticar la causa raíz mediante WP_DEBUG y herramientas de registro como Sentry o New Relic sin afectar a los usuarios activos.
• Desactivación selectiva de autoactualizaciones automáticas: Configura define( 'WP_AUTO_UPDATE_CORE', 'minor' ); en wp-config.php para que el sistema no vuelva a aplicar la versión mayor inestable durante la noche y siga instalando las versiones de seguridad. Para un plugin concreto, wp plugin auto-updates disable woocommerce.
• Resumen: Revertir versiones no es una solución definitiva, sino una medida de contención de emergencia para proteger los ingresos comerciales mientras el equipo de ingeniería resuelve las incompatibilidades técnicas subyacentes con rigor.

#Cómo restaurar WordPress caído tras una actualización

Ante una caída crítica de la web de producción tras una actualización defectuosa:

1. Poner el sitio en modo de mantenimiento inmediato: Evita que los clientes vean páginas en blanco o mensajes de error fatal de PHP ejecutando wp maintenance-mode activate.
2. Restaurar los archivos del núcleo a la versión previa estable: Descarga los binarios oficiales correspondientes a la versión anterior de WordPress e instálalos sobreescribiendo el directorio wp-admin y wp-includes.
3. Revertir la copia de seguridad de la base de datos: Importa el volcado SQL previo a la incidencia mediante wp db import backup-previo.sql. Esta acción es obligatoria si la actualización modificó tablas relacionales o esquemas de plugins críticos como WooCommerce.
4. Purgar todas las capas de caché: Vacía el almacenamiento de Redis (wp cache flush) y purga completamente la red de distribución de contenidos (Cloudflare CDN) para garantizar que los navegadores reciban el código restablecido.
5. Verificación técnica final: Comprueba el correcto funcionamiento de los formularios de contacto, el proceso de compra y las rutas de inicio de sesión de usuarios antes de desactivar el modo de mantenimiento y dar por concluida la incidencia.

#Cómo evitar otro downgrade de WordPress

Para evitar la necesidad de volver a ejecutar procesos de downgrade en el futuro:

• Implementa un calendario estructurado de mantenimiento: No apliques actualizaciones de versiones mayores el mismo día de su lanzamiento; permite un margen de varias semanas para que la comunidad identifique y resuelva posibles fallos imprevistos.
• Automatiza pruebas de regresión visual: Utiliza herramientas como Playwright o BackstopJS en tu entorno de staging para verificar automáticamente que ningún botón, tipografía o maquetación se rompa tras la actualización.
• Conclusión: La prevención metódica y el rigor en los procedimientos de despliegue son la mejor salvaguarda para la continuidad operativa de cualquier infraestructura web corporativa. La seguridad técnica y la preparación operativa son la clave del éxito comercial.