Hace tres años tomé el blog de un cliente, 400 posts, 60k visitas orgánicas mensuales, ocho años de PageRank acumulado, y lo migré a un brillante front-end en Next.js. En seis semanas habíamos perdido el 34% de ese tráfico. No porque el nuevo sitio fuera lento. No porque el contenido desapareciera. Porque fui descuidado con cuatro cosas específicas que te explicaré en este post para que no repitas mi error.
WordPress headless con Next.js es genuinamente excelente para rendimiento y experiencia del desarrollador. Pero a Google no le importa tu puntuación de Lighthouse si tus etiquetas canónicas están mal, tu sitemap XML apunta al dominio antiguo y tus datos estructurados desaparecieron en algún lugar entre WPGraphQL y getStaticProps. La migración en sí es la parte peligrosa. Hacerlo bien depende principalmente de disciplina, no de magia.
---
Por Qué Esta Migración Rompe el SEO en Primer Lugar
Aquí está la cuestión que la mayoría de tutoriales pasan por alto: WordPress hace una enorme cantidad de trabajo SEO por ti sin que te des cuenta. Yoast o Rank Math genera tus meta tags. WordPress core maneja tu estructura de enlaces permanentes. Tu tema probablemente está generando algún tipo de marcado de esquema. Tu sitemap XML se regenera automáticamente cada vez que publicas.
Cuando extraes la capa de contenido hacia Next.js a través de la API WPGraphQL y la sirves desde un nuevo front-end, toda esa infraestructura se convierte en tu responsabilidad de replicar. Cada. Pieza. Única.
El otro problema es la estructura de URLs. La mayoría de sitios WordPress tienen /category/post-slug/ o /year/month/post-slug/ o simplemente /post-slug/. Next.js te da un lienzo en blanco para el enrutamiento. Ese lienzo en blanco es un cementerio de rankings si no lo planificas cuidadosamente.
Los Dos Modos de Fallo que Veo Constantemente
La primera son los equipos que migran también las URLs y siguen rompiendo cosas, usualmente porque las redirecciones se aplican de manera inconsistente o el nuevo sitemap se publica antes de que las redirecciones estén activas. La segunda son los equipos que intencionalmente cambian la estructura de URLs (a menudo para limpiarla) y tratan el mapeo de redirecciones como algo secundario. Ambas son corregibles. Ninguna es aceptable.
---
Audita Antes de Tocar Nada
No escribas una sola línea de código en Next.js antes de tener un inventario completo de URLs. Uso Screaming Frog, rastro el sitio WordPress en vivo, exporto todas las URLs indexables, y las descargo en una hoja de cálculo. Para un sitio de 400 páginas eso es quizá una hora de trabajo. Para un sitio de 4,000 páginas sigue siendo solo una hora, porque la herramienta lo hace automáticamente.
Lo que estás capturando:
- Cada URL canónica actualmente indexada
- El estado HTTP de cada una (identifica 404s y 301s que ya existen)
- El título meta y la descripción para cada página
- Qué páginas tienen datos estructurados (usa Rich Results Test o simplemente inspecciona el código fuente)
- Enlaces internos entrantes, para que sepas qué páginas enlazan a cuáles.
También extrae tus 50 páginas principales de Google Search Console ordenadas por clics. Estas son las que no puedes permitirte equivocarte. Márcalas en la hoja de cálculo. Trátalas como dependencias en producción.
Seahawk tenía un cliente de e-commerce a finales de 2022 -- una tienda WooCommerce de 1,200 productos migrando a una configuración headless. Pasamos dos días completos en la auditoría antes de escribir código. El cliente pensó que estábamos perdiendo tiempo. Salvamos sus 90k sesiones orgánicas mensuales.
---
Configurar WordPress como un CMS Headless Verdadero
Esta parte es en su mayor parte directa. Instala WPGraphQL y expone tu contenido a través de la API de GraphQL. Pero hay algunas cosas que vale la pena ser deliberado al respecto.
Mantén Yoast (o Rank Math) Ejecutándose en el Lado de WordPress
Aunque ya no estés sirviendo WordPress como el front-end público, mantén tu plugin de SEO activo. WPGraphQL for Yoast SEO (o la extensión equivalente de Rank Math) expone todos los metadatos SEO, títulos, descripciones, URLs canónicas, datos OG, directivas robots, directamente a través de la API GraphQL. Eso significa que puedes consultarla desde Next.js y renderizarla exactamente como Yoast lo intentó.
Esta fue la lección de esa caída de tráfico de 2019 que mencioné. Asumí que podríamos regenerar títulos a partir del título de la publicación + nombre del sitio en Next.js. Podíamos. Pero Yoast había personalizado manualmente meta títulos para unos 80 de las publicaciones con mejor desempeño, y borramos todo eso. Ocho semanas para recuperarse.
Desactiva el Front-End de WordPress con Cuidado
Una vez que estés listo para dirigir tráfico a Next.js, NO quieres que WordPress sirva su propio front-end simultáneamente. Contenido duplicado a escala. La forma más limpia es establecer un robots.txt en tu instalación de WordPress para Disallow: / mientras tu sitio Next.js entra en vivo, y luego eventualmente bloquea la URL de WordPress completamente para que solo sea accesible internamente o a través de VPN.
No te saltes el paso de robots.txt. He visto equipos bloquear WordPress a nivel de CDN y luego descubrir que Googlebot tenía una ruta en caché. Toma meses limpiar.
---
Replicar la Estructura de URLs Exactamente
Mi recomendación predeterminada sólida: mantén tus URLs idénticas. Mismo slug, misma estructura de enlace permanente, mismo comportamiento de barra diagonal final. Cuanto más reflejen las rutas de Next.js las rutas de WordPress, menos redirecciones necesitarás y menos riesgo llevarás.
Las rutas dinámicas de Next.js lo hacen fácil. Si tus posts de WordPress viven en /blog/[slug], crea pages/blog/[slug].js. Listo.
Donde se complica es en archivos de categorías, páginas de autor, páginas de etiquetas y archivos paginados (/blog/page/2/). WordPress genera todos estos automáticamente. En Next.js los estás construyendo tú mismo. Muchos equipos depriorizan estos y luego se preguntan por qué la cobertura de rastreo disminuyó.
Aquí está mi checklist numerada para paridad de URLs:
- Posts/páginas individuales, coincide exactamente con el slug, incluyendo cualquier subcarpeta.
- Archivos de categoría, recrea
/category/[slug]/congetStaticPathsextrayendo todas las categorías de WPGraphQL. - Archivos de etiqueta, igual que lo anterior, no los saltes si reciben tráfico orgánico.
- Archivos de autor, revisa Search Console primero; si reciben cero clics, puedes hacer 301 hacia la página de inicio
- Archivos paginados,
/blog/page/[num]/vale la pena preservar si tienes muchos posts - Páginas de adjuntos, casi siempre haz 301 hacia el post padre; son peso muerto para SEO en WordPress también
- URLs de feed,
/feed/debe hacer 301 hacia tu nuevo feed RSS si tienes uno, o devolver 410 si no
---
Redirecciones: La Parte Que Todos Subestiman
Si estás cambiando cualquier URL, yo lo cuestionaría, pero a veces es necesario, tu mapa de redirecciones debe construirse antes del lanzamiento y probarse en un entorno de staging.
En Next.js, las redirecciones viven en next.config.js. Para sitios pequeños (menos de 200 redirecciones) está bien. Para algo más grande, ponlas en un archivo JSON e impórtalo, o usa middleware para manejarlas dinámicamente. El edge middleware de Vercel es excelente para tablas de redirecciones grandes porque se ejecuta antes de que la página se renderice, cero penalización de latencia.
El formato en next.config.js:
``redirects: [ { source: '/old-slug', destination: '/new-slug', permanent: true } ]``
permanent: true envía un 301. Úsalo para todos los cambios de URL genuinos. No uses 302 (temporal) a menos que realmente tengas la intención de revertirlo, Google los trata de manera muy diferente.
Prueba cada redirect antes del lanzamiento. Uso un script bash simple que recorre la hoja de cálculo y ejecuta curl en cada URL antigua verificando una respuesta 301 al destino correcto. Toma diez minutos escribirlo, ahorra horas de pánico post-lanzamiento.
---
Meta Tags, URLs Canónicas y Datos Estructurados en Next.js
Aquí es donde la mayoría de migraciones pierden puntos en silencio. El contenido está ahí, las URLs funcionan, pero las señales SEO están mal.
Meta Tags
Usa next-seo. Es el estándar. Pásale los datos que consultaste de WPGraphQL Yoast. Tu _app.js obtiene una configuración DefaultSeo, y cada página obtiene un componente NextSeo con las sobrescrituras específicas de la página. Toma el título, descripción, título OG, imagen OG, URL canónica, y directivas robots directamente de la respuesta GraphQL de Yoast, no lo reinventes.
Una cosa que causa problemas: las URLs canónicas. En WordPress, Yoast las configura automáticamente. En Next.js necesitas pasar la canónica explícitamente. Si se te olvida, Next.js renderizará páginas sin etiqueta canónica, y si tienes query strings en cualquier lado (paginación, filtros), terminarás con problemas de contenido duplicado más rápido de lo que esperas.
Datos Estructurados
Los temas y plugins de WordPress a menudo generan JSON-LD automáticamente. Eso desaparece en headless. Necesitas reconstruirlo. Para artículos, usa el schema Article. Para productos, Product. Para negocios locales, LocalBusiness. Yo escribo estos como componentes React que aceptan props y retornan una etiqueta <script type="application/ld+json">. Un componente por tipo de schema, reutilizado en toda la app.
Verifica cada tipo de schema que tenías previamente en la Rich Results Test antes de la migración. Documéntalo. Recréalo. Prueba los nuevos con la misma herramienta después del lanzamiento.
El Sitemap XML
No uses un sitemap estático. Genéralo dinámicamente. Para sitios pequeños, getServerSideProps en una ruta /sitemap.xml funciona. Para sitios grandes con miles de posts, genera el sitemap en tiempo de construcción mediante un script personalizado y guárdalo en la carpeta public/. Vercel ejecuta esto en cada deployment, tu sitemap siempre está actualizado.
Envía la nueva URL del sitemap a Google Search Console el primer día que el sitio nuevo esté en vivo. No el tercer día. El primer día.
---
Monitoreo Post-Lanzamiento (La Ventana de 90 Días)
La migración no termina en el lanzamiento. Termina cuando tus rankings se han estabilizado, lo cual la documentación de Google sugiere que puede tomar desde algunas semanas hasta algunos meses dependiendo del crawl budget y la autoridad del sitio.
Lo que reviso cada día de la semana durante el primer mes:
- Google Search Console → Reporte de cobertura para nuevos 404s o URLs 'Excluidas' que no deberían estarlo.
- Search Console → Performance, compara clics e impresiones semana a semana para tus top 50 páginas
- Re-rastreo de Screaming Frog del sitio nuevo para detectar cualquier 404 interno o etiquetas canónicas mal configuradas.
- Core Web Vitals, sí, el sitio Next.js debería ser más rápido, pero verifica en los datos de campo (CrUX), no solo en Lighthouse
Si ves una caída significativa en las primeras dos o tres semanas, no entres en pánico de inmediato. Casi siempre hay una fluctuación a corto plazo mientras Google recrawlea y reindexea. Lo que buscas son caídas sostenidas después de la semana cuatro. Esa es la señal de que algo estructural está mal.
A finales de 2022, proyecto diferente al del e-commerce, lanzamos una migración a Next.js para un blog SaaS y vimos una caída del 20% en impresiones en la segunda semana. Resultó que nuestro sitemap generado dinámicamente estaba incluyendo páginas con noindex porque no habíamos filtrado correctamente la consulta de WPGraphQL. Lo arreglamos en cuatro horas. Los rankings se recuperaron en tres semanas. El monitoreo lo detectó antes de que se agravara.
---
FAQ
¿Cuánto tiempo toma una migración de WordPress a Next.js?
Honestamente, depende más de la complejidad del sitio que de la cantidad de posts. Un sitio de 100 páginas tipo brochure con URLs limpias se puede hacer correctamente en dos o tres semanas. Un blog de 2,000 posts con tipos de post personalizados, campos ACF e integración WooCommerce es un proyecto de mínimo seis a ocho semanas si haces el trabajo de SEO correctamente junto con el desarrollo. No dejes que nadie te diga que es un trabajo de fin de semana.
¿Debo usar el Pages Router o el App Router en Next.js?
A partir de mediados de 2024 estoy usando App Router por defecto para nuevos proyectos. Pero si tu equipo se siente más cómodo con Pages Router y esta es una migración urgente, usa lo que conocen. Las implicaciones de SEO son mínimas, ambos soportan generación estática, renderizado del lado del servidor y rutas dinámicas. El paquete next-seo ahora tiene soporte para App Router también.
¿Necesito dejar de usar WordPress hosting completamente?
No. WordPress puede quedarse en su host existente, WP Engine, Kinsta, Cloudways, lo que estés usando, y actuar puramente como API de contenido. El front-end Next.js se despliega en Vercel o Netlify. Los dos se comunican vía HTTP. Algunos clientes en realidad prefieren esto porque el equipo editorial se queda con el admin de WordPress que ya conocen.
¿Qué hay con los plugins de WordPress que afectan el SEO, como redirecciones manejadas en Redirection?
Expórtalos antes de migrar. El plugin Redirection tiene exportación a CSV. Toma todas esas redirecciones existentes y agrégalas a tu next.config.js o a edge middleware. No asumas que se trasladarán automáticamente, no lo harán, porque viven en la base de datos de WordPress y Next.js no sabe que existen.
¿Mi ranking en Google bajará de todas formas?
Casi siempre hay algo de volatilidad a corto plazo. Una migración bien ejecutada sin cambios de URL, redirecciones propias (donde sea necesario), meta y datos estructurados replicados, y un sitemap re-enviado debería estabilizarse en cuatro a seis semanas. Las caídas que he visto que duraron meses fueron todas causadas por errores técnicos específicos, no por la migración en sí.
---
La migración no es la parte difícil. La parte difícil es la disciplina de hacer cada paso aburrido y poco glamoroso, la auditoría, el mapeo de redirecciones, la recreación del schema, antes de escribir cualquier código Next.js ingenioso. Haz ese orden correcto y saldrás del otro lado con un front-end más rápido y los mismos rankings con los que empezaste. Posiblemente mejores, una vez que las mejoras de Core Web Vitals se hagan efecto.