WordPress sigue aquí

Cada pocos años aparece una tecnología que parece destinada a ocupar el lugar de WordPress.

Primero fueron los frameworks JavaScript. Después, los generadores de sitios estáticos, los CMS headless, las plataformas SaaS, las herramientas no-code y, más recientemente, la inteligencia artificial.

Cada nueva ola llega acompañada de una promesa parecida: una web más rápida, más flexible, más segura, más sencilla de mantener o más preparada para lo que viene después.

Y casi siempre reaparece también la misma predicción: esta vez sí, WordPress quedará atrás.

Es una predicción fácil de compartir. Sobre todo cuando llevas tiempo trabajando con él y conoces también todo lo que implica mantenerlo en funcionamiento.

Y, sin embargo, WordPress sigue aquí.

No necesariamente porque sea la opción más moderna ni porque no existan alternativas mejores para determinados proyectos. Sigue aquí porque, de algún modo, continúa formando parte de la conversación cuando toca decidir cómo construir y gestionar una presencia digital.

Quizá, por tanto, la pregunta interesante ya no sea por qué WordPress no ha desaparecido.

Quizá sea qué sigue resolviendo suficientemente bien como para que continuemos utilizándolo.

Permanecer no significa no haber cambiado

Que WordPress siga aquí no significa que haya permanecido intacto.

El WordPress actual se parece poco, en muchos aspectos, al CMS que utilizábamos hace quince años. Han cambiado el editor, la forma de construir interfaces, las APIs disponibles, las versiones de PHP sobre las que funciona, los entornos de hosting, los procesos de despliegue y las expectativas de rendimiento y seguridad.

También ha cambiado la relación entre quienes desarrollan una web y quienes después tienen que gestionarla.

Gutenberg introdujo una lógica basada en bloques. La REST API abrió la puerta a arquitecturas desacopladas. El alojamiento gestionado convirtió en servicios tareas que antes recaían directamente sobre desarrolladores o administradores de sistemas. Y prácticas como staging, control de versiones, automatización de despliegues o monitorización forman hoy parte de muchos proyectos que hace años se gestionaban de una forma mucho más artesanal.

Nada de esto convierte automáticamente a WordPress en una tecnología moderna por definición. Tampoco elimina las inercias, dependencias o problemas acumulados durante años.

Pero sí obliga a matizar una idea: WordPress no ha sobrevivido simplemente porque millones de sitios sigan utilizando una instalación antigua que nadie se atreve a tocar.

Ha permanecido porque ha ido cambiando.

Y quizá una de las claves de esa permanencia sea precisamente que ha conseguido hacerlo sin dejar de ser reconocible para quienes ya trabajaban con él.

No todas las webs necesitan ser productos de software

Buena parte de la conversación tecnológica sobre la web ocurre desde el punto de vista del desarrollo.

Hablamos de frameworks, arquitecturas, componentes, rendering, APIs, pipelines de despliegue o rendimiento. Y todo eso importa. Pero no todas las organizaciones necesitan construir un producto de software.

Muchas necesitan algo bastante más cotidiano: publicar y organizar contenido, mantener su información actualizada, preparar campañas o incorporar nuevas secciones cuando el proyecto lo requiere.

Una universidad. Una asociación. Una empresa industrial. Un medio. Una consultora. Una fundación. Una web corporativa.

En todos esos casos, la pregunta principal no siempre es cuál es la arquitectura más sofisticada, sino quién podrá trabajar con ella dentro de seis meses, dos años o cinco.

Porque una web no termina cuando se publica.

Después llegan los equipos de comunicación, marketing, contenidos, administración o negocio. Personas que no necesariamente quieren saber cómo funciona el frontend, dónde se despliega el proyecto o qué servicio está resolviendo cada petición.

Quieren poder trabajar.

Y ahí aparece una de las razones por las que WordPress continúa siendo difícil de apartar de determinadas conversaciones. No porque resuelva cada problema mejor que cualquier alternativa, sino porque durante años ha intentado resolver algo menos espectacular y, a menudo, más importante: permitir que una web siga siendo utilizable después de que termine el desarrollo inicial.

La ventaja menos visible: alguien tiene que gestionar la web

Cuando evaluamos una tecnología web, tendemos a mirar lo que ocurre durante el desarrollo.

Cómo se construye. Cómo se despliega. Cómo escala. Cómo se integra con otros sistemas. Qué rendimiento ofrece.

Pero una parte importante de la vida de una web empieza después.

Alguien tendrá que publicar una noticia, cambiar una página, sustituir una imagen, crear una landing, corregir un texto o reorganizar una sección. Y, en muchos proyectos, esas tareas no las hará el mismo equipo que construyó la plataforma.

Ahí WordPress compite en un terreno diferente.

No solo importa lo que puede hacer técnicamente, sino hasta qué punto permite que personas de comunicación, marketing, contenidos o negocio trabajen con cierta autonomía sin depender continuamente del equipo de desarrollo.

Desde fuera, muchas de esas tareas parecen menores. Desde dentro de una organización, no lo son.

Esperar varios días para cambiar un texto, abrir un ticket para sustituir una imagen o necesitar una nueva intervención técnica cada vez que aparece una campaña puede convertir una web perfectamente construida en una herramienta incómoda de utilizar.

Por eso, la experiencia editorial también forma parte de la arquitectura, aunque rara vez aparezca en los diagramas.

WordPress entendió muy pronto esa necesidad. Con resultados discutibles en algunos momentos y con una evolución que todavía sigue abierta, pero situando siempre la gestión de contenidos cerca del centro del producto.

Y probablemente ahí haya otra parte de su permanencia: no solo en lo que permite construir, sino en lo que permite seguir haciendo cuando quien desarrolló la web ya no está delante.

Un ecosistema puede ser una ventaja y un problema al mismo tiempo

Parte de la fortaleza de WordPress nunca ha estado únicamente en el software.

Está también en todo lo que existe alrededor: themes, plugins, proveedores de hosting, agencias, desarrolladores, documentación, integraciones y una comunidad enorme de personas que llevan años trabajando con la plataforma.

Ese ecosistema reduce barreras.

Es relativamente fácil encontrar a alguien que conozca WordPress, conectar un servicio externo, añadir una funcionalidad existente o resolver un problema que probablemente otra persona ya haya tenido antes.

Pero esa misma amplitud tiene un coste.

Cuantas más piezas entran en juego, más dependencias aparecen. Y no todas evolucionan al mismo ritmo, ni tienen la misma calidad, ni se mantienen durante el mismo tiempo.

Un plugin puede dejar de actualizarse. Otro puede entrar en conflicto con una nueva versión de PHP. Una plantilla puede condicionar durante años decisiones que parecían menores en el momento de instalarla. Y una funcionalidad incorporada rápidamente puede terminar convirtiéndose en una dependencia difícil de sustituir.

También aumenta la superficie que hay que vigilar: compatibilidades, actualizaciones, vulnerabilidades, rendimiento y decisiones técnicas tomadas por terceros sobre los que el proyecto no tiene control directo.

Por eso, algunas de las mayores ventajas de WordPress y algunos de sus problemas más conocidos tienen exactamente el mismo origen.

Su ecosistema.

Y quizá por eso resulte insuficiente hablar de WordPress como si fuera simplemente un CMS. Para entender tanto su permanencia como sus límites, hay que observar todo lo que existe alrededor.

Lo suficientemente bueno es una decisión tecnológica

En tecnología resulta fácil confundir lo más nuevo con lo mejor.

Una arquitectura más reciente puede ofrecer un rendimiento superior, una separación de responsabilidades más limpia, una experiencia de desarrollo más atractiva o una mayor capacidad de adaptación a determinados escenarios.

Pero ninguna arquitectura existe en abstracto.

Existe para un proyecto concreto, con un equipo concreto, un presupuesto determinado y una vida útil que probablemente será mucho más larga que el entusiasmo inicial por la tecnología elegida.

Por eso, una solución técnicamente más elegante no es necesariamente una mejor decisión.

También hay que preguntarse cuánto cuesta construirla, quién podrá mantenerla, qué conocimientos exige, cuánto depende de perfiles especializados, con qué facilidad podrá evolucionar y hasta qué punto permite trabajar con autonomía a quienes la utilizarán cada día.

Podríamos hablar aquí de suficiencia tecnológica: elegir una tecnología no porque sea capaz de hacer más, sino porque hace suficientemente bien aquello que el proyecto necesita sin introducir una complejidad que no aporta un valor equivalente.

Y quizá WordPress haya encontrado durante años precisamente ese espacio.

No siempre será la opción más rápida, la más elegante ni la que un desarrollador elegiría para empezar desde cero sin ninguna restricción. Pero en determinados proyectos sigue ofreciendo un equilibrio difícil de sustituir entre coste, flexibilidad, autonomía, disponibilidad de profesionales y conocimiento acumulado.

Eso no convierte a WordPress en la decisión correcta por defecto.

Pero sí ayuda a explicar por qué ser más antiguo no lo convierte automáticamente en la decisión equivocada.

Conclusión

Quizá estamos haciendo la pregunta equivocada.

Tal vez la pregunta no sea cómo puede seguir existiendo WordPress en 2026.

Tal vez la pregunta útil sea otra:

¿En qué contextos sigue teniendo sentido utilizarlo?

Ese cambio parece pequeño, pero cambia también la conversación.

Ya no se trata de enfrentar WordPress con frameworks modernos, CMS headless, plataformas SaaS o herramientas no-code para decidir cuál es superior en abstracto. Tampoco de defender que una tecnología veterana merece seguir utilizándose simplemente porque lleva muchos años haciéndolo.

Se trata de entender qué problema estamos intentando resolver, quién va a trabajar con la plataforma, durante cuánto tiempo, con qué recursos y con qué nivel de complejidad.

Esa será también la perspectiva de esta serie.

No vamos a explicar cómo instalar WordPress. No vamos a hacer una lista de plugins imprescindibles ni a intentar demostrar que sea mejor que cualquier alternativa.

Vamos a observar qué lugar ocupa hoy dentro de una web que ha cambiado profundamente a su alrededor: cuándo sigue siendo una buena decisión, cuándo empieza a convertirse en una carga y qué ocurre cuando intentamos adaptarlo a necesidades para las que quizá nunca fue pensado.

Porque que WordPress siga aquí no significa que tenga que estar en todas partes.

Y para entender por qué sigue aquí, primero tendremos que dejar de pensar en WordPress como una sola tecnología.

Si hoy tuvieras que empezar ese mismo proyecto desde cero, ¿volverías a elegir WordPress?