Tu sitio en Craft CMS carga en 2,4 segundos. El de tu competencia, en 0,6.

Por qué dejar atrás el frontend monolítico de Craft CMS

Craft CMS 5 es, genuinamente, un buen software. El modelado de contenido es flexible, los campos Matrix son potentes y el panel de control es uno de los mejores del mercado. Pero el frontend basado en Twig está frenando tu sitio.

Cada petición de página pasa por PHP. Cada plantilla se renderiza en el servidor a través de un stack monolítico. Tus puntuaciones de Lighthouse en móvil se quedan entre 45 y 65 por mucho que optimices. El TTFB se arrastra entre 1,2 y 2,5 segundos. Y tus desarrolladores cambian constantemente de contexto entre plantillas Twig y el JavaScript que necesitan para la interactividad.

La solución no es abandonar el modelo de contenido de Craft. Es desacoplar completamente el frontend.

Una migración headless a Next.js preserva todo lo bueno de Craft —los bloques Matrix, las entradas relacionales, el flujo editorial— mientras reemplaza la capa de renderizado por algo que realmente rinde. Server components, caché en el edge e Incremental Static Regeneration. El resultado: un TTFB por debajo de los 300 ms y puntuaciones de Lighthouse superiores a 95.

Los verdaderos puntos de dolor que vemos en los sitios con Craft CMS

Hemos migrado decenas de sitios en Craft. Las quejas son llamativamente consistentes:

Techo de rendimiento

Has minificado el CSS, cargado imágenes de forma diferida, añadido caché con Redis y ajustado tu configuración de nginx. Lighthouse sigue mostrando naranja en móvil. El cuello de botella es arquitectónico: el renderizado con PHP no puede competir con páginas estáticas cacheadas en el edge ni con streaming server components. No hay ajuste que lo resuelva.

Complejidad de los campos Matrix a escala

Los campos Matrix son brillantes para 50 páginas. A partir de 500 con bloques Matrix anidados, entradas relacionales y requisitos de eager-loading, las consultas GraphQL se ralentizan de forma notoria. La lógica de las plantillas se convierte en condicionales Twig profundamente anidados. Añadir un nuevo tipo de bloque implica modificar múltiples archivos de plantilla. El problema se acumula rápido.

Contratación de desarrolladores

Encontrar desarrolladores senior de Twig/PHP que además escriban buen CSS y JavaScript es cada vez más difícil. Encontrar desarrolladores senior de React/Next.js no lo es. Tu bolsa de candidatos se amplía drásticamente con una arquitectura headless.

Costes de hosting

Craft requiere PHP, MySQL/Postgres, un servidor web y, normalmente, Redis o Memcached para un rendimiento aceptable. Eso son entre 40 y 120 £/mes como mínimo para un entorno de producción, más el mantenimiento del servidor. Un sitio en Next.js sobre Vercel empieza en 20 $/mes sin gestión de servidor.

Dependencia de plugins

Los plugins de Craft gestionan el SEO, los formularios, las redirecciones, las transformaciones de imágenes y mucho más. Cada uno es una dependencia con su propio ciclo de actualizaciones, matriz de compatibilidad y riesgo de rotura en actualizaciones mayores de Craft. Todo eso se acumula.

Cómo es la nueva arquitectura

No nos limitamos a cambiar Twig por React. Replanteamos todo el stack:

Frontend con Next.js 15 en Vercel

App Router con React Server Components. Las páginas se renderizan en el edge en menos de 100 ms. El Incremental Static Regeneration hace que las actualizaciones de contenido aparezcan en segundos sin reconstrucciones completas. La optimización de imágenes viene integrada mediante next/image. Sin ajustes de nginx, sin workers de PHP-FPM, sin dolores de cabeza por la invalidación de caché.

CMS headless para el contenido

Según tus necesidades, migramos el contenido a Sanity, Contentful, Payload CMS o mantenemos Craft 5 funcionando en modo headless. Si tus editores adoran el panel de control de Craft, lo conservamos: simplemente eliminamos el frontend Twig y consultamos el contenido a través de la API GraphQL nativa de Craft.

Supabase para los datos de la aplicación

Autenticación de usuarios, envíos de formularios, datos dinámicos, funcionalidades en tiempo real: Supabase gestiona lo que un CMS no debería. Base de datos Postgres, Edge Functions, Row Level Security y un generoso nivel gratuito. Reemplaza el conjunto de plugins de Craft que usabas para funcionalidades ajenas al contenido.

Vercel para el hosting y la red edge

Despliegues automáticos desde Git. Despliegues de previsualización para cada PR. Caché en el edge en más de 100 PoPs globales. Analítica e informes de velocidad integrados. Los costes de infraestructura se reducen mientras el rendimiento mejora en un orden de magnitud.

Nuestro proceso de migración

Ejecutamos una migración estructurada en 5 fases. Sin sorpresas, sin desvíos de alcance.

Fase 1: Auditoría de contenido y mapeo de URLs (Semana 1)

Rastreamos tu sitio Craft con Screaming Frog y exportamos la estructura completa del contenido. Cada sección, tipo de entrada, configuración de bloques Matrix y volumen de assets queda documentado. Mapeamos cada URL existente a su equivalente en Next.js y señalamos cualquier cambio estructural.

Esta fase produce dos entregables: un documento de especificación de migración de contenido y un mapa completo de redirecciones 301.

Fase 2: Diseño de arquitectura y esquema (Semana 2)

Diseñamos el nuevo esquema de contenido, ya sean secciones de Craft reestructuradas para el modo headless o un esquema nuevo en Sanity, Contentful o Payload. Los bloques Matrix se mapean a bloques de contenido tipados con esquemas explícitos. Las entradas relacionales se convierten en referencias apropiadas.

Se diseñan las tablas de Supabase para los datos de la aplicación (usuarios, formularios, contenido dinámico). Se definen los contratos de API entre Next.js y todas las fuentes de datos.

Fase 3: Desarrollo del frontend (Semanas 3-5)

Componentes de Next.js construidos a partir de tu sistema de diseño. Cada tipo de bloque Matrix se convierte en un componente React con interfaces TypeScript. Utilizamos un patrón BlockRenderer que mapea dinámicamente los tipos de bloques del CMS a los componentes correspondientes: añadir nuevos tipos de bloque más adelante es una única adición de archivo.

Las consultas GraphQL se coubican con los componentes de página. La obtención de datos usa el sistema de caché de Next.js con intervalos de revalidación apropiados. Las imágenes pasan por next/image con generación correcta de srcset.

Fase 4: Migración de contenido e implementación de redirecciones 301 (Semanas 5-6)

Scripts de migración personalizados gestionan la transferencia real del contenido. Los datos de los campos Matrix, los archivos de assets y las entradas relacionales se mueven al nuevo esquema con validación de integridad de datos.

Las redirecciones 301 se implementan en next.config.js para las redirecciones estáticas y en el edge middleware de Vercel para las reglas basadas en patrones. Verificamos cada redirección con pruebas automatizadas.

// next.config.js - ejemplo de estructura de redirecciones
const redirects = async () => [
  { source: '/blog/:slug', destination: '/articles/:slug', permanent: true },
  { source: '/services/:path*', destination: '/what-we-do/:path*', permanent: true },
  // Mapa completo generado a partir de la auditoría de URLs de Craft
];

Fase 5: Pruebas, lanzamiento y monitorización (Semanas 6-7)

Ejecutamos pruebas en paralelo: el sitio antiguo y el nuevo lado a lado. Los Core Web Vitals se validan frente a los objetivos (LCP < 2,5 s, CLS < 0,1, INP < 200 ms). Cada redirección 301 queda verificada. Se monitoriza Google Search Console en busca de errores de rastreo.

El lanzamiento se realiza con tiempo de inactividad cero mediante cambio de DNS. Monitorizamos el rendimiento en búsqueda durante 30 días tras el lanzamiento.

Estrategia de preservación del SEO

El SEO es donde la mayoría de las migraciones fallan. Hemos desarrollado un proceso que elimina la incertidumbre:

Cobertura del 100 % de las URLs. Cada URL indexada recibe una redirección 301. Sin excepciones. Cruzamos los datos de Google Search Console, los rastreos de Screaming Frog y el sitemap.xml para capturar cada URL.

Migración de metadatos. Las etiquetas de título, las meta descripciones, los datos Open Graph y los datos estructurados (JSON-LD) se migran y validan página por página. Si usabas el plugin SEOmatic de Craft, replicamos su salida de forma exacta.

Integridad de los enlaces internos. Todos los enlaces internos se actualizan a las nuevas URLs. Sin cadenas de redirecciones. Sin enlaces rotos.

Generación de sitemap XML. Sitemap dinámico generado a partir del contenido del CMS, enviado a Google Search Console el día del lanzamiento.

Etiquetas canonical y hreflang. Preservadas exactamente como estaban, o mejoradas si estaban mal configuradas.

Nuestros clientes suelen experimentar menos de un 3 % de fluctuación en el tráfico orgánico durante la migración, con recuperación y crecimiento en un plazo de 4 a 6 semanas.

Plazos y precios

Precios transparentes. Sin honorarios de descubrimiento, sin costes ocultos.

Sitios pequeños (menos de 50 páginas): 8.000-15.000 £ / 10.000-18.000 $. Plazo de 4-5 semanas.

Sitios medianos (50-500 páginas): 15.000-35.000 £ / 18.000-42.000 $. Plazo de 6-8 semanas.

Sitios grandes (más de 500 páginas): 35.000-80.000 £ / 42.000-95.000 $. Plazo de 8-12 semanas.

El precio escala con la complejidad del contenido (número de tipos de bloques Matrix, profundidad relacional, requisitos multilingües) y la funcionalidad personalizada (integraciones con Supabase, autenticación, comercio electrónico).

Los costes de hosting tras la migración: Vercel Pro a 20 $/mes, Supabase Pro a 25 $/mes y tu hosting de CMS si mantienes Craft en modo headless, o tu suscripción al CMS. La infraestructura total suele rondar los 50-100 $/mes, a menudo menos de lo que pagabas solo por el hosting de Craft.

Cada proyecto comienza con una auditoría de migración gratuita. Revisamos tu sitio actual en Craft, estimamos la complejidad del contenido y entregamos un presupuesto de precio fijo en un plazo de 48 horas.