Migrar de WordPress a Next.js sin perder SEO (2026)

Migrar de WordPress a Next.js es una de esas decisiones que se presentan como un salto técnico cuando en realidad es, sobre todo, una decisión de negocio con consecuencias en posicionamiento, velocidad, seguridad y coste de mantenimiento. Y como toda decisión importante, está rodeada de mitos en las dos direcciones: el que dice que migrar siempre destroza el SEO, y el que vende Next.js como una bala de plata que arregla problemas que en realidad son de contenido o de estrategia.

Esta guía es para la persona que se está planteando la migración en serio: el responsable de marketing que ve que su WordPress carga lento y suspende Core Web Vitals, el director de una pyme cansado de ataques y actualizaciones de plugins, o el equipo técnico que necesita justificar la inversión con datos y un plan que no ponga en riesgo el tráfico orgánico que ya tienen.

La respuesta corta, antes de las 7.000 palabras que siguen: migrar de WordPress a Next.js no hace perder posiciones si se hace con mapeo 1:1 de URLs y redirecciones 301, se replican íntegros el contenido, los metadatos y los datos estructurados, y se monitoriza la indexación las semanas posteriores. La pérdida de rankings en una migración nunca viene de Next.js, viene de saltarse pasos del checklist. El resto del artículo es para que sepas exactamente cuándo migrar, cuándo no, qué pasos seguir y qué coste y plazo esperar.

Si te interesa el contexto más amplio de tecnología y rendimiento web, este artículo encaja con nuestra guía de automatización con IA y n8n para empresas y con la guía completa de SEO y GEO para empresas en España.

Qué es Next.js y en qué se diferencia de WordPress

Next.js es un framework de desarrollo web construido sobre React que genera las páginas como HTML estático o renderizado en servidor, para servirlas casi instantáneamente desde una red de distribución de contenido (CDN). WordPress, en cambio, es un gestor de contenido en PHP que, salvo que añadas capas de caché, construye cada página en el momento de la visita consultando una base de datos MySQL.

La diferencia parece técnica pero tiene consecuencias directas en lo que mide Google y en lo que percibe el usuario. Un WordPress típico de empresa con una plantilla comercial y diez o quince plugins activos ejecuta PHP, consulta la base de datos varias veces, carga hojas de estilo y scripts de cada plugin, y entrega la página tras un proceso que rara vez baja de los 2-3 segundos sin optimización seria. Una página equivalente en Next.js, generada como estática y servida desde CDN, llega al navegador en una fracción de ese tiempo porque ya está construida.

No significa que WordPress sea malo. WordPress mueve una parte enorme de la web mundial y para muchísimos proyectos es la elección correcta: rápido de poner en marcha, con un ecosistema gigantesco y editable por cualquiera sin perfil técnico. Next.js gana cuando el rendimiento, la seguridad y el control fino sobre el código pasan a ser prioridades de negocio, y cuando el coste de mantener WordPress bien protegido y rápido supera al de operar una arquitectura moderna.

La decisión correcta no es "Next.js es mejor que WordPress". Es "para este proyecto, con estos objetivos y este equipo, ¿qué arquitectura tiene más sentido a tres años vista?".

Por qué migrar de WordPress a Next.js: las cuatro razones reales

Las empresas migran de WordPress a Next.js por cuatro motivos concretos, casi siempre por una combinación de ellos. Conviene separarlos porque cada uno justifica la migración de forma distinta, y porque algunos se pueden resolver sin migrar.

Razón 1: rendimiento y Core Web Vitals

El rendimiento es el motivo número uno, y el que tiene impacto SEO más directo. Google usa los Core Web Vitals como señal de posicionamiento desde 2021, y son tres métricas concretas que conviene conocer por su nombre porque van a aparecer en cualquier auditoría.

LCP (Largest Contentful Paint) mide cuánto tarda en mostrarse el elemento más grande de la página (normalmente la imagen del hero o el bloque de texto principal). El umbral "bueno" de Google es 2,5 segundos o menos. INP (Interaction to Next Paint), que sustituyó a FID en marzo de 2024, mide la latencia de respuesta a las interacciones del usuario; el umbral bueno es 200 milisegundos o menos. CLS (Cumulative Layout Shift) mide la estabilidad visual, es decir, cuánto se mueve el contenido mientras carga; el umbral bueno es 0,1 o menos.

Un WordPress con plantilla comercial y plugins suele suspender al menos uno de los tres, normalmente LCP por el peso de scripts y estilos, y CLS por fuentes web y bloques que reposicionan el contenido. Next.js aborda los tres por diseño: optimización automática de imágenes, división del JavaScript en fragmentos que solo se cargan cuando hacen falta, carga de fuentes optimizada y renderizado que entrega contenido estable desde el primer momento. En proyectos reales, pasar de un WordPress sin optimizar a Next.js suele llevar el LCP de la franja de 3-5 segundos a la de 1-1,5 segundos. Son cifras orientativas, dependen de cada proyecto, pero el orden de magnitud es ese.

Razón 2: seguridad

WordPress es el CMS más usado del mundo y, por eso mismo, el más atacado. La superficie de ataque la abren sobre todo los plugins y plantillas de terceros con vulnerabilidades, las versiones desactualizadas y el panel de administración expuesto. Cualquiera que haya gestionado varios WordPress conoce la rutina: actualizaciones constantes, intentos de acceso por fuerza bruta a la pantalla de login, plugins de seguridad, copias de respaldo y el miedo permanente a que una actualización rompa algo o a que un plugin abandonado se convierta en una puerta de entrada.

Next.js generado como estático reduce drásticamente esa superficie. No hay base de datos expuesta en cada visita, no hay panel de administración público que defender, no hay un ecosistema de plugins de terceros ejecutando código en tu servidor. Si el contenido vive en archivos del repositorio o detrás de un CMS headless aislado, la web pública es un conjunto de archivos estáticos: hay muy poco que atacar. Para sectores sensibles (legal, salud, financiero) o para empresas que han sufrido incidentes, este es a menudo el argumento decisivo.

Razón 3: control técnico y experiencia de usuario

Con WordPress estás dentro de las posibilidades de tu plantilla y tus plugins. Salir de ahí (una animación concreta, una interacción a medida, una integración no estándar) suele significar pelearse con código que la plantilla no previó, o acumular más plugins. Con Next.js controlas cada línea de lo que se renderiza y cada byte de JavaScript que se envía al navegador. Para una marca que quiere una experiencia diferenciada (transiciones cuidadas, componentes interactivos, un diseño que no se parezca a una plantilla más), Next.js da libertad total.

Esto enlaza con un punto de diseño que importa: una web en Next.js bien construida puede parecer producto internacional de primera, no plantilla. El control sobre la interfaz es la base de eso.

Razón 4: coste de mantenimiento a largo plazo

A primera vista WordPress parece más barato porque el arranque es casi gratis. Pero el coste real de WordPress está en el mantenimiento continuo: actualizaciones de núcleo, plugins y plantilla; resolución de incompatibilidades; gestión de seguridad; copias de respaldo; y un hosting que, para que vaya rápido, tiene que ser bueno (alojamiento gestionado WordPress, no el plan compartido barato). Next.js estático se aloja por muy poco (a veces gratis en planes de entrada de plataformas de hosting estático, o por un coste mínimo en infraestructura propia), no necesita actualizaciones de seguridad constantes y tiene mucho menos que mantener. A tres años, la ecuación de coste total suele inclinarse hacia Next.js para proyectos que se mantienen activos.

Cuándo NO migrar de WordPress a Next.js

Migrar no siempre es la decisión correcta, y un consultor honesto te lo dice antes de cobrarte una migración. Hay escenarios claros donde WordPress es la opción sensata y la migración añade riesgo y coste sin retorno proporcional.

No migres si tu equipo edita contenido a diario sin perfil técnico y no quieres mantener WordPress headless. Si tu mayor activo es que cualquier persona del equipo publica, edita y reorganiza contenido en el panel de WordPress sin depender de nadie, perder eso a cambio de velocidad puede no compensar. La solución intermedia existe (WordPress headless o un CMS con buena interfaz), pero hay que quererla y presupuestarla.

No migres si dependes de un ecosistema de plugins muy específico y difícil de reproducir. Hay sectores y casos de uso construidos enteramente sobre plugins concretos (sistemas de membresía complejos, configuradores de producto muy específicos, integraciones de nicho). Reproducir todo eso en Next.js puede ser un proyecto enorme. Audita primero qué hace cada plugin crítico y si tiene equivalente razonable.

No migres si el sitio es pequeño, rinde bien y no tiene problemas. Si tu WordPress carga rápido, aprueba Core Web Vitals, no ha tenido incidentes de seguridad y cumple su función, migrar es resolver un problema que no tienes. Optimiza lo que haya que optimizar y dedica el presupuesto a algo con más retorno.

No migres si no hay presupuesto para hacerlo bien. Una migración a medias (sin plan de redirecciones completo, sin replicar schema, sin monitorización post-lanzamiento) es activamente peor que no migrar, porque puedes perder tráfico orgánico que costó años construir. Si el presupuesto solo da para una migración apresurada, espera a tenerlo.

La regla práctica: migra cuando el rendimiento, la seguridad o el control técnico son problemas reales de negocio con coste medible, y cuando hay presupuesto para hacer la migración con todos los pasos. Si no se cumplen ambas condiciones, optimiza WordPress primero.

WordPress vs Next.js: tabla comparativa

Criterio	WordPress	Next.js
Rendimiento por defecto	Medio; requiere caché y optimización	Alto; estático o SSR desde CDN
LCP típico (sin optimizar / optimizado)	3-5 s / 1,5-2,5 s	0,8-1,5 s
Core Web Vitals	Aprobables con trabajo continuo	Aprobables por diseño
Seguridad	Superficie amplia (plugins, panel, BD)	Superficie mínima si es estático
Edición de contenido no técnica	Excelente (panel nativo)	Requiere CMS headless o Markdown
Ecosistema de plugins	Enorme	No aplica; se sustituye por código/servicios
Coste de mantenimiento a 3 años	Alto (actualizaciones, seguridad, hosting)	Bajo (poco que mantener)
Coste de arranque	Bajo	Medio-alto (desarrollo a medida)
Control del código y la UX	Limitado por plantilla/plugins	Total
Hosting	Gestionado de pago	Estático barato o gratis en plan de entrada
Curva para el equipo editor	Mínima	Depende del CMS elegido
SEO técnico base	Bueno con plugins (Yoast, RankMath)	Excelente con metadatos nativos

La tabla deja claro el patrón: WordPress gana en facilidad de edición y arranque; Next.js gana en rendimiento, seguridad, control y coste a largo plazo. La decisión correcta depende de cuál de esos ejes pesa más en tu caso concreto.

Cómo afecta la migración al SEO: la verdad sin mitos

La migración afecta al SEO solo a través de lo que cambia en cómo Google ve y rastrea tu sitio, y todo eso es controlable. Vamos a desmontar el mito de raíz: Google no penaliza por usar Next.js en lugar de WordPress. Google rastrea HTML, no le importa qué tecnología lo generó. Lo que importa es que el HTML que recibe el rastreador sea equivalente, que las URLs se mantengan o se redirijan correctamente, y que las señales (contenido, metadatos, datos estructurados, enlaces) se conserven.

Las pérdidas de tráfico en migraciones son reales pero siempre tienen causa identificable, y casi siempre es una de estas:

URLs que cambian sin redirección. Es la causa número uno. Si /servicios/consultoria pasa a ser /que-hacemos/consultoria sin una 301 de la antigua a la nueva, Google pierde la URL antigua (que tenía posicionamiento y enlaces) y la nueva empieza desde cero. Cada URL con tráfico o enlaces que cambia sin 301 es tráfico perdido.

Contenido que no se replica al detalle. Si en la migración se "limpia" o se acorta el contenido, o se pierden secciones, encabezados o párrafos, cambia la relevancia de la página para las consultas que la traían. La regla en una migración pura es replicar el contenido exacto; las mejoras de contenido se hacen después, cuando el sitio ya está estable.

Metadatos y datos estructurados que se olvidan. El title, la meta description y, sobre todo, el schema (datos estructurados JSON-LD) son señales que hay que replicar página a página. Una migración que no se ocupa del schema de cada tipo de página (artículo, producto, organización, FAQ, breadcrumb) pierde rich results y contexto para los rastreadores.

robots.txt y noindex heredados del entorno de pruebas. El error clásico y catastrófico: el sitio se desarrolla en staging con Disallow: / o con etiquetas noindex para que Google no lo rastree mientras se construye, y se lanza a producción sin quitarlos. El sitio nuevo queda bloqueado al rastreo y desaparece de Google en días. Hay que verificar esto el día del lanzamiento, sin excepción.

Sitemap no actualizado ni reenviado. Tras la migración hay que generar el nuevo sitemap XML, asegurarse de que lista las URLs correctas y enviarlo a Google Search Console para acelerar el redescubrimiento.

Ninguna de estas causas tiene que ver con Next.js. Todas son fallos de proceso, y todas se evitan con un checklist disciplinado. Una migración bien hecha no solo conserva el SEO: como mejora drásticamente los Core Web Vitals, suele traducirse en una mejora de posiciones una vez que Google ha rastreado y consolidado el sitio nuevo.

Checklist completo de migración de WordPress a Next.js

El checklist es el corazón de una migración que no pierde SEO. Recórrelo por fases, y no lances a producción hasta que cada elemento de las fases anteriores esté verificado.

Fase 1: auditoría e inventario del sitio actual

Antes de tocar nada, hay que conocer al detalle lo que se va a migrar. Esta fase produce los documentos que guían todo lo demás.

• Inventario completo de URLs. Exporta todas las URLs indexadas del sitio actual. Fuentes: el sitemap XML de WordPress, el informe de cobertura de Google Search Console, un rastreo con una herramienta tipo Screaming Frog, y las páginas con tráfico de Google Analytics. El objetivo es no dejarse ni una URL que tenga tráfico, enlaces entrantes o valor.
• Inventario de contenido. Cada página, entrada, categoría, etiqueta y archivo. Qué se migra, qué se consolida y qué se elimina (con su 301 a un destino relevante).
• Inventario de metadatos. Title y meta description de cada URL, normalmente desde la exportación de Yoast o RankMath.
• Inventario de datos estructurados. Qué schema tiene hoy cada tipo de página (Article, Product, Organization, LocalBusiness, FAQ, BreadcrumbList). Hay que replicarlo.
• Inventario de enlaces entrantes. Las páginas con más enlaces externos son las más sensibles: su 301 es prioritaria.
• Auditoría de funcionalidad de plugins. Lista de cada plugin y qué función cumple, para decidir su sustituto en Next.js: SEO, formularios, ecommerce, caché, seguridad, multiidioma, etc.
• Baseline de métricas. Captura el estado de partida: posiciones de las keywords principales, tráfico orgánico, Core Web Vitals, número de URLs indexadas. Sin baseline no puedes saber si la migración fue bien.

Fase 2: arquitectura y decisiones técnicas

• Modelo de contenido. Decide dónde vivirá el contenido: WordPress headless (mantienes el panel y Next.js consume su API), un headless CMS moderno (Sanity, Strapi, Contentful), o archivos Markdown/MDX en el repositorio. La decisión depende de quién edita y con qué frecuencia.
• Estrategia de renderizado. Estático (SSG) para el grueso de páginas que no cambian a cada minuto; renderizado en servidor (SSR) o regeneración incremental (ISR) para lo que necesita datos frescos. La mayoría de las webs corporativas son casi enteramente estáticas.
• Estrategia de URLs. La decisión más importante para el SEO. Por defecto: conservar exactamente la misma estructura de URLs que tenías. Solo se cambian URLs si hay una razón sólida, y siempre con 301.
• Hosting y dominio. Dónde se aloja el nuevo sitio y cómo se hará el cambio de DNS el día del lanzamiento.

Fase 3: desarrollo y migración de contenido

• Maquetación de plantillas. Construir las plantillas de cada tipo de página (home, página de servicio, entrada de blog, categoría, página legal) replicando estructura y contenido.
• Migración del contenido. Exportar el contenido e importarlo al nuevo sistema, conservando encabezados, formato, enlaces internos e imágenes.
• Migración de imágenes y medios. Trasladar la biblioteca de medios, idealmente con optimización (formatos modernos como WebP/AVIF, tamaños responsivos). Conservar los textos alternativos (alt) por SEO y accesibilidad.
• Metadatos página a página. Implementar title y meta description de cada URL con los metadatos nativos de Next.js, replicando los del inventario.
• Datos estructurados. Implementar el JSON-LD de cada tipo de página según el inventario de schema.
• Enlaces internos. Verificar que todos los enlaces internos apuntan a las URLs correctas del nuevo sitio.

Fase 4: plan de redirecciones 301

• Mapa de redirecciones. Una tabla con cada URL antigua y su destino en el sitio nuevo. Para una migración 1:1, la mayoría son idénticas; para las que cambian, una 301 explícita.
• Implementación de las 301. Configurar las redirecciones permanentes en Next.js (en su archivo de configuración) o a nivel de servidor/CDN, según la infraestructura.
• Cadenas y bucles. Evitar redirecciones encadenadas (A→B→C) y bucles. Cada URL antigua debe ir directa a su destino final.
• URLs con parámetros y mayúsculas. Contemplar variantes con barra final, parámetros de seguimiento y diferencias de mayúsculas que el sitio antiguo resolvía.

Fase 5: SEO técnico del sitio nuevo

• sitemap.xml. Generar el nuevo sitemap con las URLs correctas y prepararlo para enviarlo a Search Console.
• robots.txt. Verificar tres veces que el robots.txt de producción permite el rastreo y no arrastra el Disallow: / de staging.
• Etiquetas canónicas. Cada página con su canonical correcto y autorreferencial.
• Verificar ausencia de noindex accidental. Ninguna página que deba indexarse puede llevar noindex heredado del entorno de pruebas.
• Hreflang si el sitio es multiidioma, replicando la configuración de idiomas y regiones.
• 404 personalizada que devuelva código 404 real y ayude a navegar.

Fase 6: pruebas en staging

• Comparación de contenido entre el sitio antiguo y el nuevo, página por página de las más importantes.
• Validación de redirecciones con una herramienta que compruebe que cada URL antigua devuelve 301 a su destino correcto.
• Validación de schema con la herramienta de pruebas de resultados enriquecidos de Google.
• Core Web Vitals medidos en staging para confirmar la mejora esperada.
• Pruebas en móvil de toda la navegación, formularios y elementos interactivos.
• Revisión de formularios y de cualquier funcionalidad que antes daba un plugin.

Fase 7: lanzamiento

• Cambio de DNS apuntando el dominio al nuevo hosting.
• Verificación inmediata de robots.txt, sitemap, una muestra de redirecciones 301 y que las páginas principales devuelven 200 y se ven correctas.
• Envío del sitemap a Google Search Console para acelerar el redescubrimiento.
• Comprobar Search Console de que la propiedad y la verificación siguen activas.

Fase 8: monitorización post-lanzamiento

• Cobertura e indexación en Search Console, a diario las primeras semanas, vigilando errores 404 y URLs excluidas.
• Posiciones de keywords comparadas con el baseline, esperando cierta volatilidad temporal mientras Google reconsolida.
• Errores 404 reales en los logs o en Search Console, para añadir las 301 que se hayan escapado.
• Core Web Vitals en datos de campo, que tardan unas semanas en reflejar la mejora.
• Tráfico orgánico comparado con el baseline, sabiendo que lo normal es una pequeña caída inicial seguida de recuperación y, a menudo, mejora.

Riesgos de la migración y cómo mitigarlos

Los riesgos de una migración de WordPress a Next.js son operativos y todos tienen mitigación conocida. La tabla resume los principales por probabilidad e impacto.

Riesgo	Impacto	Probabilidad si no se controla	Mitigación
URLs cambiadas sin 301	Pérdida de tráfico y enlaces	Alta	Mapa de redirecciones completo y verificado
robots.txt o noindex de staging en producción	Desindexación total	Media	Verificación obligatoria el día del lanzamiento
Contenido no replicado al detalle	Pérdida de relevancia	Media	Comparación página a página en staging
Schema no migrado	Pérdida de rich results	Alta	Inventario y replicación de JSON-LD
Sitemap no enviado	Redescubrimiento lento	Media	Envío a Search Console en el lanzamiento
Funcionalidad de plugin sin sustituto	Pérdida de función	Media	Auditoría de plugins en fase 1
Cambio de DNS mal coordinado	Caída temporal del sitio	Baja	Reducir TTL antes; lanzar en horario de bajo tráfico
Equipo editor sin formación en el CMS nuevo	Bloqueo operativo	Media	Elegir CMS adecuado y formar al equipo

La mitigación común a casi todos los riesgos es la misma: una fase de pruebas en staging seria antes de tocar el DNS, y un checklist que nadie se salta por prisa. Las migraciones que pierden tráfico son, casi sin excepción, las que se lanzaron con prisa y sin verificar.

Plazos realistas de una migración

El plazo de una migración lo determinan el volumen de contenido, el número de redirecciones y la complejidad de las integraciones, no la velocidad de escribir código. Estos son los plazos que conviene esperar.

Web corporativa pequeña (10-30 páginas, sin blog o con blog pequeño, contenido estático): 3-5 semanas desde la auditoría hasta el lanzamiento. La mayor parte del tiempo va a maquetación de plantillas y verificación, no a migración de contenido.

Web con blog amplio (50-200 entradas, mapeo de URLs, varias categorías): 6-10 semanas. El blog añade trabajo de migración de contenido, replicación de metadatos por entrada y un plan de redirecciones más extenso.

Sitio grande o ecommerce (cientos o miles de URLs, headless CMS, integraciones a medida, catálogo de producto): 3-5 meses. La complejidad está en las integraciones (pasarela de pago, gestión de stock, CRM), el volumen de URLs a mapear y las pruebas exhaustivas que un ecommerce exige antes de lanzar.

Sobre cualquiera de estas estimaciones, reserva un 20-30 % de margen para imprevistos: documentación de API incompleta, funcionalidades de plugin más complejas de lo previsto, o limpieza de contenido y datos heredados. Los proyectos planificados sin margen son los que generan estrés y atajos cuando aparece el primer imprevisto, y los atajos en una migración se pagan en tráfico.

Coste orientativo de migrar de WordPress a Next.js en España

El coste de una migración depende del volumen de contenido, el número de redirecciones, el modelo de CMS elegido y la complejidad de las integraciones. Con esa advertencia, estos son los rangos orientativos que se manejan en el mercado español para proyectos hechos con todos los pasos del checklist.

Tipo de proyecto	Rango orientativo (setup)	Incluye
Web corporativa pequeña (10-30 páginas)	3.000-6.000 €	Auditoría, plantillas, migración de contenido, 301, verificación
Web con blog (50-200 entradas)	6.000-12.000 €	Lo anterior + migración de blog, mapeo de URLs, metadatos por entrada
Sitio grande / ecommerce	Desde 15.000 €	Headless CMS, integraciones, catálogo, pruebas exhaustivas
Migración con CMS headless conservando el panel	4.000-9.000 €	Front en Next.js consumiendo la API del CMS existente
Solo plan de redirecciones (proyecto aparte)	600-2.000 €	Inventario de URLs y mapa de 301 (si lo desarrolla otro equipo)

A esto hay que sumar el hosting, que en Next.js suele ser más barato que un alojamiento gestionado equivalente: un sitio estático se aloja desde gratis en planes de entrada de plataformas de hosting estático, o por un coste mínimo en infraestructura propia. Frente a un alojamiento gestionado de calidad (que para una empresa con tráfico ronda los 25-100 €/mes), el ahorro recurrente es real.

Regla práctica para presupuestar: desconfía de cualquier presupuesto de migración que no incluya explícitamente, como partidas separadas, la auditoría e inventario de URLs, el plan de redirecciones 301 y la verificación post-lanzamiento. Si esos tres elementos no aparecen, te están presupuestando un rediseño, no una migración con SEO preservado, y la diferencia te puede costar el tráfico orgánico de años. Una migración sin plan de redirecciones no es más barata: es más cara, porque la pagas en clientes perdidos.

Cómo preservar los rankings durante la migración: los cinco controles innegociables

Preservar los rankings durante una migración se reduce a cinco controles que no admiten excepción. Si los cinco están cubiertos, el riesgo de pérdida de posiciones es bajo; si falta uno, el riesgo es alto por mucho que el resto esté perfecto.

Control 1: mapeo 1:1 de URLs con 301. Cada URL antigua tiene un destino definido en el sitio nuevo. Si la URL se mantiene, perfecto; si cambia, una redirección 301 permanente de la antigua a la nueva. Sin cadenas, sin bucles, sin 302 (temporal) donde debe haber 301 (permanente). Este control es el que más tráfico salva.

Control 2: replicación exacta de señales on-page. Title, meta description, encabezados (H1-H6) y el cuerpo del contenido se replican sin "mejoras" durante la migración. La página nueva debe ser, para Google, la misma página en una tecnología distinta. Las mejoras de contenido se hacen después, sobre el sitio ya estable, y de una en una para poder medir su efecto.

Control 3: datos estructurados completos. El schema JSON-LD de cada tipo de página se replica íntegro. Es lo que alimenta los resultados enriquecidos y da contexto a los rastreadores y a los motores de IA. Perderlo es perder visibilidad y, cada vez más, citabilidad en respuestas generadas por IA.

Control 4: rastreo e indexación habilitados desde el minuto uno. robots.txt de producción correcto, sin noindex heredado, sitemap nuevo generado y enviado a Search Console el día del lanzamiento. Este control es el que evita el desastre de la desindexación total.

Control 5: monitorización activa cuatro a seis semanas. Tras el lanzamiento, vigilancia diaria de cobertura, indexación, errores 404 y posiciones. Es normal una pequeña volatilidad mientras Google reconsolida; lo que no es normal es una caída sostenida, y si aparece hay que diagnosticarla y corregirla rápido. La mayoría de las migraciones que "perdieron SEO" en realidad tuvieron un error corregible que nadie detectó a tiempo por falta de monitorización.

Estos cinco controles son la diferencia entre una migración que conserva (y suele mejorar) el posicionamiento y una que lo pone en riesgo. No son negociables ni recortables por presupuesto: son el presupuesto.

El camino intermedio que muchas empresas pasan por alto: CMS headless

Un CMS headless permite quedarse con un panel de edición cómodo y a la vez tener un front moderno en Next.js, y es la opción correcta para muchas empresas que descartan migrar por miedo a perder la facilidad de edición. La idea es simple: el gestor de contenido deja de generar las páginas públicas y pasa a ser solo un almacén de contenido al que Next.js accede a través de su API (REST o GraphQL). El equipo sigue editando como siempre; los visitantes reciben páginas rápidas servidas por Next.js.

Si quieres conservar exactamente el panel de WordPress que ya conoces, WordPress puede operarse en modo headless: edita en WordPress, sirve con Next.js. Si prefieres una interfaz de edición más moderna, hay gestores pensados para esto desde el principio (Sanity, Strapi, Contentful, Payload).

Las ventajas son evidentes: conservas el flujo de trabajo editorial que tu equipo ya conoce, ganas el rendimiento y la seguridad del front estático, y separas el panel de administración (que puedes proteger y aislar) de la web pública. Es especialmente buena opción para medios, blogs corporativos activos y empresas con un equipo de marketing que publica con frecuencia.

Los matices a tener en cuenta: hay que mantener dos sistemas (el gestor de contenido y el front Next.js), la sincronización de contenido necesita su mecanismo (regeneración de páginas cuando se publica o edita), y algunas funciones que antes eran automáticas (vistas previas, ciertos añadidos de front) requieren trabajo adicional. Aun así, para el perfil de empresa que no quiere renunciar a un panel cómodo pero necesita velocidad, headless suele ser la mejor relación entre beneficio y riesgo.

Qué pasa con los plugins de WordPress al migrar

Los plugins de WordPress no funcionan en Next.js, pero casi todas sus funciones habituales tienen un equivalente directo que se implementa con código o con un servicio externo. Conviene saber cuál es el sustituto de los más comunes para no llevarte sorpresas en el presupuesto.

Función del plugin	Plugin típico en WordPress	Equivalente en Next.js
SEO (metadatos, sitemap)	Yoast, RankMath	Metadatos nativos de Next.js + sitemap generado
Caché y rendimiento	WP Rocket, W3 Total Cache	Innecesario: estático desde CDN
Formularios	Contact Form 7, WPForms	Integración con servicio de formularios o endpoint propio
Ecommerce	WooCommerce	Solución de ecommerce headless o pasarela directa
Multiidioma	WPML, Polylang	Enrutado de idiomas nativo de Next.js + hreflang
Seguridad	Wordfence, Sucuri	Mayormente innecesario: poca superficie de ataque
Copias de respaldo	UpdraftPlus	Versionado en el repositorio (Git)
Analítica	MonsterInsights	Integración directa de la herramienta de analítica
Constructor visual	Elementor, Divi	Componentes a medida (no hay equivalente directo)

El caso que más atención requiere es el de los constructores visuales tipo Elementor o Divi: no tienen equivalente directo porque su valor es precisamente permitir maquetar visualmente sin código, y en Next.js la maquetación es código. Si tu web depende fuertemente de un constructor visual y quieres mantener esa capacidad de editar el diseño sin programar, la migración debe contemplar un CMS que ofrezca bloques visuales, o asumir que el diseño lo gestionará el equipo técnico. Auditar esto en la fase 1 evita el descubrimiento incómodo a mitad de proyecto.

Next.js y la visibilidad en motores de IA (GEO)

Next.js parte con ventaja también en visibilidad ante los motores de IA porque entrega HTML completo y bien estructurado, que es lo que esos sistemas necesitan para leer y citar contenido. La optimización para motores generativos (ChatGPT, Perplexity, Gemini, Google AI Overviews) se está volviendo tan relevante como el SEO clásico, y los factores que la favorecen se alinean con lo que Next.js hace bien.

El renderizado en servidor o estático garantiza que el rastreador de un motor de IA reciba el contenido completo, no un esqueleto que depende de JavaScript ejecutado en el cliente. Los datos estructurados completos dan contexto explícito sobre qué es cada cosa. Y el control total sobre la salida permite implementar elementos que mejoran la citabilidad: archivos como llms.txt o ai.txt, endpoints de resumen, contenido con respuestas claras al principio de cada sección (el patrón "answer-first" que también gusta a Google).

Una migración bien hecha es, por tanto, una oportunidad para construir desde el principio con la visibilidad en IA en mente, en lugar de añadirla después con esfuerzo. Si la migración va a tocar todo el sitio de todas formas, tiene sentido aprovechar para dejarlo listo para la era de la búsqueda generativa. Profundizamos en este enfoque en la guía de SEO y GEO para empresas en España.

Migración de un ecommerce: lo que cambia respecto a una web corporativa

Migrar un ecommerce de WooCommerce a Next.js es un proyecto de otra categoría, porque a las URLs de contenido se suman las URLs de catálogo, las páginas de filtro y paginación, y un sistema transaccional que no puede fallar. Vale la pena tratarlo aparte porque los errores aquí no solo cuestan posiciones: cuestan ventas directas.

El primer reto es el volumen y la naturaleza de las URLs. Un ecommerce tiene URLs de producto, de categoría, de subcategoría, de filtros combinados (color, talla, precio) y de paginación. No todas deben indexarse: las combinaciones de filtros generan miles de URLs casi duplicadas que conviene gestionar con canónicas o con noindex selectivo, igual que se hacía en WooCommerce. La migración tiene que replicar esa estrategia de indexación con precisión, porque indexar de golpe todas las combinaciones de filtros que antes estaban controladas es una forma rápida de diluir la autoridad del catálogo.

El segundo reto es el sistema transaccional. En WooCommerce, el carrito, el checkout, el pago y la gestión de pedidos vienen de serie. En Next.js hay que decidir la arquitectura de ecommerce: un backend de comercio headless (que gestiona catálogo, carrito, pedidos y stock vía API mientras Next.js renderiza el front), o mantener WooCommerce como backend headless y consumir su API de tienda. La pasarela de pago, el cálculo de impuestos (IVA según destino), los gastos de envío y la sincronización de stock son piezas que hay que probar exhaustivamente en staging con pedidos reales de prueba antes de tocar el dominio.

El tercer reto es el SEO del catálogo, que es la mayor parte del tráfico de un ecommerce. Las fichas de producto y las páginas de categoría son las que rankean para las búsquedas con intención de compra. Su migración exige conservar URLs, replicar el contenido descriptivo, mantener el schema de producto (Product con precio, disponibilidad y valoraciones), y preservar las imágenes con sus textos alternativos. Una ficha de producto que pierde su schema pierde la estrella de valoración y el precio en los resultados de Google, y con ello buena parte de su CTR.

La recomendación para un ecommerce: planificar la migración en una ventana de bajo tráfico de ventas, tener el sitio antiguo accesible como respaldo inmediato, y no migrar todo el catálogo de golpe si es muy grande, sino por bloques verificables. El plazo realista de un ecommerce de tamaño medio es de tres a cinco meses, y el presupuesto, desde 15.000 € hacia arriba según el número de referencias y la complejidad de las integraciones. Son cifras orientativas, pero el orden de magnitud refleja que un ecommerce no es una web corporativa con más páginas: es un sistema con lógica de negocio que hay que reconstruir y validar.

Implementación técnica de las redirecciones 301 en Next.js

Las redirecciones 301 en Next.js se pueden implementar de tres formas, y elegir la adecuada según el volumen de URLs es lo que evita problemas de rendimiento y mantenimiento. Esta sección es para el perfil técnico que va a ejecutar la migración o que quiere entender qué le están proponiendo.

La primera forma es la configuración estática en el archivo de configuración del proyecto. Next.js permite declarar redirecciones permanentes en su fichero next.config, donde cada entrada define un origen, un destino y la marca de permanente (que genera el código 308, equivalente a un 301 que preserva el método de la petición). Es la opción adecuada cuando el número de redirecciones es manejable (decenas o algún centenar) y son estáticas. La ventaja es que viven en el repositorio, versionadas y revisables; el inconveniente es que un volumen muy grande de reglas ralentiza el arranque y es incómodo de mantener.

La segunda forma es la redirección a nivel de servidor o CDN. Cuando hay miles de redirecciones (típico de un ecommerce o de una migración con reestructuración grande de URLs), tiene más sentido gestionarlas en la capa de red (el CDN o el servidor que sirve la aplicación), donde se resuelven antes de llegar a la aplicación y con mejor rendimiento. Muchas plataformas de hosting permiten cargar un mapa de redirecciones como archivo. La ventaja es la escala; el inconveniente es que las reglas viven fuera del código de la aplicación y hay que documentarlas bien.

La tercera forma es la redirección dinámica para patrones, no para URLs individuales. Si la migración cambia un patrón completo (por ejemplo, todas las URLs que empezaban por /blog/AAAA/MM/titulo pasan a /blog/titulo), no hace falta una regla por URL: una sola regla con captura de parámetros redirige todo el patrón. Esto reduce miles de reglas individuales a unas pocas reglas de patrón, y es la diferencia entre un mapa de redirecciones manejable y uno ingobernable.

El detalle técnico que más errores causa: usar 302 (redirección temporal) donde debe ir 301 o 308 (permanente). Una 302 le dice a Google que la URL antigua volverá, así que no transfiere la autoridad a la nueva. En una migración, casi todas las redirecciones deben ser permanentes. El otro detalle crítico es evitar cadenas: si la URL A redirige a B y B redirige a C, cada salto pierde un poco de eficiencia y rastreo. Hay que aplanar las cadenas para que A vaya directamente a C. Una herramienta de rastreo que siga las redirecciones permite detectar y corregir estas cadenas antes del lanzamiento.

Cómo medir el éxito de la migración: qué esperar semana a semana

El éxito de una migración no se mide el día del lanzamiento, sino en la evolución de un conjunto de métricas durante las seis a ocho semanas posteriores, comparadas con el baseline que se capturó antes de empezar. Saber qué es normal y qué es alarma evita dos errores opuestos: entrar en pánico por una caída temporal esperable, o no detectar a tiempo un problema real.

La curva típica de una migración bien hecha tiene una forma reconocible. En los primeros días tras el cambio de DNS, Google empieza a rastrear el sitio nuevo y a procesar las redirecciones; es habitual ver una ligera caída de impresiones y posiciones mientras el rastreador reconsolida, porque está reevaluando el sitio. Esa caída inicial, si es moderada y se recupera, es normal y no debe provocar cambios precipitados. Entre la segunda y la cuarta semana, las posiciones suelen volver al nivel previo a medida que Google consolida las señales en las nuevas URLs. A partir de ahí, si los Core Web Vitals han mejorado de verdad, es frecuente ver una mejora sobre el baseline, no solo una recuperación.

Esta es la tabla de qué vigilar y qué umbral marca alarma:

Métrica	Dónde se mide	Qué es normal	Señal de alarma
URLs indexadas	Search Console (cobertura)	Estable o subiendo tras 2-3 semanas	Caída sostenida del número de URLs indexadas
Errores 404	Search Console / logs	Algunos al principio, en descenso	404 que crecen o no se corrigen
Posición media	Search Console (rendimiento)	Bajada leve inicial, recuperación en 2-4 semanas	Caída fuerte que no se recupera tras 4 semanas
Impresiones	Search Console	Recuperación progresiva	Caída del 30 % o más sostenida
Tráfico orgánico	Analítica	Pequeña caída inicial, luego recuperación	Caída pronunciada y sostenida
Core Web Vitals (campo)	Search Console / PageSpeed	Mejora visible en 3-4 semanas	Métricas peores que antes de migrar

La regla de diagnóstico: una caída moderada que se recupera es el comportamiento esperado; una caída fuerte que no se recupera tras cuatro semanas indica un problema concreto que hay que diagnosticar (casi siempre redirecciones mal hechas, contenido no replicado o un bloqueo de rastreo). El error de no monitorizar es lo que convierte un problema corregible en una pérdida permanente de tráfico, porque nadie lo detecta hasta que el daño está consolidado.

Conviene fijar un punto de revisión formal a las cuatro y a las ocho semanas, comparando cada métrica con su baseline. A las cuatro semanas se decide si hay que intervenir; a las ocho se cierra el proyecto de migración con un informe de antes y después que demuestra que el SEO se preservó (o mejoró) y que el rendimiento dio el salto esperado. Ese informe es también la prueba de que la inversión en una migración bien hecha valió la pena.

El proceso de migración paso a paso, resumido

Para quien necesita el mapa de un vistazo, este es el orden lógico de una migración que no pierde SEO, condensado en sus hitos:

1. Auditoría e inventario. URLs, contenido, metadatos, schema, enlaces, plugins y baseline de métricas. Nada se migra sin estar inventariado.
2. Decisiones de arquitectura. Modelo de contenido (headless, CMS o Markdown), estrategia de renderizado y, sobre todo, estrategia de URLs (por defecto, mantenerlas).
3. Desarrollo en staging. Plantillas, contenido replicado, metadatos y schema página a página, enlaces internos correctos.
4. Plan de redirecciones. Mapa completo de 301, implementado y verificado.
5. SEO técnico. sitemap, robots.txt, canónicas, hreflang si aplica, 404 correcta.
6. Pruebas en staging. Comparación de contenido, validación de 301 y schema, Core Web Vitals, móvil, formularios.
7. Lanzamiento. Cambio de DNS, verificación inmediata, envío de sitemap a Search Console.
8. Monitorización. Vigilancia diaria de indexación, 404, posiciones y tráfico durante 4-6 semanas.

El orden importa: no se desarrolla sin auditar, no se lanza sin probar en staging, y no se da por terminada la migración el día del lanzamiento, sino cuando las métricas se han estabilizado semanas después.

Errores frecuentes en migraciones (y cómo no cometerlos)

Después de ver migraciones que salieron bien y otras que costaron tráfico, los errores se repiten con un patrón reconocible. Conocerlos de antemano es la mejor vacuna.

Error 1: cambiar URLs "para mejorarlas" en la misma migración. La tentación de aprovechar la migración para reorganizar la estructura de URLs es comprensible pero peligrosa. Cada cambio de URL es una 301 más y un punto más de riesgo. Si hay que reestructurar URLs, hazlo como proyecto separado, antes o después de la migración, no a la vez, para poder aislar el efecto de cada cambio.

Error 2: mejorar el contenido durante la migración. Igual que con las URLs: si reescribes o amplías contenido a la vez que cambias de tecnología, no podrás saber si una caída de posiciones vino de la migración o del nuevo contenido. Replica primero, mejora después.

Error 3: lanzar sin reducir el TTL del DNS antes. Si el TTL del registro DNS es alto (24 horas, por ejemplo), el cambio de servidor tarda en propagarse y durante ese tiempo unos usuarios ven el sitio viejo y otros el nuevo. Reducir el TTL unos días antes del lanzamiento hace que el cambio se propague rápido y limpio.

Error 4: dar por buena la migración el día del lanzamiento. El lanzamiento es el principio de la fase crítica, no el final. Las primeras semanas son cuando aparecen los 404 que se escaparon y los problemas de indexación. Cerrar el proyecto el día del cambio de DNS es dejar la puerta abierta a perder tráfico sin enterarse.

Error 5: no conservar el sitio antiguo accesible un tiempo. Mantener el sitio original disponible (en un subdominio o en local) durante unas semanas después del lanzamiento permite consultar contenido, comparar y recuperar cualquier cosa que se haya escapado del inventario. Borrarlo el día del lanzamiento es quemar la red de seguridad.

Cómo abordamos las migraciones en YAG

Si has llegado hasta aquí, probablemente tienes claro que la migración es viable pero quieres asegurarte de que se hace sin riesgo para tu posicionamiento. Así es como planteamos una migración a Next.js cuando una empresa nos la encarga.

Primero, auditoría y baseline. Antes de proponer nada, inventariamos el sitio actual: URLs, tráfico, posiciones, contenido, schema y funcionalidades. Ese trabajo produce el mapa de lo que hay que preservar y el baseline contra el que mediremos el éxito. Sin baseline no hay forma honesta de demostrar que la migración salió bien.

Decisión de arquitectura según tu equipo. No imponemos un modelo de CMS: lo elegimos según quién edita tu contenido y con qué frecuencia. Si tu equipo publica a diario sin perfil técnico, headless conservando un panel cómodo; si el contenido es más estable, Markdown en el repositorio, que es la opción más rápida y segura.

Desarrollo en staging con verificación continua. Construimos en un entorno de pruebas y verificamos contenido, redirecciones, schema y Core Web Vitals antes de tocar el dominio. El plan de redirecciones 301 es una partida explícita del proyecto, no un añadido.

Lanzamiento controlado y monitorización. Coordinamos el cambio de DNS, verificamos todo en producción el mismo día y monitorizamos la indexación y las posiciones durante las semanas siguientes, corrigiendo cualquier 404 o incidencia en cuanto aparece.

El objetivo no es solo no perder SEO: es que, gracias a la mejora de rendimiento y a una base técnica moderna, el sitio quede mejor posicionado de lo que estaba, más rápido, más seguro y más barato de mantener. Si quieres saber qué tiene sentido para tu caso, en YAG Comunicación hacemos una primera consultoría sin coste para evaluar si la migración te compensa y qué riesgos concretos tiene tu proyecto.

Conclusión: la migración no pierde SEO, los atajos sí

Migrar de WordPress a Next.js es una decisión que, bien ejecutada, mejora el rendimiento, la seguridad y el coste de mantenimiento de tu web sin sacrificar el posicionamiento que has construido. La idea de que migrar destroza el SEO es un mito que confunde la causa: lo que destroza el SEO no es Next.js, son las migraciones hechas con prisa, sin inventario de URLs, sin plan de redirecciones 301, sin replicar contenido y schema, y sin monitorización posterior.

La tecnología es la parte fácil. La parte que decide el resultado es la disciplina del proceso: auditar antes de tocar nada, mantener las URLs o redirigirlas con 301, replicar todas las señales on-page, garantizar el rastreo desde el primer minuto y vigilar las métricas hasta que se estabilicen. Cumple esos cinco controles y la migración no solo conserva tu tráfico orgánico: lo más probable es que, con unos Core Web Vitals notablemente mejores, lo aumente.

Y si tu WordPress va rápido, es seguro y cumple su función, la decisión más inteligente puede ser no migrar todavía. La mejor migración es la que se hace cuando hay una razón de negocio real y presupuesto para hacerla completa. Si ese es tu caso, el camino está claro y el riesgo es manejable. Si no lo es, optimiza lo que tienes y guarda el presupuesto para cuando la migración tenga un retorno que la justifique.