Cómo actualizar un WordPress antiguo sin romper la web

Ordenador con WordPress durante un proceso de actualización y mantenimiento técnico

Tu web lleva años funcionando y nadie ha querido tocarla demasiado. Hay actualizaciones pendientes de WordPress, varios plugins muestran avisos, el tema tiene una versión antigua y el hosting recomienda cambiar PHP.

El problema aparece cuando decides poner todo al día: ¿por dónde empiezas sin romper una web que, al menos de momento, sigue funcionando?

Si WordPress lleva años sin actualizarse, no conviene tratarlo como una actualización rutinaria. Antes de pulsar ningún botón hay que averiguar qué tienes, qué componentes siguen siendo compatibles, qué depende de ellos y cómo recuperar la web si algo falla.

La solución no consiste necesariamente en actualizarlo todo de golpe. En instalaciones muy antiguas puede ser necesario preparar una actualización por etapas, sustituir componentes abandonados, cambiar el entorno del servidor o incluso plantearse si merece la pena conservar la instalación actual.

Por qué actualizar un WordPress antiguo puede ser complicado

WordPress no funciona solo.

Una web puede depender de:

  • una determinada versión de PHP;
  • un tema y, en ocasiones, un tema hijo;
  • plugins;
  • un constructor visual;
  • código personalizado;
  • la base de datos;
  • configuraciones específicas del servidor;
  • formularios y servicios de correo;
  • APIs e integraciones externas.

Todos esos elementos evolucionan a ritmos diferentes.

Por eso una web puede seguir aparentemente funcionando después de cinco años sin mantenimiento y, al mismo tiempo, encontrarse en una situación delicada para actualizar.

El problema no es simplemente la cantidad de actualizaciones pendientes. Es la distancia tecnológica acumulada entre los distintos componentes.

Un plugin antiguo puede no funcionar correctamente con una versión moderna de PHP. El tema puede depender de funciones que han cambiado. Una extensión puede haber sido abandonada por su desarrollador. Y puede existir código personalizado que nadie recuerda que está ahí.

Actualizar uno de esos elementos puede dejar al descubierto incompatibilidades que hasta entonces permanecían ocultas.

Eso no significa que sea mejor no actualizar.

Mantener indefinidamente software obsoleto tampoco es una solución. WordPress considera las actualizaciones del núcleo, plugins, temas y PHP parte de la salud de una instalación, tanto desde el punto de vista de seguridad como de mantenimiento.

La cuestión es cómo pasar de una instalación antigua a una mantenible sin utilizar la web pública como banco de pruebas.

Antes de actualizar, averigua qué tienes

El primer paso no debería ser actualizar. Debería ser hacer inventario.

Necesitas conocer, como mínimo:

  • versión actual de WordPress;
  • versión de PHP;
  • tema activo y su versión;
  • existencia de un tema hijo;
  • plugins activos;
  • plugins inactivos;
  • versiones de esos plugins;
  • componentes que ya no reciben actualizaciones;
  • funciones importantes de la web;
  • personalizaciones realizadas;
  • servicios externos conectados;
  • sistema de copias de seguridad;
  • características relevantes del hosting.

Si tu versión de WordPress dispone de Herramientas > Salud del sitio > Información, esa pantalla proporciona una buena parte del inventario técnico: versión de WordPress, tema, plugins, servidor, base de datos, tamaños de directorios y otra información del entorno.

No necesitas comprender cada dato para que resulte útil. Puedes guardarlo como fotografía inicial de la instalación antes de intervenir.

En una web empresarial también conviene saber algo menos técnico: quién controla realmente cada servicio.

¿La empresa tiene acceso al hosting? ¿Al dominio? ¿A WordPress? ¿A las licencias de los plugins? ¿Las cuentas pertenecen a la empresa o al desarrollador que creó la web hace años?

Si no lo tienes claro, conviene resolverlo antes de iniciar una intervención importante. En qué accesos de WordPress debería controlar tu empresa explicamos qué credenciales e infraestructura deberían permanecer bajo control del negocio.

Comprueba si los plugins y el tema siguen teniendo mantenimiento

Que WordPress indique que existe una actualización no resuelve por sí solo la cuestión de la compatibilidad.

Revisa cada componente importante y clasifícalo.

Componentes mantenidos

Son los más sencillos de gestionar. Existe una versión actual, documentación y una trayectoria reciente de actualizaciones.

Aun así, hay que comprobar los requisitos de las versiones a las que quieres llegar.

Componentes abandonados

Aquí aumenta el riesgo.

Puede ocurrir que un plugin continúe funcionando en la instalación antigua pero lleve años sin mantenimiento. Actualizar WordPress o PHP puede provocar que deje de funcionar.

En ese caso, la solución a largo plazo normalmente no consiste en conservar eternamente todo el entorno antiguo para mantener vivo ese plugin. Conviene estudiar qué función realiza y cómo sustituirla.

Componentes desconocidos

Son especialmente frecuentes en webs heredadas.

Quizá existe un plugin cuyo nombre no te dice nada y nadie sabe para qué sirve.

No lo desactives para comprobar qué ocurre directamente en producción.

Primero investiga su función y comprueba si interviene en formularios, maquetación, seguridad, SEO, redirecciones, reservas, áreas privadas o cualquier otro proceso importante.

Lo mismo ocurre con los plugins inactivos: que estén desactivados no significa que debamos borrarlos sin saber por qué siguen instalados.

Una web antigua necesita primero menos incógnitas, no más cambios.

PHP merece una revisión aparte

PHP es el lenguaje sobre el que funciona WordPress y su versión depende del servidor.

Este punto provoca muchos problemas en instalaciones antiguas porque PHP, WordPress, plugins y temas tienen sus propios requisitos de compatibilidad.

A agosto de 2026, WordPress recomienda PHP 8.3 o superior junto con MariaDB 10.11+ o MySQL 8.0+ y HTTPS.

Pero ese dato no significa que debas cambiar inmediatamente una web antigua a PHP 8.3 desde el panel del hosting.

La recomendación actual de WordPress describe el entorno moderno al que interesa llegar. No garantiza que un tema o plugin instalado hace muchos años sea compatible con él.

Si una web antigua utiliza una versión de PHP que ya no recibe soporte, existe una razón importante para modernizarla. Pero el cambio debe formar parte del plan de actualización, no ser un experimento aislado.

Entonces, ¿qué se actualiza primero?

Esta es una de las preguntas más difíciles de responder con una regla universal.

En una web mantenida regularmente, actualizar WordPress, plugins y temas puede ser una operación bastante rutinaria.

Cuando existen varios años de retraso, el orden depende del punto de partida y de las compatibilidades que encuentres.

Por ejemplo, puedes encontrarte con que:

  • WordPress necesita avanzar para soportar correctamente un componente moderno;
  • un plugin necesita actualizarse antes de cambiar PHP;
  • una versión nueva de un plugin ya no es compatible con tu WordPress antiguo;
  • el tema no funciona correctamente con el PHP al que necesitas migrar;
  • una extensión abandonada debe sustituirse antes de continuar.

Por eso no recomendaría una receta del tipo «primero PHP, después plugins y finalmente WordPress» para todas las instalaciones.

Primero se determina el estado inicial y el estado al que queremos llegar. Después se diseña el camino entre ambos.

La documentación oficial de WordPress incluso distingue específicamente las actualizaciones que atraviesan múltiples versiones y remite a un procedimiento ampliado para esos casos.

Si tu instalación no lleva años abandonada y lo que necesitas es simplemente aplicar actualizaciones pendientes con precaución, consulta cómo actualizar WordPress sin romper tu web. Ese artículo aborda el mantenimiento ordinario; aquí estamos tratando una situación diferente.

No empieces sin una copia que puedas recuperar

Antes de modificar WordPress, PHP, plugins o tema necesitas una copia completa.

La propia documentación oficial de WordPress recomienda hacer backup antes de actualizar para poder restaurar la web si aparecen problemas.

Pero en una instalación antigua hay una diferencia importante entre tener un archivo de backup y saber que puedes recuperar la web con él.

Comprueba:

  • qué fecha tiene;
  • si incluye archivos;
  • si incluye la base de datos;
  • dónde está almacenado;
  • si puedes acceder a él;
  • cuánto tiempo se conserva;
  • si existe más de un punto de restauración;
  • si se ha probado alguna restauración.

Además, realiza una copia inmediatamente antes de comenzar la intervención.

En nuestra guía sobre copias de seguridad en WordPress explicamos por qué comprobar la restauración es tan importante como generar el backup.

Esta precaución cobra todavía más importancia si la web recibe formularios, reservas, altas de usuarios u otros datos que pueden cambiar mientras trabajas.

Utiliza un entorno de pruebas siempre que sea posible

Una web que lleva años sin actualizarse es precisamente el tipo de instalación en la que un entorno de staging resulta especialmente útil.

Un staging es una copia de la web utilizada para realizar pruebas sin modificar directamente la versión que ven tus clientes.

Ahí puedes comprobar qué sucede al cambiar PHP, actualizar WordPress, sustituir un plugin o modificar el tema sin convertir cada prueba en una posible caída de la web pública.

La idea es sencilla:

producción continúa funcionando mientras investigas en la copia.

Pero tampoco hay que considerar staging una garantía absoluta.

La copia debe representar adecuadamente la instalación real y, dependiendo de cómo funcione la web, puede haber servicios externos, configuraciones del servidor o datos dinámicos que se comporten de forma diferente.

Por eso staging reduce enormemente el riesgo, pero no elimina la necesidad de comprobar producción después de aplicar los cambios.

Define qué significa que la web «funciona»

Uno de los errores más fáciles de cometer es actualizar, abrir la portada y concluir que todo ha salido bien.

Una web empresarial puede cargar perfectamente y tener roto el formulario por el que llegan los clientes.

Antes de empezar, anota las funciones que no pueden fallar.

Por ejemplo:

  • navegación;
  • formularios;
  • buscador;
  • área privada;
  • descargas;
  • reservas;
  • traducciones;
  • correos automáticos;
  • integración con CRM;
  • analítica;
  • redirecciones importantes;
  • páginas clave para captación.

Después de cada fase relevante, vuelve a probarlas.

Esto convierte una impresión subjetiva —«parece que funciona»— en una comprobación mucho más útil.

No hagas diez cambios a la vez

Cuando una instalación está muy atrasada puede resultar tentador seleccionar todas las actualizaciones pendientes y resolver el problema de una vez.

El inconveniente aparece si algo falla.

Si has cambiado simultáneamente PHP, WordPress, el tema y quince plugins, determinar qué ha provocado el error será mucho más difícil.

Siempre que la ruta de compatibilidad lo permita, es preferible trabajar por fases y comprobar el resultado.

La finalidad no es avanzar despacio por principio. Es conservar la capacidad de diagnosticar y revertir.

Si durante las pruebas WordPress muestra un mensaje de error crítico, no significa necesariamente que hayas perdido la web. Ese mensaje es un síntoma, no un diagnóstico. En qué hacer ante un error crítico en WordPress explicamos qué comprobar antes de empezar a cambiar cosas o restaurar copias indiscriminadamente.

¿Y si después de actualizar algo deja de funcionar?

No continúes instalando actualizaciones con la esperanza de que la siguiente arregle la anterior.

Identifica en qué momento apareció el problema.

Las preguntas útiles son:

¿Qué acababa de cambiar?

¿Afecta a toda la web o a una función concreta?

¿Aparece algún error registrado?

¿Desaparece al volver al estado anterior?

¿Existe una incompatibilidad documentada?

Si estabas trabajando en staging, puedes investigar sin afectar a los visitantes.

Si el problema ha ocurrido en producción y compromete una función importante, tendrás que valorar si conviene revertir el último cambio o restaurar. Antes de restaurar una copia, recuerda que podrías perder información creada desde el momento del backup.

La capacidad de volver atrás debe prepararse antes de actualizar, no después de descubrir el problema.

El hosting puede ayudar, pero no sustituye el diagnóstico

Es posible que necesites al proveedor de alojamiento durante el proceso.

Por ejemplo, para:

  • consultar o cambiar versiones de PHP;
  • revisar configuraciones del servidor;
  • acceder a logs;
  • crear staging;
  • recuperar una copia del servidor;
  • comprobar límites de recursos;
  • resolver problemas de permisos.

Eso no significa necesariamente que el hosting pueda determinar si un plugin concreto es compatible con tu tema o comprobar todas las funciones de negocio después de una actualización.

Tampoco necesitas llamar al registrador del dominio simplemente porque WordPress esté desactualizado.

Dominio, DNS, hosting y mantenimiento de WordPress son servicios relacionados, pero cumplen funciones diferentes. Entender quién controla cada uno evita acabar pidiendo una reparación de WordPress a quien únicamente gestiona el registro del dominio.

¿Cuándo merece la pena actualizar y cuándo es mejor rehacer?

Que una web tenga diez años no significa automáticamente que haya que tirarla y empezar de nuevo.

Una instalación antigua puede conservar contenido valioso, URLs posicionadas, configuraciones útiles y una estructura perfectamente recuperable.

Pero también existen casos donde mantener el sistema actual obliga a conservar demasiadas dependencias obsoletas.

Antes de decidir, conviene valorar:

  • estado del tema;
  • número de componentes abandonados;
  • cantidad de código personalizado;
  • compatibilidad con PHP actual;
  • complejidad de las funciones existentes;
  • estado del contenido;
  • estructura de URLs y SEO;
  • rendimiento;
  • accesibilidad;
  • facilidad futura de mantenimiento;
  • coste y riesgo de actualizar;
  • coste y riesgo de reconstruir.

La decisión correcta no depende exclusivamente de la edad.

Una web de ocho años bien construida puede ser recuperable. Otra bastante más reciente puede depender de un ecosistema tan frágil que resulte razonable replantear parte de ella.

Y «rehacer» tampoco debería significar necesariamente borrar todo. En muchos proyectos se pueden conservar contenido, estructura, URLs, datos o determinadas funcionalidades mientras se sustituye la parte tecnológica que se ha quedado atrás.

Qué no haría con un WordPress que lleva años sin actualizarse

Hay varias acciones que evitaría especialmente:

Actualizar todo directamente en producción. Si aparece un conflicto, tendrás demasiadas variables para identificarlo.

Cambiar PHP a la versión más nueva solo porque el hosting lo recomienda. Primero hay que comprobar las dependencias de la instalación.

Borrar plugins desconocidos. Averigua qué hacen antes de eliminarlos.

Confiar en una única copia sin comprobarla. El momento de descubrir que un backup está incompleto no debería ser después de romper producción.

Mantener indefinidamente versiones antiguas porque «la web funciona». Posponer el problema puede aumentar la distancia que habrá que salvar más adelante.

Dar por buena la actualización porque carga la portada. Hay que probar las funciones que importan al negocio.

El objetivo no es simplemente llegar a la última versión

Actualizar un WordPress abandonado durante años no consiste en conseguir que desaparezcan todos los avisos rojos del escritorio.

El objetivo debería ser dejar detrás una instalación que vuelva a ser mantenible.

Eso significa que:

  • WordPress puede seguir recibiendo actualizaciones;
  • PHP se encuentra en una versión adecuada;
  • los componentes importantes tienen mantenimiento;
  • se han eliminado dependencias que ya no tienen sentido;
  • existen copias recuperables;
  • se conocen los accesos;
  • las funciones importantes se han probado;
  • hay un procedimiento para las siguientes actualizaciones.

Una vez recuperado ese punto, las actualizaciones dejan de ser un proyecto extraordinario y vuelven a convertirse en mantenimiento.

En Mantenimiento WordPress en 2026: qué debería incluir realmente explicamos cómo integrar actualizaciones, copias, monitorización y revisión técnica para no volver a acumular años de retraso.

También conviene establecer una política en lugar de esperar a que las actualizaciones vuelvan a acumularse. En cómo afectan las actualizaciones de WordPress a una web de empresa puedes ver cómo preparar ese proceso de forma recurrente.

Si nadie sabe qué ocurrirá al actualizar, primero hay que diagnosticar

Una web antigua que sigue funcionando puede dar una falsa sensación de seguridad.

No es necesario romperla para descubrir si puede modernizarse.

Antes se puede analizar la instalación, revisar versiones y dependencias, comprobar las copias y reproducir los cambios en un entorno de pruebas.

A veces el resultado será que la web puede actualizarse con relativa facilidad. Otras aparecerán plugins abandonados, incompatibilidades o personalizaciones que necesitan trabajo adicional. Y habrá casos en los que tenga más sentido sustituir parte de la instalación que seguir acumulando soluciones temporales.

Lo importante es que esa decisión se tome antes de empezar a pulsar botones en producción.

Si tu WordPress lleva años sin mantenimiento y no sabes qué puede ocurrir al actualizarlo, en Arreglo tu Web podemos revisar el estado de la instalación, las versiones, plugins, tema, PHP, copias y funciones críticas antes de plantear los cambios.

El objetivo no es actualizar por actualizar.

Es conseguir que la web vuelva a estar en una situación en la que mantenerla deje de dar miedo.

Si necesitas convertir este proceso en una rutina segura, nuestro mantenimiento WordPress para empresas puede ayudarte a mantener actualizaciones, copias y revisiones bajo control.

Autor/a:

Deja el primer comentario

Contenidos relacionados