Sitio desactualizado: el riesgo de dejar WordPress quieto

El sitio de la empresa se lanzó hace unos años, funciona y recibe contactos. Nadie lo toca desde entonces. Visto desde fuera, todo está bien. Por dentro, funciona sobre un conjunto de software que envejece cada mes, y parte de él ya no recibe parches de seguridad.

Ese es el retrato de buena parte de los sitios WordPress en Brasil y en el mundo. Y el 31 de diciembre de 2026 la situación empeora: otra versión de PHP, el lenguaje sobre el que funciona WordPress, deja de recibir parches. En este artículo muestro las cifras, qué está realmente en riesgo y qué pedir a quien gestiona tu sitio antes de fin de año.

Uno de cada tres sitios WordPress ya va sin parches

WordPress publica en tiempo real las estadísticas de versiones en uso en los sitios que monitorea. En la consulta del 29 de octubre de 2026, el reparto de PHP era este:

• el 33,2% de los sitios usaba PHP 8.1 o anterior, versiones que ya no reciben parches de seguridad;
• el 14,9% seguía en PHP 7.4, que perdió el soporte en noviembre de 2022;
• el 22,5% usaba PHP 8.2, que pierde el soporte de seguridad el 31 de diciembre de 2026.

Las fechas son del calendario oficial de PHP. PHP 8.1 salió de la lista el 31 de diciembre de 2025, y la página de versiones sin soporte advierte que pueden tener fallos de seguridad sin parchear.

Suma las dos líneas: si nada cambia antes de fin de año, más de la mitad de los sitios WordPress (55,7%) funcionará sobre un PHP sin parches de seguridad en enero de 2027.

El propio WordPress lo dice en su página de requisitos. Recomienda PHP 8.3 o superior y avisa que las versiones antiguas aún funcionan, pero “llegaron al fin de su vida oficial” y “pueden exponer tu sitio a vulnerabilidades”.

Por qué “funciona” no significa “es seguro”

El software sin soporte no deja de funcionar. Solo deja de corregirse. El sitio carga, el formulario se envía, el dueño no nota nada. Cuando se descubre un fallo nuevo en esa versión, nadie publica el parche.

El riesgo no viene solo de fallos nuevos. El informe State of WordPress Security in 2026, de Patchstack, muestra que de los 10 fallos más atacados en sitios WordPress en 2025, 6 se habían publicado en 2023 o 2024. Los atacantes siguen probando fallos viejos porque saben que muchos sitios nunca aplicaron el parche.

En la práctica, un sitio sin mantenimiento se vuelve un blanco fácil por tres vías:

1. PHP sin soporte. La base del sitio deja de recibir parches. Cualquier fallo nuevo queda abierto para siempre en esa versión.
2. Plugins y tema viejos. Cada plugin es software de otro proveedor. Si nadie lo actualiza, el parche existe, pero no llega a tu sitio.
3. Plugins abandonados. Algunos proveedores simplemente dejan de actualizar. Cuando aparece un fallo, no hay parche que aplicar, y la única salida es cambiar el plugin.

Un hackeo casi nunca tumba el sitio. Lo más común es que empiece a redirigir visitas a páginas falsas, aparezca en Google con enlaces de spam o el navegador lo marque como peligroso. Pierdes contactos, posición en Google y confianza, muchas veces antes de saber qué pasó. Si ya ocurrió, la guía de qué hacer cuando hackean tu sitio ayuda en las primeras horas.

Qué suele frenar la actualización

Si actualizar lo resuelve, ¿por qué tantos sitios quedan quietos? Casi siempre por uno de estos motivos:

• Nadie es responsable. El sitio se entregó, el contrato terminó y el mantenimiento nunca se acordó.
• Miedo a romperlo. Una actualización ya tumbó el sitio, y desde entonces nadie lo toca.
• Tema o plugin incompatible. Un componente antiguo no funciona con el PHP nuevo, y cambiarlo da trabajo.
• Acceso perdido. El hosting o el panel están a nombre de quien hizo el sitio, y la empresa no puede entrar.

Todos tienen solución. Pero ninguno se resuelve solo, y cuanto más tiempo pasa, mayor es el salto entre la versión actual y una con soporte.

Qué pedir a quien gestiona tu sitio

Antes de cualquier presupuesto, pide un inventario por escrito. Son cinco preguntas:

1. ¿Qué versión de PHP tiene el servidor del sitio?
2. ¿Qué versión de WordPress usa?
3. ¿Cuántos plugins hay instalados y cuándo se actualizó cada uno por última vez?
4. ¿El tema todavía recibe actualizaciones del proveedor?
5. ¿Existe una copia del sitio para probar actualizaciones antes de publicarlas?

Con esas respuestas, el plan queda claro:

• PHP 8.1 o anterior: prioridad alta. El sitio ya funciona sin parches. Actualiza a 8.3 o superior, probando antes en una copia.
• PHP 8.2: tienes hasta el 31 de diciembre de 2026. Programa la actualización ahora, no en la última semana de diciembre.
• Plugins sin actualizar hace más de un año: cámbialos o elimínalos. Cada plugin menos es una puerta menos.
• Tema abandonado: compara el costo de cambiar el tema con el de rehacer el sitio.

Y no te quedes en la actualización. Lo que protege es la rutina: actualizar con frecuencia fija, probar antes, tener copias de seguridad fuera del hosting. Detallé ese mínimo en backup y seguridad del sitio, y la diferencia entre arreglar lo que se rompió y evitar que se rompa en mantenimiento correctivo, preventivo o evolutivo.

¿Actualizar o rehacer?

No todo sitio desactualizado necesita rehacerse. Si tiene pocos plugins, el tema sigue mantenido y PHP sube de versión sin romper nada, actualizar lo resuelve y cuesta poco.

La cuenta cambia cuando el sitio depende de decenas de plugins, el tema dejó de actualizarse y cada actualización se vuelve un proyecto. En ese caso, pagas por mantener vivo un sitio que volverá a envejecer al año siguiente.

Un sitio en código propio, sin panel expuesto y sin plugins de terceros, tiene muchas menos piezas que actualizar. Es el caso de los sitios que hacemos y mantenemos en nuestro servidor, como amandanutri.com.br, sitio de una nutricionista con atención 100% en línea y agenda por WhatsApp, y conversaovisual.com.br, página de ventas de un curso que marcó 99 de 100 en Google Lighthouse en octubre de 2026.

No hace falta decidir a ciegas. El inventario de las cinco preguntas muestra cuánto trabajo cuesta actualizar, y esa cifra se puede comparar con el costo de rehacer.

Cómo lo hacemos en el Studio

Desde 2014 ponemos productos digitales en marcha, con más de 600 proyectos en 13 países. Cuando un sitio nos llega para mantenimiento, empezamos por el diagnóstico: versiones, plugins, tema, accesos y backup. El precio cerrado se define después de ese diagnóstico, y el plazo va por escrito en el contrato.

El código, los archivos y los accesos, incluidos dominio y hosting, quedan a nombre del cliente. Trabajamos con nuestro equipo de desarrollo, y usamos Claude Code y Figma en el diseño y el build. Todo sistema que entregamos sale con un agente de IA que corre a diario, señala fallos, sugiere mejoras y verifica que los datos tengan sentido.

Si tu sitio está en PHP 8.2 o anterior, faltan semanas para el fin del soporte. Escríbenos a través del servicio de mantenimiento y evolución del sitio y cierra diciembre con el sitio actualizado y una rutina para que no vuelva a envejecer.