WordPress mueve el 43% de todas las webs del mundo — más que cualquier otra plataforma por una distancia enorme. No es una herramienta obsoleta ni un error de diseño. Es una plataforma madura, con una comunidad enorme, un ecosistema de plugins que resuelve prácticamente cualquier necesidad y miles de profesionales que la conocen a fondo. Nosotros la usamos durante años y la seguimos recomendando a clientes en los casos adecuados. Pero en 2026, cuando rediseñamos kronexia.com, decidimos no continuar con WordPress. Las razones fueron concretas, medibles y específicas de nuestro caso. Este artículo las explica sin humo, junto con los casos en los que WordPress sigue siendo la mejor decisión.

El punto de partida: qué teníamos con WordPress

La versión anterior de kronexia.com era una web WordPress estándar: tema de pago, una decena de plugins activos, hosting compartido con SSL, actualizaciones manuales y un panel de administración que cualquier persona podía usar sin conocimientos técnicos.

Funcionaba. El sitio cargaba, el formulario de contacto enviaba emails, el blog tenía entradas. No había ningún problema urgente que resolver.

Pero había acumulación silenciosa. No de un solo problema grande, sino de varios problemas pequeños que juntos empezaban a pesar.

Los factores que nos hicieron decidir el cambio

1. El rendimiento en móvil no mejoraría sin cambiar la arquitectura

El LCP (Largest Contentful Paint — el tiempo que tarda el elemento principal de la página en aparecer) estaba por encima de 4,5 segundos en móvil. Google usa el LCP como factor de posicionamiento desde que introdujo los Core Web Vitals como señales de ranking.

El problema no era el hosting ni el tema elegido. Era arquitectural: WordPress genera HTML en el servidor en cada visita y envía al navegador todo el JavaScript de los plugins activos, independientemente de si esa página los necesita o no. En un WordPress optimizado con caché, lazy loading y un tema ligero, se puede llegar a 65-80 puntos en PageSpeed Insights en móvil. Raramente más, como documentamos en el caso de mantenimiento de Coaching for Business.

Con Next.js, la web de Kronexia carga el hero en menos de 1 segundo en móvil. El mismo elemento que antes tardaba 4,7 segundos. No es optimización: es una diferencia de arquitectura.

2. El mantenimiento de plugins era un trabajo en sí mismo

Con diez plugins activos, mantener la web segura requería atención constante: revisar actualizaciones cada semana, probar que cada actualización no rompía algo, mantener copias de seguridad antes de actualizar, revisar logs de intentos de acceso, renovar las licencias de los plugins de pago.

Ese tiempo no genera ningún valor para el negocio. Es coste de mantenimiento del sistema, no inversión en mejorar el sitio. Como documentamos en el artículo sobre plugins peligrosos en WordPress, el riesgo de seguridad de un WordPress con plugins desactualizados no es teórico: es rutinario.

Con la web actual de Kronexia no hay plugins que actualizar. No hay WordPress que parchear. Hay un repositorio en GitHub del que Vercel despliega automáticamente cuando hay un cambio. El mantenimiento de seguridad se reduce a mantener las dependencias de Node actualizadas, algo que los bots de GitHub hacen con una pull request automática.

3. El control sobre el rendimiento y la apariencia era limitado

En WordPress, el comportamiento técnico de la web depende en gran parte del tema y de los plugins elegidos. Si el tema genera código ineficiente, el margen de mejora está acotado por cómo está construido ese tema. Si dos plugins generan conflictos, la solución pasa por cambiar uno de ellos o por entender código PHP de terceros.

Con Next.js y código propio, cada decisión de rendimiento es explícita. El hero de kronexia.com usa CSS puro para las animaciones en lugar de Framer Motion porque el análisis mostró que Framer Motion añadía tiempo de carga sin beneficio visual apreciable. Esa decisión es posible cuando controlas exactamente qué código corre en qué página.

4. El coste de hosting a largo plazo escalaba

Un hosting WordPress compartido con rendimiento decente para una web de empresa en España está entre 8€ y 20€/mes. Un hosting de mayor calidad (VPS administrado) puede estar entre 30€ y 60€/mes. Y eso sin contar las licencias de los plugins de pago.

La web actual de Kronexia está en Vercel (plan Hobby, gratuito para uso personal) con DNS en Cloudflare (gratuito). El coste de hosting es cero. No es el factor decisivo, pero sumado a los demás inclina la balanza.

Lo que ganamos con el cambio

Rendimiento: LCP en móvil por debajo de 1 segundo. PageSpeed Insights en móvil consistentemente por encima de 90/100. Sin optimización activa — es el resultado por defecto de la arquitectura.

Seguridad: sin plugins, sin WordPress que parchear, sin panel de administración accesible desde /wp-admin. La superficie de ataque se reduce radicalmente. Hemos implantado un filtro anti-spam en el formulario a nivel de código, sin depender de plugins de terceros.

Deploy automático: cada cambio en el repositorio de GitHub despliega automáticamente en Vercel. Los artículos del blog programados se publican solos a través de una GitHub Action sin intervención manual. El ciclo de actualización es minutos, no horas.

Control total: cada línea de la web es código que conocemos. No hay cajas negras de plugins. No hay actualizaciones que rompan algo inesperadamente.

Edición de contenido sin código: TinaCMS permite editar textos, añadir artículos al blog y actualizar contenido desde un panel visual en kronexia.com/admin, con login de GitHub. No es tan inmediato como el editor de WordPress, pero es suficientemente accesible para el uso real que hace una web de empresa de su propio admin: actualizar el blog y ajustar textos ocasionalmente.

Lo que perdimos (honestidad)

No todo fue una mejora. Hay cosas que WordPress hacía bien y que con Next.js requieren más trabajo o son directamente peores:

La curva de entrada para nuevos contenidos. El editor de WordPress (Gutenberg) es más flexible e intuitivo para alguien no técnico que TinaCMS. Añadir un bloque de imagen, una llamada a la acción o un vídeo embebido en WordPress es cuestión de clics. En TinaCMS, lo que no está configurado en el schema no aparece como opción en el editor.

El ecosistema de plugins. Si mañana necesitamos una funcionalidad nueva —un sistema de reservas, un chat, una tienda— en WordPress hay un plugin para eso. Con Next.js hay que construirlo, integrarlo con una API externa o usar un componente. Es más flexible a largo plazo, pero más trabajo a corto plazo.

La comunidad de no-técnicos. Para WordPress hay tutoriales de YouTube para absolutamente cualquier cosa, en español, gratuitos. Para Next.js hay documentación excelente pero orientada a desarrolladores. Si el propietario del negocio quiere hacer cambios de diseño o funcionalidad por su cuenta, WordPress es mucho más accesible.

La portabilidad del contenido. En WordPress, el contenido vive en una base de datos que se puede exportar con un clic. En kronexia.com, el contenido vive en archivos MDX en GitHub — igualmente exportable, pero requiere saber qué se está buscando.

Cuándo WordPress sigue siendo la mejor opción

Esta sección importa tanto como el resto del artículo. No hay una respuesta universal de "WordPress vs. moderno" — hay una respuesta específica para cada proyecto.

WordPress es la mejor opción cuando:

  • El cliente quiere gestionar el contenido de forma autónoma, incluyendo cambios de diseño, añadir secciones nuevas o modificar estructuras de página. El ecosistema visual de WordPress (Elementor, Beaver Builder, Divi) permite hacer eso sin tocar código.

  • El proyecto necesita una tienda online con catálogo grande, gestión de inventario, variantes de producto, cupones y pasarelas de pago. WooCommerce sigue siendo una de las soluciones más completas para e-commerce de tamaño medio en WordPress.

  • El presupuesto es ajustado y hay que maximizar la funcionalidad disponible en el menor tiempo posible. Los miles de plugins de WordPress resuelven en horas lo que requeriría días de desarrollo a medida.

  • El cliente ya tiene un WordPress funcionando, el equipo que le da soporte conoce WordPress y las mejoras necesarias no justifican una migración. Optimizar un WordPress existente puede ser perfectamente suficiente.

  • El proyecto necesita funcionalidades muy específicas de WordPress: multisitio, roles avanzados de usuario, multilingüe con WPML, integración con WooCommerce, o cualquier funcionalidad para la que hay un plugin consolidado con miles de instalaciones activas.

Nosotros seguimos haciendo proyectos WordPress para clientes cuando el caso lo justifica. La plataforma no es el problema; la gestión descuidada de ella sí puede serlo.

Una tecnología más moderna puede tener sentido cuando:

  • El rendimiento en móvil es crítico para el negocio (tiendas, servicios con competencia alta en buscadores, webs de captación de clientes) y el WordPress actual no llega a los umbrales de Core Web Vitals.

  • El coste de mantenimiento de plugins, actualizaciones y seguridad empieza a ser significativo en tiempo o dinero y el sitio no cambia de contenido frecuentemente.

  • El sitio tiene necesidades de rendimiento o integraciones muy específicas que chocan con los límites de la arquitectura de WordPress.

  • Es un proyecto nuevo sin herencia tecnológica, donde el stack puede elegirse desde cero en función de los requisitos reales.

La pregunta que hay que hacerse antes de migrar

Migrar una web tiene un coste: tiempo de desarrollo, redirecciones de SEO, adaptación del contenido, formación del equipo en el nuevo sistema. Ese coste solo se justifica si los problemas que se resuelven tienen un impacto real en el negocio.

Las preguntas que orientan esa decisión:

¿El rendimiento actual está afectando a las conversiones o al posicionamiento? Si el sitio tiene buen tráfico, buenas conversiones y PageSpeed aceptable, el argumento técnico para migrar es débil. Si el tráfico orgánico lleva meses bajando o la tasa de rebote en móvil es alta, el rendimiento puede ser parte del problema.

¿Cuánto tiempo se dedica al mantenimiento del WordPress actual? Si la respuesta es "básicamente ninguno porque no se actualiza", la web tiene un problema de seguridad que hay que resolver antes de plantearse si migrar.

¿El contenido cambia con frecuencia? Un sitio que se actualiza poco (5-10 cambios al año) necesita menos del ecosistema editorial de WordPress. Uno con blog activo, noticias frecuentes o catálogo que cambia constantemente aprovecha más las herramientas de WordPress.

¿Hay integraciones específicas de WordPress de las que depende el negocio? WooCommerce, un plugin de reservas específico, un sistema de membresías — si esas integraciones funcionan y son críticas, el coste de replicarlas en otra plataforma puede no valer la pena.

En kronexia.com, la respuesta a todas esas preguntas fue clara en una dirección. En otros proyectos, puede ser la contraria.

Preguntas frecuentes

¿Es WordPress seguro?

El núcleo de WordPress tiene un historial de seguridad razonablemente bueno — el equipo de seguridad oficial lo actualiza con rapidez cuando aparecen vulnerabilidades críticas. El problema de seguridad en WordPress casi siempre viene de plugins desactualizados o abandonados, temas de fuentes no oficiales y contraseñas débiles. Un WordPress bien mantenido, con plugins mínimos y actualizados, es perfectamente seguro para la gran mayoría de webs de empresa.

¿Qué es Next.js y por qué lo usamos?

Next.js es un framework de desarrollo web basado en React, creado y mantenido por Vercel. Permite construir webs que se renderizan en el servidor (para mejor SEO y velocidad de carga) y en el cliente (para interactividad). Es la tecnología detrás de webs de empresas como Notion, TikTok, Twitch y muchas otras. Para proyectos nuevos donde el rendimiento y el control técnico son prioritarios, es actualmente una de las mejores opciones disponibles.

¿Perderé posicionamiento SEO si migro de WordPress?

Depende de cómo se haga la migración. Los riesgos principales son: cambiar las URLs sin redireccionamientos 301 correctos (hace que Google pierda las páginas indexadas), perder el contenido de los artículos o perder los metadatos de SEO. Una migración bien hecha — con redirecciones, sitemap actualizado, revisión en Google Search Console — generalmente no pierde posicionamiento y en muchos casos lo mejora gracias al mejor rendimiento.

¿TinaCMS reemplaza completamente al editor de WordPress?

Para edición de contenido de blog y ajustes de texto en páginas existentes, sí. Para añadir nuevas secciones, cambiar el layout de una página o crear tipos de contenido nuevos, TinaCMS requiere que esas posibilidades estén configuradas previamente en el schema. No es tan inmediato como el editor visual de WordPress para un usuario sin conocimientos técnicos, pero es suficiente para el uso real que hace una web de empresa de su propio panel de administración.

¿Cuánto cuesta migrar de WordPress a Next.js?

Depende del tamaño del sitio, del volumen de contenido a migrar y de las integraciones que tenga el WordPress actual. Una web de empresa de 6-8 páginas sin tienda, con blog y formulario de contacto, puede migrarse en un rango de semanas de trabajo. El coste incluye diseño (si se actualiza), desarrollo, migración de contenido, configuración de hosting y redirecciones SEO. En nuestro servicio de webs detallamos qué incluye y cómo funciona el proceso.

¿Puedo tener un WordPress y una web moderna al mismo tiempo?

No en el mismo dominio raíz. Pero sí es posible, por ejemplo, tener la web principal en Next.js y un subdominio (blog.tuempresa.com) en WordPress si el flujo editorial de WordPress es importante para el equipo. En la práctica, para la mayoría de empresas pequeñas y medianas esa arquitectura híbrida añade complejidad sin beneficio proporcional.