Cambias la versión de PHP desde el hosting y WordPress deja de funcionar.
Aparece un error crítico, la pantalla se queda en blanco, no puedes entrar en el administrador o alguna parte de la web empieza a fallar. Vuelves a seleccionar la versión anterior de PHP y todo funciona otra vez.
La conclusión parece evidente: «mi WordPress no es compatible con PHP nuevo».
Puede ser, pero todavía no sabes qué parte de la web provoca el problema.
WordPress no funciona solo. El tema, los plugins, un constructor visual, código personalizado y determinadas características del servidor también tienen que ser compatibles con la versión de PHP que estás utilizando.
Si la web funciona con PHP antiguo y falla al actualizarlo, volver temporalmente a la versión anterior puede servir para recuperar el servicio. No resuelve la incompatibilidad que te impide actualizar.
Lo importante es identificar qué componente está bloqueando el cambio y decidir si se puede actualizar, sustituir o reparar.
PHP es el lenguaje sobre el que funciona buena parte de WordPress. Lo ejecuta el servidor, por lo que su versión normalmente se gestiona desde el hosting y no desde el panel de WordPress.
Al cambiar PHP estás modificando el entorno en el que se ejecutan WordPress y todo el código que has añadido a la instalación.
Un sitio puede llevar años funcionando con una determinada combinación:
Que esa combinación funcione hoy no demuestra que todos sus componentes puedan ejecutarse sin cambios sobre una versión más reciente de PHP.
Y al revés: que la web falle al actualizar PHP tampoco demuestra que WordPress en sí sea el responsable.
WordPress mantiene una tabla oficial de compatibilidad entre sus versiones y PHP. En versiones actuales, el núcleo es compatible con distintas ramas modernas de PHP. Pero esa compatibilidad se refiere a WordPress Core, no garantiza automáticamente la compatibilidad de todos los plugins, temas y desarrollos personalizados instalados en una web. Compatibilidad oficial entre WordPress y PHP
Por eso el primer objetivo no debería ser encontrar «la versión de PHP que no rompe la web».
Debería ser localizar qué impide que la instalación funcione en un entorno mantenible.
Es uno de los primeros elementos que conviene investigar, especialmente en webs con años de vida.
Un plugin puede seguir funcionando aparentemente bien sobre el PHP que utilizabas hasta ahora y mostrar un error fatal al ejecutarse sobre una versión posterior.
Esto es especialmente relevante si el plugin:
Pero tampoco conviene empezar desactivando plugins al azar en la web pública.
Si tienes veinte plugins y haces varios cambios simultáneos, puedes acabar con una web diferente y seguir sin saber cuál era el problema original.
Primero necesitas obtener información del error.
Un tema no es únicamente el diseño que ves en pantalla.
Puede contener PHP encargado de plantillas, menús, funcionalidades propias, integraciones o modificaciones realizadas durante el desarrollo de la web.
Además, muchas instalaciones utilizan un tema hijo con código añadido específicamente para ese proyecto.
Por eso cambiar de tema temporalmente puede tener sentido dentro de un diagnóstico controlado, pero no conviene convertirlo en la primera solución ni asumir que debes rediseñar la web porque el nombre del tema aparezca en un error.
Hay que averiguar qué código está fallando y por qué.
Este escenario es habitual en webs heredadas.
Quizá un desarrollador añadió una función hace seis años para modificar WooCommerce, conectar un formulario con otro sistema o resolver una necesidad concreta del negocio.
Ese código puede estar:
Si nadie ha documentado esas personalizaciones, actualizar PHP puede ser el momento en que aparezcan por primera vez.
Por eso una web que «solo tiene plugins actualizados» no está necesariamente libre de código antiguo.
Si la instalación lleva años sin actualizarse, no conviene analizar el cambio de PHP de forma aislada.
Las distintas versiones de WordPress soportan diferentes versiones de PHP. WordPress mantiene esa información en su documentación técnica y las versiones antiguas no tienen el mismo rango de compatibilidad que las actuales. Tabla de compatibilidad de WordPress con PHP
En ese escenario quizá no estás ante «un problema de PHP», sino ante una instalación que ha acumulado demasiada distancia entre:
Si es tu caso, consulta Cómo actualizar un WordPress antiguo sin romper la web, donde explicamos cómo inventariar la instalación y plantear la modernización por fases. Cómo actualizar un WordPress antiguo sin romper la web
No.
Has recuperado la web y, al mismo tiempo, has encontrado una pista muy útil.
Si el único cambio realizado fue pasar de una versión de PHP a otra y al revertirlo desaparece el fallo, existe una relación clara con ese cambio de entorno.
Pero rollback y reparación son cosas diferentes.
Volver temporalmente a la versión anterior puede ser la decisión correcta si la web está caída y necesitas restaurar el servicio antes de investigar.
El problema aparece cuando ese rollback se convierte en la solución permanente.
PHP mantiene cada rama durante un periodo limitado. Cuando una versión llega al final de su ciclo deja de recibir soporte oficial, incluidas correcciones de seguridad. El proyecto PHP publica las ramas que siguen mantenidas y sus fechas de soporte. Versiones de PHP actualmente soportadas
A octubre de 2026:
Por tanto, volver atrás puede darte tiempo para diagnosticar.
No debería utilizarse como estrategia para evitar indefinidamente la incompatibilidad.
Si la web empresarial está en producción y ha dejado de funcionar, la prioridad es recuperar el servicio sin destruir las pistas que permiten encontrar la causa.
Actualizar plugins, cambiar el tema, reinstalar WordPress, borrar cachés, modificar PHP otra vez y restaurar una copia en rápida sucesión puede empeorar mucho el diagnóstico.
Cada cambio introduce una variable nueva.
Si PHP ha sido el único cambio y puedes revertirlo de forma segura, recuperar temporalmente la versión anterior puede ser una forma razonable de devolver la web a su estado inicial mientras preparas las pruebas.
Antes de volver a experimentar necesitas una copia de archivos y base de datos.
Pero tener un archivo llamado backup.zip no es suficiente.
Tienes que saber:
En Copias de seguridad en WordPress: la diferencia entre creer que las tienes y saber que funcionan explicamos por qué la capacidad de restaurar es tan importante como crear copias. Cómo saber si tus copias de seguridad de WordPress funcionan
No continúes con cambios importantes si no sabes cómo regresar al estado anterior.
«La web se rompe» describe el resultado, pero no la causa.
Necesitas saber qué ocurre cuando PHP intenta ejecutar el código.
Dependiendo del caso, puedes encontrar información en:
Si aparece el mensaje «Ha habido un error crítico en esta web», no significa automáticamente que WordPress esté corrupto.
Es una señal de que se ha producido un error que impide completar la ejecución.
En Error crítico en WordPress: qué significa y qué hacer si tu web deja de funcionar explicamos cómo abordar ese síntoma antes de desactivar o reinstalar componentes indiscriminadamente. Qué hacer ante un error crítico en WordPress
Un registro útil puede apuntar hacia:
Encontrar el nombre de un plugin en un error tampoco demuestra automáticamente que sea defectuoso.
Puede ocurrir, por ejemplo, que ese plugin esté llamando a código de otro componente o que el error aparezca como consecuencia de una incompatibilidad anterior.
El registro sirve para reducir el área de investigación.
Después hay que comprobar versiones, documentación y mantenimiento del componente implicado.
Si localizas un plugin o tema que falla, comprueba primero su estado real.
Preguntas útiles:
No sustituiría un plugin únicamente porque aparezca mencionado en un error.
Tampoco actualizaría directamente en producción un componente crítico simplemente para «ver si se arregla».
Cuando sea posible, la investigación debería hacerse en una copia independiente.
El objetivo no es tener un staging por cumplir una lista de buenas prácticas.
Es poder cambiar PHP, actualizar un componente, desactivarlo o reproducir un error sin utilizar la web que atiende a tus clientes como entorno de pruebas.
En una tienda, web de reservas o página que recibe formularios, experimentar directamente en producción puede afectar ventas o contactos aunque la portada siga cargando.
No hay una respuesta útil basada únicamente en elegir el número más alto que aparezca en el hosting.
WordPress recomienda actualmente PHP 8.3 o superior, pero mantiene compatibilidad con distintas versiones según la versión concreta de WordPress. En 2026, el proyecto retiró además la antigua etiqueta de compatibilidad «beta» para las versiones modernas de PHP que ya soporta.
Eso describe la compatibilidad del núcleo.
Tu instalación completa también tiene que ser compatible.
Por eso el objetivo no debería ser:
«¿Cuál es la versión más nueva que puedo seleccionar sin que se rompa?»
Una pregunta mejor sería:
«¿Qué impide que mi web funcione en una versión de PHP actualmente mantenida?»
Una vez identificado y resuelto ese bloqueo podrás decidir la versión de destino teniendo en cuenta WordPress, plugins, tema, hosting y servicios que utilice tu web.
No existe un orden universal que sea seguro para todas las instalaciones antiguas.
Supongamos que tienes:
Cambiar PHP primero puede provocar un error.
Pero seleccionar todas las actualizaciones de WordPress y plugins simultáneamente también puede hacerlo.
La ruta correcta depende de las versiones iniciales y de las dependencias entre componentes.
En una web mantenida de forma regular, el proceso suele ser sencillo.
En una instalación que lleva años sin tocarse puede ser necesario establecer una secuencia de actualización, probar cada fase y sustituir primero algún componente que ya no permite avanzar.
Por eso en Cómo actualizar un WordPress antiguo sin romper la web recomendamos hacer inventario antes de empezar a pulsar botones. Actualizar un WordPress antiguo paso a paso
Depende de qué esté fallando.
El hosting controla el entorno PHP y puede ayudarte a:
Pero si el error está en un plugin abandonado, un tema antiguo o una personalización, cambiar de servidor no reescribe ese código.
Conviene diferenciar ambas responsabilidades.
Si solo tienes acceso al panel de WordPress y no sabes quién controla el alojamiento, antes de intervenir revisa Tengo acceso a WordPress, pero no al hosting: qué hacer. El acceso al servidor puede resultar esencial precisamente para consultar errores, modificar PHP o recuperar una instalación que ya no permite entrar en /wp-admin. Qué hacer si tienes WordPress pero no acceso al hosting
No.
Si el proveedor ya te ha avisado de un cambio próximo, tienes una situación mucho mejor que quien descubre la incompatibilidad después de que la web se caiga.
Puedes probar la nueva versión antes, revisar componentes y preparar una vía de retorno.
En Mi hosting va a cambiar la versión de PHP: cómo evitar que se rompa WordPress tratamos específicamente ese escenario preventivo. Qué comprobar antes de que tu hosting cambie PHP
Si ya has ejecutado el cambio y la web falla, estás en otra fase: necesitas diagnosticar la incompatibilidad.
Una tienda puede cargar perfectamente después del cambio de PHP y tener rota una función que solo aparece al comprar.
Después de cualquier actualización del entorno deberías comprobar al menos:
Esto es especialmente relevante ahora porque WooCommerce ha anunciado que WooCommerce 11.6, previsto para febrero de 2027, elevará el requisito mínimo a PHP 8.1.
Las tiendas que sigan en PHP 7.4 o 8.0 podrán llegar hasta WooCommerce 11.5 según el plan anunciado, pero tendrán que resolver el cambio de PHP para continuar actualizando posteriormente. WooCommerce recomienda actualmente PHP 8.3 o superior en entornos compatibles. Aviso oficial de WooCommerce sobre el requisito PHP 8.1
Si tu tienda solo funciona manteniendo PHP antiguo, por tanto, no estás ante un problema que convenga aplazar indefinidamente.
No necesariamente.
Que una actualización de PHP descubra una incompatibilidad no significa que haya que tirar la web y empezar de cero.
A veces el problema está perfectamente localizado:
En otros proyectos el diagnóstico descubre algo distinto: varios componentes críticos abandonados, personalizaciones sin documentación y una cadena de dependencias que obliga a conservar versiones obsoletas.
Entonces ya no estás decidiendo cómo reparar un error concreto.
Estás decidiendo cuánto sentido tiene seguir invirtiendo en mantener esa arquitectura.
Los componentes importantes continúan mantenidos, la incompatibilidad está localizada y la web sigue cumpliendo las necesidades actuales del negocio.
El resultado de la intervención debería ser una instalación que pueda volver a recibir actualizaciones con normalidad.
Para mantener una función esencial hay que conservar varios componentes abandonados, las personalizaciones antiguas dificultan cada actualización y resolver un bloqueo simplemente deja al descubierto el siguiente.
Tampoco en ese caso la antigüedad por sí sola decide nada.
Una web de muchos años puede ser recuperable.
Otra más reciente puede acumular dependencias que ya no compensa conservar.
Primero se diagnostica. Después se decide.
Conseguir que aparezca la portada sin errores es una comprobación demasiado pobre para una web empresarial.
Después del cambio debes probar las funciones que realmente importan.
Por ejemplo:
También conviene revisar los registros por si el cambio ha producido errores que todavía no son visibles para los usuarios.
Una actualización puede estar técnicamente activa y seguir habiendo dejado dañada una función importante.
Si tu WordPress solo funciona cuando vuelves a una versión antigua de PHP, has descubierto una dependencia que necesita atención.
No hace falta empezar rehaciendo la web.
Tampoco tiene sentido mantener indefinidamente el entorno antiguo únicamente porque «de momento funciona».
La secuencia correcta es otra: identificar el error, localizar el componente responsable, comprobar si puede actualizarse o sustituirse, probar la solución fuera de producción y verificar después las funciones importantes de la web.
A veces será una incompatibilidad concreta y sencilla de resolver.
En otras instalaciones, el cambio de PHP sacará a la luz años de mantenimiento pendiente y habrá que planificar una actualización por fases.
Y habrá casos en los que el diagnóstico muestre que conservar determinadas dependencias ya no tiene sentido.
La decisión entre reparar, actualizar o rehacer debería llegar después de saber qué está fallando, no antes.
Si tu WordPress funciona con una versión antigua de PHP pero se cae en cuanto intentas actualizarla, en Arreglo tu Web podemos revisar la instalación, localizar qué componente está bloqueando el cambio y plantear una ruta de actualización sin utilizar la web pública como banco de pruebas.
El objetivo no es cambiar un número en el panel del hosting.
Es que la web vuelva a estar en una situación en la que puedas mantenerla sin depender de software obsoleto.
