Seguridad de PHP: por qué migramos de WordPress a código

La seguridad fue la razón principal para pasar nuestro sitio de WordPress a código. En WordPress casi todo el riesgo está en los plugins: según Patchstack, el 91 % de las vulnerabilidades nuevas de 2025 apareció en plugins y el 46 % no tenía parche del autor cuando se hizo pública. Un sitio con páginas ya generadas deja mucho menos código de terceros expuesto en cada visita.

Durante años nuestro propio sitio vivió en WordPress con Elementor. Cada aviso de una vulnerabilidad nueva en PHP o en un plugin significaba lo mismo: revisar qué teníamos instalado, esperar el parche del proveedor y actualizar con la esperanza de que nada se rompiera. Qué pasa en el servidor en cada visita, y cuándo WordPress sigue siendo buena opción, lo explicamos en por qué construimos en código y no en WordPress. Aquí nos quedamos con la seguridad.

Dónde están las vulnerabilidades de WordPress

Patchstack, una empresa que registra vulnerabilidades del ecosistema WordPress, contó 11.334 vulnerabilidades nuevas en 2025, un 42 % más que en 2024. El 91 % estaba en plugins y el 9 % en temas; en el núcleo de WordPress se reportaron solo seis.

El problema no es PHP como lenguaje, sino la cantidad de código de terceros que se ejecuta en cada visita. Un sitio típico suma el núcleo de WordPress, un tema, un page builder y una lista de plugins, cada uno escrito por un equipo distinto que publica parches a su propio ritmo. La guía oficial para proteger WordPress lo resume en dos consejos: mantener los plugins siempre actualizados y borrar los que no usas.

Qué es la ventana de exposición

Cuando se publica una vulnerabilidad de PHP, de WordPress o de un plugin, la información queda disponible para cualquiera, incluidos quienes buscan sitios sin actualizar. Desde ese momento tu sitio está expuesto hasta que pasen dos cosas: que el autor publique el parche y que alguien lo instale en tu servidor.

Esa ventana no siempre es corta. Según Patchstack, el 46 % de las vulnerabilidades de 2025 no recibió un parche del autor a tiempo para su publicación, y en las vulnerabilidades más atacadas pasaron, en mediana ponderada, cinco horas entre la regla de protección que publicó Patchstack y el primer intento de ataque. Si el plugin está abandonado, el parche nunca llega. Si la actualización choca con otro plugin, el sitio se rompe y toca elegir entre un sitio caído y un sitio vulnerable.

1. 1Se publica la vulnerabilidadQueda disponible para cualquiera, incluidos quienes buscan sitios sin actualizar.
2. 2El autor publica el parcheSi el plugin está abandonado, este paso nunca llega.
3. 3Alguien lo instala en tu servidorSi choca con otro plugin, el sitio se rompe.

Tu sitio está expuesto durante todo este tiempo

Qué cambia con una página ya generada

En un sitio hecho en código con Next.js, las páginas de contenido se generan cuando publicamos, no cuando alguien las pide. El visitante recibe HTML listo: no hay PHP que ejecutar, ni plugins que cargar, ni una base de datos detrás de cada visita, ni un panel de administración público en /wp-admin.

Las partes que sí necesitan un servidor, como el envío de un formulario, se resuelven con funciones pequeñas hechas solo para esa tarea, con validación de datos y límite de solicitudes. Las dependencias del proyecto quedan fijadas en el repositorio y cada cambio pasa por pruebas antes de publicarse: nada se actualiza solo en producción.

Primer caso: nuestro propio sitio

Empezamos por casa. El sitio que estás leyendo pasó de WordPress con Elementor a Next.js con React y TypeScript. El sitio anterior nunca tuvo títulos ni descripciones SEO configurados; el nuevo los genera desde el código en cada página, en español e inglés, con hreflang y datos estructurados de schema.org.

También lo preparamos para los buscadores con IA: el robots.txt permite a rastreadores como GPTBot, ClaudeBot y PerplexityBot, publicamos un archivo llms.txt y cada respuesta de nuestras preguntas frecuentes está escrita para poder citarse sola. Más de mil pruebas automatizadas revisan cada cambio antes de publicarlo. El caso completo está en WilkieDevs: de WordPress a código.

Segundo caso: Cube Media

Cube Media es el segundo proyecto que construimos en código desde cero. Es un sitio de portafolio en Next.js 16 donde el equipo edita textos y proyectos desde Sanity CMS, sin tocar código ni instalar plugins.

El sitio funciona en español e inglés con rutas localizadas, usa transiciones entre páginas con la API View Transitions y su formulario de contacto valida los datos, tiene un campo trampa contra bots y un límite de solicitudes antes de enviar el correo. Si el CMS no responde, el sitio sigue en pie con un cliente de respaldo.

Cómo revisar los plugins de tu WordPress

Tres preguntas rápidas sobre tu sitio actual:

1. ¿Cuántos plugins tienes activos y cuándo se actualizó cada uno por última vez?
2. ¿Alguno de ellos dejó de recibir actualizaciones de su autor?
3. ¿Quién instala los parches cuando se publica una vulnerabilidad, y en cuánto tiempo?

Si alguna respuesta es "no sé", empieza por actualizar lo que tenga parche y borrar los plugins que no usas. En octubre negro contamos un caso reciente de fallos graves en el propio PHP, y en desarrollo web cómo migramos un sitio a código sin perder posicionamiento. Si quieres que revisemos tu caso, escríbenos.

Fuentes

• State of WordPress Security in 2026, Patchstack
• Hardening WordPress, WordPress.org
• Manage Plugins, WordPress.org