Migración a Next.js y Astro: SEO, riesgos y arquitectura

#Por qué migrar tu sitio web a Next.js o Astro?

#Rendimiento: números reales tras la migración

Las empresas que pasaron de un WordPress monolítico a una arquitectura headless reportan una mejora medible, no una impresión subjetiva:

• Reducción del 80-90% en TTFB (Time to First Byte): las páginas llegan al navegador antes de que el usuario se impaciente.
• PageSpeed Insights 95-100 de forma constante, no como excepción puntual el día que se ejecuta la auditoría.
• LCP por debajo de 2,5 segundos, cumpliendo el umbral de Core Web Vitals que Google marca en verde.
• INP por debajo de 200 ms: la interfaz responde al instante al tocar un botón o abrir un menú.
• CLS cercano a cero: sin saltos de maquetación mientras carga el contenido.

La diferencia se nota especialmente en móvil, donde una conexión 4G irregular castiga a los sitios pesados.

#Seguridad del sitio tras la migración

Un WordPress tradicional con decenas de plugins es una puerta entreabierta para cualquier atacante. La arquitectura headless cambia el modelo de raíz:

• Frontend estático: el visitante recibe archivos HTML ya generados, no código PHP ejecutándose en vivo con cada petición.
• Sin riesgo de inyección SQL: la base de datos no queda expuesta al frontend público.
• Se eliminan las vulnerabilidades de plugins: no hay página de login de WordPress accesible ni plugins ejecutándose de cara al usuario.
• Seguridad a nivel de API: rate limiting, autenticación y políticas CORS para el backend, que queda oculto tras un firewall.

Para un negocio sujeto al RGPD y a la vigilancia de la AEPD, reducir la superficie de ataque tiene una lectura directa: menos brechas potenciales de datos personales, menos exposición a sanciones y menos noches en vela cada vez que se publica un aviso de vulnerabilidad crítica en un plugin popular.

#Costes de hosting tras la migración

Servir archivos estáticos desde una CDN sale mucho más barato que mantener un servidor de origen procesando PHP en cada visita:

• Hosting WordPress tradicional: facturas que escalan con el tráfico, porque cada petición golpea PHP y la base de datos.
• Hosting estático tras la migración: archivos ya generados servidos desde CDN, que a menudo caben en un plan gratuito o de bajo coste incluso con volumen relevante.
• Menor coste de mantenimiento, porque no hay un servidor de origen que parchear, afinar y escalar bajo carga.

Muchos proyectos españoles arrancan en un hosting nacional compartido (Webempresa, Raiola Networks) y ese salto de plataforma es donde el ahorro se hace visible.

#Astro o Next.js: cuál elegir para la migración?

Es la pregunta que abre casi todas las reuniones de arranque. La respuesta depende del tipo de proyecto.

#Cuándo elegir Astro

Astro parte de una filosofía “content-first”. Por defecto envía cero kilobytes de JavaScript al navegador, lo que lo convierte en la opción más rápida del mercado para sitios informativos.

Mejores casos de uso:

• Sitios corporativos y de empresa orientados a conversión.
• Blogs y portales de contenido con cientos de artículos.
• Landing pages donde el rendimiento es la prioridad.
• Documentación técnica y bases de conocimiento.

Ventajas técnicas de Astro:

• Arquitectura de “islas”: el JavaScript solo se carga donde de verdad hace falta.
• Soporte nativo para React, Vue y Svelte, así que puedes reutilizar componentes existentes.
• Optimización de imágenes integrada con conversión automática a AVIF y WebP.
• Renderizado en servidor y generación estática en el mismo framework, con View Transitions API para transiciones fluidas.

#Cuándo elegir Next.js

Next.js es un framework React completo con renderizado avanzado y funcionalidad dinámica.

Mejores casos de uso:

• Tiendas online con carrito dinámico y pasarela de pago (Redsys, Bizum).
• Plataformas con login de usuario y paneles personalizados.
• Aplicaciones SaaS con múltiples vistas y navegación compleja.
• Portales con búsqueda en tiempo real, filtrado avanzado, configuradores y calculadoras.

Ventajas técnicas de Next.js:

• Incremental Static Regeneration (ISR): rendimiento estático con frescura de contenido dinámico.
• Server Actions: eliminan la necesidad de una API separada para operaciones CRUD.
• React Server Components: renderizado en servidor sin mandar JavaScript de más al navegador.
• Edge Middleware: personalización, tests A/B y geolocalización en el borde de la red.

#Desde qué plataformas puedes migrar?

#WordPress a headless

WordPress es, con diferencia, el origen más común. En modo headless, WordPress permanece como backend de gestión de contenido y el nuevo frontend en Astro o Next.js consume los datos vía WPGraphQL o REST API.

Lo que cambia: la capa visual, lo que ve el usuario. Lo que se queda: el panel de administración, así que la redacción sigue trabajando en la interfaz de siempre.

#Joomla y Drupal

Los CMS legacy exigen extracción completa del contenido y una reestructuración. Migramos artículos, categorías y etiquetas conservando la jerarquía, cuentas de usuario, formularios de contacto (reconstruidos sobre React Hook Form) e integraciones de terceros. En la administración pública española y en universidades todavía queda mucho Drupal, y ahí el volumen histórico de URLs es lo más delicado del proyecto.

#Angular, Vue.js y React legacy

Las aplicaciones de frontend sobre frameworks antiguos se migran componente a componente:

• Angular (cualquier versión): migración gradual conservando la lógica de negocio.
• Vue.js / Nuxt.js: transplante de componentes Vue donde ese stack ya encaja con tu backlog.
• React legacy (componentes de clase, Create React App): modernización a Next.js App Router.
• jQuery: sustitución progresiva por interacciones en React.

#Frameworks PHP y generadores estáticos

• Laravel, Symfony, CodeIgniter: reconstrucción API-first conservando la lógica del backend.
• Hugo, Jekyll, Gatsby: migración de estructura de contenido y plantillas.

#Proceso de migración paso a paso

Una migración ordenada corre en paralelo al sitio en producción, sin ni un minuto de caída.

#Fase 1: auditoría y planificación (semana 1)

1. Inventario de contenido: documentación de todas las páginas, entradas, tipos de contenido personalizados y taxonomías.
2. Mapa de URLs: cada dirección antigua asignada a su nuevo destino, incluidas las de /categoria/ y /etiqueta/.
3. Auditoría de funcionalidad: formularios, integraciones con CRM, analítica, pasarelas de pago.
4. Medición base: PageSpeed, Core Web Vitals y posiciones en Google antes de tocar nada.
5. Análisis competitivo: cómo te comparas con el resto del mercado.

#Fase 2: configuración del CMS headless (semanas 1-2)

WordPress u otro CMS se configura para trabajar como API: instalación de WPGraphQL o configuración de la REST API, seguridad del panel de administración oculto tras un firewall, eliminación de plugins de frontend que ya no hacen falta y optimización de los endpoints.

#Fase 3: desarrollo del nuevo frontend (semanas 2-5)

Construcción de la nueva capa visual desde cero: diseño responsive mobile-first, optimización de imágenes (AVIF y WebP con srcsets responsivos), Schema.org generado automáticamente (FAQ, HowTo, Product, Article), Core Web Vitals optimizados desde la primera línea de código y accesibilidad WCAG 2.1 (jerarquía de encabezados, navegación por teclado y contraste).

#Fase 4: migración de contenido y medios (semanas 4-5)

Transferir el contenido es mucho más que copiar texto: conversión de shortcodes en componentes React o Astro, optimización de medios (cada imagen pasa por el pipeline con AVIF, fallback WebP, varias variantes y carga diferida), reescritura de enlaces internos a la nueva estructura de URLs y transferencia de metadata (títulos, descripciones, Open Graph y Twitter Cards).

#Fase 5: pruebas y despliegue (semanas 5-6)

Pruebas de regresión en varios dispositivos y navegadores, verificación SEO (todas las redirecciones 301, meta tags y sitemap), pruebas de rendimiento y de carga, y despliegue blue-green: el nuevo sitio se levanta junto al antiguo y el cambio de DNS tiene rollback instantáneo. Después, monitorización diaria durante 30 días en Search Console.

#Cómo preservar el SEO durante la migración

Es la pregunta crítica para cualquier negocio que se plantee migrar: una migración mal ejecutada puede tirar por la borda años de posicionamiento en Google.

#Mapeo de URLs y redirecciones 301

Cada URL antigua debe tener una redirección 301 a su nuevo destino. Las 301 transfieren la autoridad de enlace a las nuevas direcciones y mantienen las posiciones en buscadores. El detalle que más gente pasa por alto: las páginas de archivo de /categoria/ y /etiqueta/ también reciben tráfico orgánico y también necesitan su redirección.

#Transferencia de datos estructurados Schema.org

Los datos estructurados (JSON-LD) deben transferirse o mejorarse: Article/BlogPosting para artículos, Product con AggregateRating para fichas, FAQPage para preguntas frecuentes (visibles en Google como rich snippets), HowTo para guías paso a paso, BreadcrumbList para las migas de pan y Speakable para búsqueda por voz.

#Monitorización en Search Console tras la migración

Tras el despliegue vigilamos a diario la cobertura de indexación de las nuevas URLs, los errores de rastreo (404, 500 y cadenas de redirección), los Core Web Vitals y las posiciones de las palabras clave.

#Resultados SEO tras la migración

La mayoría de clientes ven mejoras de posiciones en 4-6 semanas. Las razones: mejores Core Web Vitals (señal directa de ranking), HTML más limpio que mejora la rastreabilidad, carga más rápida que reduce el rebote y datos estructurados que generan más rich snippets en la SERP.

#Comparación de rendimiento: WordPress vs headless

#Hosting e infraestructura tras la migración

• Vercel: CDN global, despliegues de previsualización, edge functions, ISR y analítica. La opción natural para Next.js con soporte nativo del App Router.
• Netlify: especializado en sitios estáticos, con distribución global, formularios integrados y funciones serverless. Encaja muy bien con Astro.
• Cloudflare Pages: hosting sobre la CDN más rápida del mundo, con workers, almacenamiento R2 y protección DDoS incluida. Para audiencia española y europea, la baja latencia desde los nodos locales es un argumento de peso.

#Cuánto cuesta la migración?

El coste depende de la complejidad del proyecto:

Cada proyecto se presupuesta de forma individual tras una consulta y auditoría de tu sitio actual.

#Errores habituales de migración y cómo evitarlos

La mayoría de migraciones que salen mal no fallan por la tecnología nueva, sino por descuidos concretos que se repiten proyecto tras proyecto. Estos son los que más caro se pagan.

Un mapa de redirecciones 301 incompleto. Es el error número uno. El equipo redirige la home y las páginas principales, pero se olvida de las URLs de archivo: /categoria/marketing/, /etiqueta/rgpd/, el paginado /blog/page/2/ y las URLs con parámetros. Google llevaba años enviando tráfico a esas direcciones y, de golpe, se encuentran cientos de 404. El resultado es una caída del tráfico orgánico que se arrastra durante semanas hasta que alguien completa el mapa. La regla es simple: exporta todas las URLs indexadas desde Search Console y desde el sitemap antiguo antes de tocar nada, y comprueba que cada una tiene destino.

Datos estructurados que no se transfieren. Una tienda que tenía FAQPage y Product con valoraciones aparecía en Google con estrellas y precio. Tras la migración, el desarrollador reconstruyó el diseño pero olvidó portar el JSON-LD. Los rich snippets desaparecieron de la noche a la mañana y con ellos una parte del CTR, sin que el ranking cambiara ni un puesto. Portar el Schema.org es parte del alcance, no un extra opcional.

Lanzar a la redacción sin plan de transición. Un equipo editorial acostumbrado al editor de bloques de WordPress se topa de repente con un flujo headless o basado en Git y se bloquea. Si el CMS sigue siendo WordPress en modo headless, este problema desaparece porque la interfaz no cambia. Si se cambia a un flujo de trabajo nuevo, hay que formar al equipo y documentar el proceso antes del cambio, no después.

Intentar recrear cada plugin antiguo. Muchos proyectos arrastran veinte plugins de los que la mitad no se usa desde hace años. Migrar es la oportunidad de auditar y abandonar lo que sobra, no de replicarlo pieza a pieza. Un caso concreto y anonimizado: una pyme de servicios profesionales de Valencia llegó con catorce plugins activos. Tras la auditoría se conservaron cinco funciones reales (formulario, analítica, un slider, el aviso de cookies y la conexión con su CRM) y el resto se descartó. El sitio quedó más rápido, más seguro y más barato de mantener precisamente porque no se replicó la deuda técnica.

#Lo que WordPress te daba gratis, y cómo sustituirlo

WordPress resolvía de serie un montón de cosas mediante plugins que, en un stack headless, hay que resolver de forma explícita. No es más trabajo, es trabajo distinto y casi siempre con mejor rendimiento. Este es el mapa de sustituciones.

Formularios. Contact Form 7 o WPForms desaparecen. En su lugar, un formulario en React Hook Form (validación en cliente) conectado a una función serverless, o bien un servicio de formularios como Formspree o Basin si no quieres mantener backend. Para el mercado español, cualquiera de las dos opciones se puede configurar cumpliendo el RGPD: doble opt-in, casilla de consentimiento explícita y aviso de privacidad enlazado. Recuerda añadir un mecanismo antispam como Cloudflare Turnstile.

Buscador interno. WordPress ofrecía búsqueda por defecto contra la base de datos. En un sitio estático, Pagefind indexa el contenido en tiempo de compilación y hace la búsqueda en el navegador sin servidor, ideal para blogs y catálogos. Para sitios grandes o dinámicos, Algolia o Typesense (autoalojable) dan búsqueda instantánea con facetas y tolerancia a errores tipográficos.

Comentarios. El sistema nativo de WordPress se sustituye por un servicio externo como Giscus (sobre GitHub Discussions) o una función serverless propia si quieres moderación a medida y control total del dato personal bajo el RGPD.

Entradas relacionadas y archivos de taxonomía. Lo que antes calculaba un plugin en cada carga ahora se resuelve construyendo un grafo de contenido en tiempo de compilación: las relaciones entre artículos, categorías y etiquetas se calculan una vez al desplegar y se sirven como HTML estático, sin consultas en vivo.

Gestión de medios. La biblioteca de medios de WordPress se sustituye por el pipeline de imágenes de Astro o Next.js: conversión automática a AVIF con fallback WebP, varios tamaños responsivos y carga diferida, todo generado en el build.

Sitemap y RSS. Yoast o Rank Math generaban el sitemap y el feed. En el stack nuevo, ambos se generan de forma programática en cada despliegue a partir del contenido, siempre actualizados y sin plugin que mantener. Recuerda reenviar el sitemap a Search Console tras el primer despliegue para acelerar la reindexación de las URLs nuevas.

#Conclusión: merece la pena la migración?

Migrar a Astro o Next.js es una inversión en el futuro de tu negocio online. Cambias la “deuda técnica” por una solución rápida, segura, escalable y más barata de mantener, mejor preparada además ante las exigencias de rendimiento y de protección de datos del mercado español.

Listo para acelerar? Contáctanos para una consulta gratuita y una auditoría de tu sitio. Descubre nuestros servicios de migración a Next.js y Astro o de rediseño WordPress.

¿Necesitas un especialista para tu proyecto Astro? Descubre mis servicios de desarrollo con Astro.