¿Por qué migrar de WordPress a Next.js en 2026?

Por tres razones operativas. Rendimiento: Next.js sirve estáticamente lo que WordPress reconstruye en cada request, bajando TTFB de 400-1.200 ms a menos de 100 ms en Europa. Mantenimiento: sin plugins que rompan al actualizar ni pantalla blanca por incompatibilidad de extensiones. Seguridad: la superficie de ataque de WordPress es enorme; los stacks headless o basados en archivos estáticos reducen riesgo drásticamente.

¿Voy a perder posicionamiento al migrar?

No si la migración se hace correctamente. Las claves son: mapa de redirects 301 al 100% (cada URL antigua redirige a su nueva equivalente), preservación literal del contenido textual, replicación exacta del sitemap, mantenimiento de URL canónicas y replicación de schema.org. Si todo eso se hace bien, el posicionamiento se conserva o mejora a las 4-8 semanas por la subida de Core Web Vitals. Las pérdidas de tráfico orgánico que vemos en migraciones mal hechas son del 30-70% en las primeras 8 semanas.

¿Cuánto tarda una migración de WordPress a Next.js?

Una web corporativa de 20-50 páginas con blog y 100-300 entradas se migra en 2-5 semanas. Web con multi-idioma, área privada o integraciones complejas: 4-8 semanas. Ecommerce: depende del catálogo y carrito, normalmente 6-12 semanas. El grueso del tiempo no es escribir código sino: auditar URLs, validar el mapa de redirects y replicar literal el contenido y schema.

¿Qué pasa con mi blog, los comentarios y los plugins?

Contenido del blog: se exporta vía WordPress REST API o WP-CLI a archivos MDX/MD que Next.js consume con Velite, Contentlayer o similar. Comentarios anteriores: se pueden migrar a un servicio externo (Disqus, GitHub Discussions, autohospedado tipo Isso) o archivarse como contenido estático; habitualmente archivamos: añaden poco valor SEO y suman complejidad. Plugins: se reemplazan por capacidades nativas (metadata, schema, sitemap son nativos de Next.js) o servicios externos (formularios vía API Route, caché innecesaria porque Next.js sirve estáticamente desde CDN).

¿WooCommerce se puede migrar a Next.js?

Sí, hay tres caminos. Mantener WooCommerce como backend headless: la API WP-REST sirve catálogo y checkout, Next.js renderiza el front. Migrar el catálogo a un ecommerce headless dedicado: Shopify Hydrogen, Medusa o Saleor según volumen y necesidad. Construir un ecommerce a medida si los flujos son específicos (B2B con catálogos por cliente, configuradores complejos, integraciones con ERP). Cada opción tiene trade-offs de coste y flexibilidad: depende del volumen y la complejidad del catálogo.

¿Cuándo conviene migrar vs reconstruir la web desde cero?

Reconstruye desde cero si: el contenido necesita reescritura profunda, la estructura SEO antigua no era buena, el branding ha cambiado, o la web acumula 3+ hallazgos críticos en diagnóstico técnico. Migra preservando si: el contenido posiciona bien, los backlinks valiosos están en URLs concretas que conviene mantener, o el equipo no tiene ancho de banda para reescribir todo. Regla práctica: si el ahorro de tiempo de reescribir es mayor que el coste de perder 4-12 semanas de tráfico mientras Google reindexa, reconstruye. Si no, migra fiel y mejora después.

¿Qué stack europeo usar para la web nueva?

Para mantener datos en Europa y coste predecible: Next.js + Velite (MDX) o headless CMS europeo (Strapi, Payload, Directus). Hosting: Coolify autohospedado en Hetzner (Alemania) u OVHcloud (Francia). CDN: Cloudflare con regiones europeas o Bunny CDN. Analytics: Umami o Plausible autohospedados. Email transaccional: Postmark UE, Mailjet (Francia) o servidor propio Postfix. Cubrimos el mapa completo en la guía de Datos en Europa.

Migrar de WordPress a Next.js sin perder SEO: guía técnica 2026

Migrar de WordPress a Next.js sin perder SEO es posible si haces tres cosas bien: redirects 301 al 100%, preservación literal del contenido textual y replicación exacta del sitemap más el schema.org.
Tiempo realista: 2-5 semanas para web corporativa con blog. 4-8 semanas si hay multi-idioma o área privada. Ecommerce caso a caso.
Lo que ganas: Core Web Vitals 2-4x mejores (TTFB de 400-1.200 ms a < 100 ms en regiones europeas), factura de hosting que baja, sin plugins que rompan en cada actualización.
El error caro: lanzar la nueva web sin un plan de redirects revisado URL por URL. Las pérdidas de tráfico orgánico en migraciones mal hechas son del 30-70% en las primeras 8 semanas.
El plus de 2026: aprovecha la migración para implementar la capa GEO técnica desde el código (llms.txt, whitelist explícita de bots IA, FAQPage schema, Speakable).

Este artículo es el spoke 'cómo ejecutar' del cluster Web/Visibilidad de Ignira. El contexto estratégico de SEO + GEO + AEO está en el pillar SEO, GEO y AEO en 2026. Para diagnosticar antes el estado de tu web actual, Diagnóstico técnico de una web en 2026. Si te planteas también qué stack europeo usar al reconstruir, Datos en Europa: alternativas RGPD a Stripe, AWS y OpenAI en 2026.

Por qué migrar (y por qué no)

Por qué sí

WordPress sigue siendo el CMS más usado del mundo, pero arrastra deuda técnica de 20 años: arquitectura PHP monolítica que reconstruye cada página en cada request, ecosistema de plugins que se actualizan a ritmos descoordinados, base de datos MySQL que se hincha con metadatos.

Una web moderna construida en Next.js + un CMS headless (o MDX en repositorio) se sirve estáticamente desde CDN. Eso significa:

TTFB (Time To First Byte) por debajo de 100 ms en regiones europeas. WordPress típico: 400-1.200 ms.
LCP (Largest Contentful Paint) en el verde de Core Web Vitals (< 2,5s) por defecto, no como objetivo a perseguir.
Factura de hosting muy inferior a la del hosting WordPress decente con caché premium. Servicios como Vercel Hobby, Netlify, Cloudflare Pages o Coolify autohospedado cubren cargas pequeñas y medias muy barato.
Sin plugins que rompan al actualizar el core. Sin pantalla blanca por incompatibilidad de Yoast con Elementor con el nuevo PHP.

Por qué no (o todavía no)

WordPress sigue siendo la mejor opción si:

Tu equipo de marketing publica contenido a diario y no tiene perfil técnico. WordPress con Gutenberg sigue siendo el editor WYSIWYG más maduro.
Tu web depende de un ecosistema de plugins maduro (membresías, calculadoras de seguros, integraciones específicas) que en Next.js habría que reconstruir desde cero.
Tu presupuesto es muy limitado y la web cumple su función actual sin causar problemas.

Si ninguno de estos casos te aplica, una migración a Next.js suele pagar la diferencia en 12-18 meses entre ahorro de hosting, ahorro de mantenimiento reactivo y subida de conversiones por velocidad.

El checklist de migración SEO-segura

Fase 1 · Auditoría previa (antes de tocar nada)

1.1 Inventario completo de URLs publicadas. Exporta del sitemap actual de WordPress (suele estar en /sitemap_index.xml con Yoast o RankMath). Si no tienes sitemap, usa Screaming Frog, Sitebulb o wget --spider para rastrear el sitio. Resultado: lista CSV con todas las URLs que actualmente están en Google.

1.2 Tráfico orgánico por URL. Exporta de Google Search Console los últimos 12 meses, agrupado por página. Identifica el top 50: esas son las URLs cuyo posicionamiento NO puedes romper.

1.3 Backlinks por URL. Si tienes Ahrefs, Semrush o Majestic, exporta los backlinks por URL destino. Estas son las URLs que SÍ o SÍ deben mantener su URL final o tener redirect 301 perfecto.

1.4 Schema.org actual. Inspecciona con Schema Markup Validator o curl + grep qué schemas tienes en producción (Organization, BreadcrumbList, FAQPage, Article, LocalBusiness, Service+Offer). Toca replicarlos en la nueva web.

1.5 Sistema de URLs. WordPress por defecto usa /?p=123, pero la mayoría de webs reales usan /categoria/slug-de-la-entrada/. Documenta el patrón. Si en algún momento hubo cambios de permalinks, busca redirects antiguos que también haya que mantener.

Fase 2 · Reconstrucción en Next.js

2.1 Decisión de fuente de contenido. Tres caminos habituales:

MDX en repositorio: el contenido vive como archivos .mdx en Git, gestionado por Velite, Contentlayer o similar. Excelente para blogs técnicos y webs corporativas con publicación moderada. Es lo que usamos en este sitio.
CMS headless: Sanity, Strapi, Payload, Directus. El equipo de marketing edita en una UI, Next.js consume vía API. Mejor para equipos no técnicos con publicación frecuente.
WordPress headless: mantienes WordPress como backend y Next.js como front. Buen punto medio si tu equipo ya domina WordPress y solo quieres el front moderno.

2.2 Replicación literal del contenido. Esto suele saltarse y es donde se pierde SEO. El texto publicado se migra letra a letra: títulos H1/H2/H3, párrafos, texto alternativo (alt) de las imágenes, anclas internas. Reescribir contenido "ya que estamos" es introducir una variable adicional cuando Google reindexe: verá una página distinta y tendrá que reevaluarla.

Política sana: primero migra fiel, despliega, espera 4-6 semanas a que Google reindexe sin cambios. Después, mejora.

2.3 Estructura de URLs. Mantén las mismas URLs siempre que sea posible. Si la web vieja tenía /servicios/diseno-web/, la nueva también. Cambiar la estructura sin razón es la principal causa de pérdidas SEO en migraciones.

Si decides cambiar URLs (porque la estructura antigua era horrible o por redirects acumulados de tiempos pasados), prepara un mapa CSV url_antigua,url_nueva,tipo_redirect. Todos deben ser 301 (permanent), no 302 (temporary).

2.4 Metadata y schema.org. Por cada página replica:

<title>: idealmente el mismo texto que en la web antigua. Si era un desastre, mejorar es aceptable pero documenta el cambio.
<meta name="description">: igual.
<link rel="canonical">: apunta a la URL canónica de la nueva web.
<meta property="og:*"> (Open Graph): título, descripción, imagen 1200x630.
schema.org: Organization en home + LocalBusiness si aplica, BreadcrumbList en todas, Article en blog, FAQPage donde haya preguntas, Service+Offer en fichas. Servir como <script type="application/ld+json">.

En 2026 conviene además generar llms.txt y los schemas pensados para GEO/AEO: coste adicional bajo, ganancia potencial en visibilidad en LLMs.

2.5 Sitemap.xml y robots.txt.

Sitemap: genéralo dinámicamente desde el código (Next.js tiene sitemap.ts nativo). Incluye todas las URLs públicas con lastModified, changeFrequency y priority.
Robots.txt: replica el del WordPress antiguo si era correcto. Aprovecha para añadir whitelist explícita de bots IA permitidos (GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-SearchBot, Claude-User, PerplexityBot, Google-Extended, Applebot-Extended).

Fase 3 · Redirects 301 (la fase crítica)

El mapa de redirects es la pieza más importante. Si fallas aquí, pierdes SEO sí o sí.

3.1 Crea el mapa. CSV con dos columnas. Ejemplo de patrones habituales en migraciones reales:

/blog/2019/seo-tecnico-2019/, /articulos/seo-tecnico-historico/
/category/web-design/, /articulos?categoria=web
/index.php?p=42, /casos/cliente-anonimo/
/?author=1, /equipo/

(Si tu WordPress tenía permalinks heredados con parámetros de query, mapea cada patrón a su nueva URL. Las URLs ?p=ID son las más olvidadas y siguen indexadas en Google años después.)

3.2 Implementa los redirects. En Next.js, edita next.config.ts con la función redirects():

async redirects() {
  return [
    {
      source: "/blog/2019/seo-tecnico-2019/",
      destination: "/articulos/seo-tecnico-historico/",
      permanent: true,
    },
    // ... resto del mapa
  ];
}

Si tu mapa tiene cientos de redirects con patrones, usa wildcards y captures (/recursos/:slug → /articulos/:slug).

3.3 Valida antes de lanzar. Antes de cambiar DNS, valida con un script que cada URL antigua devuelva 301 con destino correcto:

while read line; do
  url=$(echo $line | cut -d',' -f1)
  expected=$(echo $line | cut -d',' -f2)
  actual=$(curl -sI -o /dev/null -w "%{http_code} %{redirect_url}" "https://nueva.tuweb.com${url}")
  echo "$url -> $actual (expected $expected)"
done < redirects.csv

Cada línea debe responder 301 https://tuweb.com/url-nueva.

Fase 4 · Lanzamiento controlado

4.1 Pre-lanzamiento.

Web nueva accesible en subdominio nueva.tuweb.com con noindex por ahora.
WordPress antiguo intacto en tuweb.com.
Mapa de redirects validado.
Google Search Console preparado para la web nueva.

4.2 Lanzamiento.

Quita noindex del nuevo sitio.
Cambia el DNS de tuweb.com para apuntar a la nueva infraestructura. (Si usas Cloudflare, es cuestión de segundos.)
La web antigua queda fuera de servicio o redirigida globalmente.
Comprueba que los redirects funcionan inmediatamente.

4.3 Notifica a Google.

Envía el nuevo sitemap en Google Search Console.
"Change of Address" (cambio de dirección) si cambias de dominio. No aplica si es el mismo dominio.
Solicita reindexación de las URLs críticas (las 20 con más tráfico).

Fase 5 · Monitorización post-lanzamiento (4-8 semanas)

5.1 Search Console diariamente la primera semana.

Errores de cobertura.
Páginas excluidas.
404 inesperados: si aparecen, añade redirects en caliente.

5.2 Análisis de logs de servidor. Si tienes acceso a logs, busca peticiones 404 reales. Cualquier 404 con tráfico significativo es un redirect que se te escapó.

5.3 Análisis de tráfico orgánico. Es normal una caída del 5-15% las primeras 2-4 semanas mientras Google reindexa. Si la caída excede el 20% a las 4 semanas, hay algo mal: vuelve al mapa de redirects, revisa metadata y schema.

A las 8-12 semanas el tráfico orgánico debería estar igual o mejor que antes. Si tu web ganó velocidad significativa, normalmente mejora un 5-15% por subida en posiciones que dependen de Core Web Vitals.

Errores caros que vemos en migraciones de WordPress a Next.js

Error 1 · Cambiar URLs sin necesidad

"Aprovechamos para limpiar la estructura". Resultado: 300 redirects 301 mal mapeados, pérdida del 40% del tráfico, 6 meses para recuperar. Solución: mantén URLs idénticas en la primera versión. Si la estructura antigua es horrible, redirige selectivamente solo lo que sume.

Error 2 · Reescribir el contenido durante la migración

"Ya que reescribimos la web, mejoramos los textos". Google ve páginas distintas y tiene que reevaluarlas. Aunque los textos nuevos sean mejores, hay 4-12 semanas de inestabilidad. Solución: primero migra literal, deja que Google reindexe, después optimiza.

Error 3 · Olvidar redirects de URLs muertas

WordPress acumula URLs viejas (categorías, etiquetas, autores, archivos por fecha). Algunas tienen backlinks olvidados de hace años. Si las dejas en 404, pierdes la autoridad de enlace que esos backlinks aportaban. Solución: redirige a la categoría o sección equivalente, no a la home.

Error 4 · Sitemap mal generado

Sitemap nuevo que incluye URLs noindex o que excluye URLs publicadas. Google se confunde, indexación caótica. Solución: genera el sitemap programáticamente desde la fuente de contenido. Nunca a mano.

Error 5 · Schema.org perdido en la migración

WordPress con Yoast o RankMath genera schema automáticamente. Si la web nueva no lo replica, pierdes rich snippets en SERP. Y especialmente en 2026, pierdes presencia en asistentes IA que se apoyan en schema para entender el contenido. Solución: documenta los schemas activos antes de migrar y replícalos en la web nueva con JSON-LD nativo (Next.js Metadata API o <script type="application/ld+json"> server-side).

Error 6 · Migrar sin pasar antes el diagnóstico

Empezar la migración sin saber qué tienes hoy es construir sobre arena. Pasa primero el diagnóstico técnico de las 5 capas sobre tu web actual y guárdalo: te servirá como baseline para medir antes/después y como inventario de schemas a replicar.

Para empezar

Si tu WordPress va lento, se rompe cada 6 semanas o no se puede tocar sin pedir presupuesto, una migración a Next.js suele pagar la inversión en 12-18 meses. Cubrimos el caso completo en el servicio de migración / rescate de web, con un plan validado URL por URL antes de tocar nada.

Antes de comprometerte, diagnostica el estado actual en 30 segundos o reserva una llamada de 15 minutos. Si tu caso encaja, propuesta cerrada en 48 horas con plazo y precio fijo.