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. Quizá, además, la persona o empresa que creó la web hace tiempo que dejó de ocuparse de ella.
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, de qué depende la web y cómo recuperarla si algo falla.
Una web antigua puede parecer estable precisamente porque nadie ha cambiado nada. Eso no significa que esté preparada para recibir cinco años de actualizaciones de golpe.
WordPress facilita mucho las actualizaciones.
Entras en Escritorio → Actualizaciones, aparecen varias pendientes y parece lógico resolver el problema desde ahí.
En una instalación mantenida regularmente, ese proceso suele ser razonable. En una web que lleva años sin tocarse, puede ser justo lo que no conviene hacer.
Entre la versión actual de la web y la que quieres alcanzar pueden haber cambiado:
Actualizar todo a la vez introduce otro problema: si algo falla, no sabrás qué cambio lo ha provocado.
Y volver atrás puede resultar bastante más complicado que pulsar el botón que inició la actualización.
Antes de actualizar hay que hacer inventario.
No hace falta elaborar un informe de treinta páginas. Sí conviene saber, al menos:
Este último punto se pasa por alto con frecuencia.
Puedes tener acceso como administrador de WordPress y, aun así, no controlar realmente la instalación. Cambiar PHP, recuperar archivos, acceder a determinadas copias o intervenir si WordPress deja de arrancar suele exigir acceso al alojamiento.
Si estás precisamente en esa situación, conviene resolver primero la diferencia entre tener acceso al panel y controlar realmente la infraestructura de la web. Tengo acceso a WordPress, pero no al hosting: qué hacer
Esto ocurre mucho en webs empresariales.
Un proveedor creó la primera versión. Años después intervino otro diseñador. Alguien instaló un plugin para solucionar un problema puntual. Otro desarrollador añadió unas líneas de PHP. Más tarde se cambió el hosting.
Al final tienes una web que funciona, pero nadie puede explicar con seguridad para qué sirve cada pieza.
Un plugin aparentemente prescindible puede estar modificando un formulario.
Un fragmento dentro de functions.php puede controlar una parte del proceso de compra.
Un tema hijo puede contener cambios importantes realizados hace seis años.
Una extensión desactivada puede ser simplemente basura… o algo que se desconectó temporalmente durante una incidencia.
Por eso limpiar antes de entender es tan arriesgado como actualizar antes de probar.
Antes de modificar una web antigua necesitas una vía de vuelta.
No basta con que el hosting muestre el mensaje «copias automáticas activadas».
Tampoco basta con encontrar un plugin de backups instalado.
Una copia útil debería permitir recuperar tanto los archivos como la base de datos y, sobre todo, deberías saber cómo restaurarla si WordPress deja de funcionar.
Hay una diferencia importante entre tener backups y haber comprobado que puedes restaurarlos. Lo explicamos con más detalle en nuestra guía sobre copias de seguridad de WordPress. Copias de seguridad WordPress: cómo saber si funcionan
En una web antigua, además, conservaría una copia completa del estado inicial antes de empezar.
No porque esa versión sea buena, sino porque es tu punto de retorno conocido.
Si la web genera contactos, reservas, pedidos o ventas, utilizar producción como banco de pruebas tiene poco sentido.
Lo adecuado es reproducir la instalación en un entorno de staging o pruebas y realizar allí los cambios importantes.
Eso permite descubrir, por ejemplo:
Lo importante del staging no es simplemente comprobar que aparece la portada.
Hay que probar las funciones que hacen útil la web.
Una web puede cargar correctamente y estar rota.
Por eso, antes de actualizar, anotaría qué debe seguir funcionando después.
Por ejemplo:
La prueba posterior debe partir de esa lista.
Que WordPress no muestre un error crítico solo demuestra que WordPress arranca.
Aquí suelen aparecer muchas de las decisiones difíciles.
Una web antigua puede contener plugins que:
No trataría todos igual.
Es el escenario más sencillo. Se puede preparar su actualización y comprobarla en pruebas.
Conviene estudiar su eliminación.
Pero primero hay que comprobar qué función proporcionaba y si ha dejado datos, shortcodes o elementos visibles en la web.
Aquí el problema ya no consiste en «actualizar WordPress».
Hay que buscar cómo sustituir esa funcionalidad.
Por ejemplo, un sistema antiguo de formularios puede necesitar migrarse a otra solución antes de poder modernizar el resto de la instalación.
No asumiría que es incompatible ni que es seguro simplemente porque sigue funcionando.
Hay que revisar qué hace, cómo está construido y de qué APIs o versiones de PHP depende.
Un tema antiguo merece una revisión específica.
Especialmente si fue comprado hace muchos años, contiene personalizaciones directas o depende de un constructor que ya no recibe mantenimiento.
Hay tres situaciones muy distintas.
Puede que baste con preparar correctamente la actualización y revisar posibles cambios visuales.
Actualizar WordPress puede exponer incompatibilidades.
Aquí habrá que valorar si merece la pena adaptar el tema o si ha llegado el momento de sustituirlo.
Actualizarlo podría sobrescribir modificaciones.
Por eso conviene comprobar si existe un tema hijo y dónde están realmente las personalizaciones antes de instalar una versión nueva.
Este tipo de dependencias son una de las razones por las que actualizar una web con muchos años no equivale a actualizar una instalación mantenida regularmente.
PHP es el lenguaje sobre el que funciona WordPress y su versión depende del servidor.
Actualmente WordPress recomienda PHP 8.3 o superior, junto con MariaDB 10.11+ o MySQL 8.0+ y HTTPS. Las versiones antiguas pueden seguir funcionando en determinados casos, pero algunas ya están fuera de su ciclo oficial de soporte.
Eso no significa que debas ver PHP antiguo en el hosting y cambiar inmediatamente a PHP 8.3.
El objetivo es llegar a un entorno moderno y mantenido. La ruta hasta allí depende de la web.
Un tema o plugin construido hace años puede contener código incompatible con una versión moderna de PHP.
Por eso el salto debe probarse junto al resto de componentes.
Si tu proveedor ya te ha avisado de que va a retirar una versión de PHP, tenemos una guía específica sobre qué comprobar antes de que se produzca ese cambio. Mi hosting cambia PHP: cómo evitar errores en WordPress
No existe una secuencia universal válida para cualquier WordPress abandonado durante años.
Y desconfío de las instrucciones del tipo:
«Actualiza primero A, después B y finalmente C».
En una instalación sencilla podría funcionar.
En otra podría dejarla inaccesible.
El orden depende de las compatibilidades encontradas durante el diagnóstico.
Por ejemplo, puedes encontrarte con que una versión reciente de un plugin exige un WordPress más nuevo, mientras que ese WordPress necesita una versión de PHP con la que otro plugin antiguo no funciona.
En ese caso no tienes una cola de actualizaciones.
Tienes un problema de dependencias.
El trabajo consiste en encontrar una ruta viable entre el estado actual y un entorno mantenible.
Cuando ya sabes qué componentes pueden actualizarse, conviene evitar otro error habitual: cambiar diez cosas y comprobar la web una sola vez al final.
Es preferible trabajar por fases.
Por ejemplo:
Así, cuando algo deja de funcionar, el número de posibles responsables es mucho menor.
Para instalaciones que reciben mantenimiento normal, nuestra guía sobre cómo actualizar WordPress de forma segura explica este procedimiento con mayor detalle. Cómo actualizar WordPress sin romper tu web
Después de actualizar hay fallos muy evidentes:
Son casi los más fáciles de detectar.
Más delicados son los errores silenciosos:
Por eso una revisión posterior debería incluir tanto el frontal como el funcionamiento interno.
Si después de una actualización aparece el mensaje de error crítico, tampoco significa automáticamente que WordPress esté perdido: es necesario identificar qué componente está originando el fallo. Error crítico en WordPress: qué significa y cómo diagnosticarlo
Poner al día una web antigua no debería limitarse a conseguir que desaparezcan los números rojos de «actualizaciones pendientes».
También es una oportunidad para preguntarse si todo lo instalado sigue teniendo sentido.
Puede haber:
No eliminaría todo indiscriminadamente.
Pero una vez estabilizada la actualización sí merece la pena dejar una instalación más comprensible y mantenible que la que encontraste.
En webs con muchos años, también puede ser útil revisar posteriormente qué ha ido acumulando la base de datos y qué puede limpiarse con seguridad. Cómo limpiar la base de datos de WordPress sin tocar código
Esta posibilidad suele omitirse en las guías sobre actualizaciones.
Hay webs donde técnicamente es posible conservarlo casi todo, pero económicamente no merece la pena.
Imagina una instalación que depende de:
Podrías dedicar muchas horas a mantener vivo ese conjunto.
Pero quizá sea más razonable conservar contenidos y funciones necesarias y reconstruir sobre una base moderna.
La decisión no debería tomarse por la edad de la web.
Debería depender de tres cosas:
cuánto cuesta actualizarla, qué riesgo seguirá existiendo después y qué vida útil tendrá el resultado.
Una web de ocho años puede modernizarse perfectamente.
Otra de cuatro puede arrastrar una arquitectura que hace más sensato rehacer buena parte de ella.
Que una web siga cargando no significa que sea buena idea dejarla indefinidamente congelada.
WordPress, PHP, navegadores, servicios externos, APIs y plugins siguen evolucionando aunque tú no cambies ningún contenido.
El problema suele hacerse visible precisamente cuando alguien necesita intervenir:
el hosting retira una versión de PHP, aparece una vulnerabilidad, falla un formulario o necesitas añadir una función y descubres que el entorno ya no admite software actual.
Mantener WordPress no consiste en estar cambiándolo continuamente.
Consiste en evitar que la distancia entre tu instalación y el ecosistema actual llegue a ser tan grande que cualquier cambio se convierta en un proyecto.
Ese es el verdadero problema de una web que lleva años sin actualizarse.
Si mañana tuviera que hacerme cargo de un WordPress que nadie actualiza desde hace años, el orden mental sería este:
Solo después plantearía limpieza, rendimiento y mejoras adicionales.
El objetivo no es conseguir que WordPress diga «todo está actualizado».
Es dejar una web que puedas volver a actualizar dentro de unas semanas sin tener que repetir una operación de rescate.
