La versión de PHP de tu web es el lenguaje en el que están escritos el núcleo de WordPress, el tema y cada plugin instalado, y casi ningún despacho la ha mirado nunca. Se nota cuando algo falla: una actualización que rompe el formulario de contacto, una carga más lenta de lo habitual, un plugin que deja de funcionar de un día para otro. En 2026 el descuido tiene fecha concreta: dos versiones muy extendidas dejan de recibir soporte este mismo año, y seguir en ellas no es solo un riesgo de seguridad, también de compatibilidad.
PHP es el lenguaje de programación que ejecuta WordPress en el servidor: procesa cada página antes de enviarla al navegador. Cuando una versión de PHP se queda sin soporte, deja de recibir parches de seguridad y de rendimiento, aunque la web siga funcionando con normalidad aparente.
Qué versión de PHP sostiene tu web ahora mismo
WordPress técnicamente arranca con PHP 7.4, pero esa versión perdió el soporte de seguridad en noviembre de 2022 y seguir con ella es correr sin red. La documentación oficial de WordPress recomienda PHP 8.3 o superior para obtener el mejor rendimiento y la mejor seguridad, no la versión mínima compatible.
La diferencia no es cosmética. Entre una versión antigua y una reciente hay mejoras de velocidad medibles en cada carga de página: menos tiempo de procesamiento en el servidor antes de que el navegador reciba una sola línea de HTML. Eso pesa en la velocidad general de la web y, con ella, en cómo evalúa Google la experiencia de quien la visita.
La mayoría de despachos no eligió esta versión de forma consciente. La trae el hosting por defecto en el momento de contratarlo y ahí se queda, actualización tras actualización de WordPress, hasta que un plugin nuevo exige una versión más reciente para instalarse y todo se revisa de golpe, con prisa y sin margen para probarlo con calma. Preguntarlo antes evita ese aprieto: cualquier panel con cPanel o Plesk permite consultar y cambiar la versión de PHP en un par de clics, sin tocar código ni depender de un desarrollador para algo tan básico.
PHP 8.2 pierde el soporte de seguridad en 2026
Según la tabla oficial de versiones soportadas de PHP, la 8.2 entra en su último tramo de vida durante este 2026: a partir de ahí solo recibe parches ante fallos de seguridad graves, ni uno más para el resto de errores.
Qué diferencia hay entre soporte activo y solo seguridad
PHP reparte la vida de cada versión en dos fases de dos años cada una. Durante el soporte activo se corrigen tanto errores normales como fallos de seguridad, con publicaciones periódicas. Pasado ese plazo entra en soporte de solo seguridad: dos años más, pero solo para vulnerabilidades críticas, sin mejoras ni correcciones menores. La 8.2 sale de esa segunda fase el 31 de diciembre de 2026; la 8.3, un año después; la 8.4, en 2028. Pasada la fecha límite, cualquier fallo que se descubra en esa versión queda sin parchear para siempre, y el servidor sigue ejecutándolo igual que el día anterior, sin ningún aviso visible en la web.
Versiones desactualizadas todavía muy usadas
No es un caso aislado. Un análisis de más de 6.000 tiendas WooCommerce publicado en marzo de 2026 encontró que un 12% seguía funcionando con PHP 7.4, una versión sin soporte desde hace más de tres años y que no recibe ningún parche aunque aparezca una vulnerabilidad grave. La 8.1, la siguiente versión en la lista, dejó de recibir parches el 31 de diciembre de 2025: cualquier web que la use hoy lleva meses expuesta a fallos que ya no se van a corregir nunca.
Ninguna de las dos deja de funcionar de golpe. WordPress sigue cargando, los formularios de contacto siguen enviando correos y las páginas se siguen sirviendo con normalidad aparente. Por eso el problema pasa desapercibido: no hay ningún aviso en el escritorio de administración que diga que la versión ha caducado, y la mayoría de despachos solo lo descubre cuando aparece un fallo de seguridad, una incompatibilidad con un plugin recién instalado o una migración de hosting que obliga a revisarlo todo de golpe.
Dos formas de comprobar la versión de PHP
No hace falta esperar a que el hosting avise, ni depender de que alguien más lo revise por ti. WordPress trae desde hace años una herramienta propia para consultarlo en dos clics, sin tocar el servidor.
El informe de salud del sitio, dentro de tu propio WordPress
En el escritorio de administración, el menú Herramientas incluye una sección llamada «Salud del sitio». Ahí aparece la versión de PHP activa junto al resto de datos técnicos del servidor, sin necesidad de pedírselo a nadie ni de abrir el panel de hosting. Si se prefiere consultarlo directamente en el servidor, el dato está igual de accesible en dos sitios habituales:
- cPanel: sección «Software», en la herramienta de selección de versión de PHP del dominio.
- Plesk: ficha del dominio, pestaña de configuración de PHP, donde también se puede cambiar la versión activa.
Conviene anotar la fecha de la revisión. Si pasan doce meses sin volver a mirarlo, es fácil acumular dos versiones de retraso sin que nadie lo haya decidido.
La actualización no depende solo del hosting
Cambiar la versión de PHP no depende solo de marcar una casilla en el panel del hosting. Cada plugin activo, el tema y los complementos de formularios, SEO o seguridad tienen que ser compatibles con la versión nueva, y no todos lo son el mismo día en que sale. Un plugin sin actualizar desde hace dos años puede dejar de funcionar de golpe, o peor: fallar a medias, sin mostrar ningún error visible en pantalla.
Por eso el cambio conviene probarlo primero en una copia de la web, no directamente sobre la que ve el público. Ahí se detecta cualquier incompatibilidad —un formulario que deja de enviar, un bloque de Elementor que se descuadra— antes de que la vea un cliente potencial que llega buscando al despacho.
Quien mantiene la web día a día —una agencia, un autónomo o el propio hosting cuando incluye soporte— es quien debería tener esta revisión en su calendario. No es una tarea que dependa de que el despacho se acuerde de preguntarla: si nadie la tiene asignada, simplemente no se hace.
El momento adecuado para programar el cambio
La fecha de fin de soporte de cada versión de PHP se conoce con años de antelación, así que no hace falta esperar a un aviso de última hora. Lo razonable es revisar la versión activa una vez al año, por ejemplo al renovar el hosting, y programar el salto antes de que la versión en uso entre en su último tramo de vida, el de solo parches de seguridad.
Esa revisión encaja bien con la de tu plan de hosting en general, porque muchas veces el cambio de versión de PHP y el cambio de plan van de la mano: los planes más recientes suelen traer ya la versión recomendada por defecto. Y conviene mirarlo junto al resto del mantenimiento técnico de WordPress, no como una tarea suelta y aislada. Un despacho que ya paga por mantenimiento debería tener esto cubierto sin necesidad de pedirlo expresamente; si no está claro que lo incluya, es la primera pregunta que conviene hacer.
Preguntas frecuentes sobre la versión de PHP
¿Qué versión de PHP recomienda WordPress en 2026?
La documentación oficial recomienda PHP 8.3 o superior. Es compatible con el núcleo y con la mayoría de plugins activos, y ofrece mejor rendimiento y más años de soporte de seguridad por delante que las versiones anteriores, ya cerca de su fin de vida.
¿Qué pasa si mi web sigue con una versión de PHP sin soporte?
Sigue funcionando con normalidad aparente, pero cualquier vulnerabilidad que se descubra a partir de ese momento no se corrige nunca. El riesgo crece con el tiempo, y algunos plugins empiezan a exigir una versión mínima más reciente para poder actualizarse.
¿Cambiar de versión de PHP puede romper mi web?
Puede, si algún plugin o el tema no son compatibles todavía. Por eso conviene probarlo antes en una copia de la web y no directamente en la versión publicada, revisando que formularios y funciones de Elementor sigan funcionando igual.
¿Cada cuánto hay que revisar la versión de PHP?
Una vez al año es suficiente en la mayoría de los casos, coincidiendo con la renovación anual del hosting. Si el despacho paga mantenimiento a una agencia, esta revisión debería formar parte del servicio contratado sin necesidad de pedirla.
Fuente: PHP.net – Supported Versions