En los últimos años han aparecido diversas alternativas a WordPress, el más popular de los sistemas de administración de contenidos web (CMS por sus siglas en inglés). Algunas vienen desde el mundo del desarrollo moderno, otras desde empresas dedicadas a infraestructura, y otras desde empresas que llevan tiempo observando los mismos problemas en distintos proyectos.

Sin ir más lejos, en este mes de Abril Cloudflare, una de las empresas de infraestructura más importantes, liberó emDash CMS, un sistema que intenta replantear varias decisiones que hoy se dan por sentadas: cómo se entrega el contenido, cómo se optimiza, y qué tan predecible es el sistema cuando empieza a crecer.

No es un caso aislado. Actualmente existe una tendencia hacia soluciones más acotadas, más controladas y más alineadas con la forma en que hoy se construyen y distribuyen las aplicaciones. Aun así, cuando uno aterriza esto a un proyecto real, la conversación suele ser bastante más simple.

Se busca un sistema autoadministrable, que se pueda implementar rápido, que funcione en el hosting (alojamiento web) que ya está contratado, y que permita resolver múltiples tareas sin tener que desarrollar todo desde cero. En la práctica, eso suele llevar a un set de tecnologías conocias, donde WordPress sigue siendo una opción razonable, considerando que posee sobre un 50% de uso dentro de los CMS y otras opciones están por debajo del 8% de uso (Referencia: https://w3techs.com/technologies/overview/content_management).

Al utilizar esta alternativa “que todos usan” el punto de fricción no suele aparecer al inicio. Aparece después, en decisiones pequeñas que se van acumulando.

Por ejemplo, cuando se necesita agregar un formulario más complejo y se instala un plugin; luego otro para SEO; otro para caché; para manejar redirecciones; etc. Y al final, cada uno resuelve algo puntual pero también agrega su propia lógica, sus propias dependencias y sus propias actualizaciones. Y así, en un momento difícil de predecir, una actualización automática rompe el diseño de la página y no siempre es evidente el por qué. Puede ser un cambio en un plugin, en el tema, o en cómo se comunican entre sí. El sitio sigue funcionando, pero algo dejó de verse como antes y hay que empezar a revisar capas que nadie documentó.

También pasa con el rendimiento. Un sitio comienza cargando rápido, pero con el tiempo empieza a demorarse más, no hay un único culpable claro: imágenes sin optimizar, plugins que cargan recursos en todas las páginas, consultas a base de datos que crecieron sin que nadie las revisara. Desde fuera, simplemente “el sitio está más lento”.

Otro caso común es cuando el cliente quiere hacer un cambio aparentemente simple —mover una sección, ajustar un contenido, integrar algo nuevo— y ese cambio termina siendo más complejo de lo esperado porque está amarrado a cómo se configuró un plugin o a cómo se estructuró el tema en su momento.

Nada de esto es un error aislado. Es más bien la forma en que estos sistemas evolucionan cuando crecen sin una lógica clara de mantenimiento.

Las nuevas propuestas de CMS emergen en ese contexto. Buscan reducir este tipo de situaciones desde el diseño del sistema: limitar la cantidad de capas, definir mejor cómo se extiende la funcionalidad, y apoyarse más en la infraestructura que en soluciones internas acumulativas. Eso tiene implicancias. En muchos casos se gana en estabilidad y en rendimiento, pero se pierde parte de la flexibilidad inmediata que hace que herramientas como WordPress sean tan atractivas al inicio.

Por todo lo anterior es que la decisión no suele resolverse comparando herramientas en abstracto. Termina siendo más útil entender qué tipo de cambios va a tener el sitio hoy y en un futuro proyectado, quién se va a hacer cargo de mantenerlo y qué tan crítico es que el sistema sea predecible en el tiempo. Las claves están en definir “cómo” se va administrar el sitio antes de definir “qué” herramienta instalar.

Hay proyectos donde WordPress funciona bien durante años. Hay otros donde empieza a generar fricción bastante antes de lo esperado, y también, hay casos donde vale la pena partir desde una base distinta, aunque eso implique un poco más de trabajo al inicio. La mejor alternativa será siempre la que encaje con la mayor cantidad de variables relevantes para tu proyecto.

En Slash trabajamos con distintas tecnologías que adaptamos según el contexto de cada proyecto, pero la parte más importante de nuestro acompañamiento digital está en anticipar este tipo de escenarios para simplificar la decisión del cliente. No es la herramienta, sino cómo se toman las decisiones que la rodean.