Migración de WordPress a Next.js sin perder ni un solo ranking.

¿Honestamente? Principalmente porque Lighthouse nunca llega del todo.

He pasado muchas mañanas explicando a founders por qué su sitio de Elementor construido con cariño se queda en 62 en PageSpeed Insights incluso después de tres plugins de caché, un CDN y un cambio de hosting reciente. Hay un techo. Puedes forzar un front-end clásico de WordPress hacia los bajos 80 si realmente te importa, pero cada actualización de plugin es un riesgo de regresión y cada lanzamiento de page builder trae otro medio megabyte que no pediste.

Los equipos que veo migrar caen en tres categorías aproximadas, y casi nunca se superponen.

El bucket de rendimiento

Un sitio de marketing SaaS de Serie A, actualmente en WP Engine, pagando por Elementor Pro más tres paquetes add-on. Lighthouse 64 en mobile. INP en 380 ms. Tienen un equipo de contenido que lanza dos posts por semana y un equipo de engineering que quiere enviar flujos de onboarding, no parches de WordPress. El rebuild de Next.js los lleva a 96, y los engineers dejan de tocar wp-admin.

El bucket de engineering

Tres engineers de TypeScript. Uno de ellos está de guardia por el sitio de marketing. Abren wp-admin una vez cada quince días y maldice. Todo el número de "¿esto es PHP 7.4 u 8.1, qué versión de WooCommerce nos dejó la agencia" es un impuesto sobre personas que estarían felices de enviar en Astro con la mitad de la agitación. Migra, dale un repo de Next.js o Astro con CI adecuado, y la rotación de guardia se reduce.

El bucket de seguridad

Menos común, más decisivo. Un mandato a nivel de board de que las superficies públicas no deberían ejecutar PHP. O un incidente de seguridad que envió un plugin parcheado tres semanas tarde. WordPress headless en una origen no pública satisface la política sin obligar al equipo editorial a aprender un CMS nuevo. El wp.example.com se vuelve privado; el front-end es solo un sitio estático en Vercel. La mayoría de pen tests dejan de ser interesantes.

Tres. Genuinamente tres, no del tipo página de marketing que todos se colapsan en el mismo scope. Cada uno se adecúa a un equipo diferente.

Ruta 1 — mantener WordPress, reemplazar el front-end

Headless. WordPress se queda como la superficie de edición. Yoast sigue haciendo su trabajo en el admin. ACF sigue haciendo su trabajo en el admin. El sitio público se reconstruye en Next.js o Astro y obtiene contenido a través de WPGraphQL. Los editores apenas notan el día de la migración más allá de que la barra de URL muestre el nuevo dominio del front-end. Esta es la ruta más común que cotizo; aproximadamente dos tercios de las migraciones recientes han seguido este camino.

Cuándo es la opción correcta: el equipo editorial está conforme en WordPress, el problema de ingeniería es puramente del front-end, y no quieres migrar doce mil páginas de metadatos de Yoast.

Ruta 2 — abandonar WordPress por completo

Migrar todo a Sanity, Payload, Storyblok o Contentful. Apagar WordPress en el lanzamiento. Codebase más nuevo, modelo de contenido más limpio, sin PHP en ningún lugar. El costo de migración es más alto porque estás moviendo contenido, no solo reconstruyendo el front-end. Vale la pena cuando el equipo editorial específicamente quiere salir de WordPress, o cuando el modelo de contenido necesita más rigor del que el contenido flexible de ACF puede darte.

Cuándo es la opción correcta: realmente quieres un CMS diferente, no solo un front-end diferente.

Ruta 3 — híbrida

Algo de contenido se queda en WordPress, algo se mueve a otro lugar. Patrón de ejemplo real: el blog se queda en WP porque el equipo editorial es maduro y Yoast está haciendo un trabajo real; las páginas de producto se mueven a Payload porque el esquema necesita relaciones y validación adecuadas. El front-end es una sola aplicación Next.js que lee desde ambos backends. Más arquitectura pero a veces es la respuesta correcta.

Cuándo es la opción correcta: dos formas de contenido genuinamente diferentes en el mismo sitio, y forzarlas en un solo CMS le está haciendo la vida peor a alguien.

Aquí es donde las migraciones viven o mueren, y también es la parte en la que los equipos rutinariamente escatiman. Sin un mapa completo pierdes rankings el primer día. Con un mapa parcial los pierdes lentamente durante seis semanas mientras te dices a ti mismo que la caída es solo estacionalidad.

El mapa se construye a partir de tres fuentes independientes antes de que cualquier código se despliegue.

1. Exportación de Search Console — cada URL que Google ha rastreado y considerado indexable en los últimos 16 meses. Esta es la lista canónica de lo que Google actualmente espera encontrar en tu dominio.
2. Exportación de Ahrefs o Semrush — cada URL con al menos un dominio de referencia apuntando a ella, ordenada por cantidad de dominios de referencia. Estas son las URLs donde la preservación de 301 importa más. Si haces un 404 en una página con 200 backlinks, acabas de desperdiciar 200 backlinks.
3. Sitemap de WordPress — tu exportación actual de sitemap XML. Detecta páginas que pueden no tener backlinks ni tráfico orgánico pero que siguen en la estructura. Útil como tercera pasada para encontrar lo que las primeras dos pasaron por alto.

Tres listas, deduplicadas, mapeadas a nuevas URLs, desplegadas como 301s en vercel.json o netlify.toml en el edge. No 302s. No redirecciones impulsadas por JavaScript. No una meta refresh. Las URLs realmente retiradas obtienen 410. Las URLs que han cambiado slug obtienen 301. El linter de compilación falla el despliegue si alguna URL previa a la migración falta en el mapa.

He visto una migración de 5.000 páginas perder el 60% de su tráfico orgánico en ocho semanas porque el mapa de redirección estaba 87% completo y "el resto no vale la pena preocuparse". Ese 13% valía la pena preocuparse. Siempre lo vale.

Auditoría de plugins el primer día. Cada plugin activo cae en uno de cuatro buckets, y el bucket decide el trabajo.

Se mantiene como está

Plugins que corren del lado del servidor y nunca tocan el front-end público. WP Migrate DB, BackWPup, analítica del lado del servidor, gestión de roles. Siguen funcionando porque nada de su tarea implica renderizar HTML a un visitante. Aproximadamente el 20-25% del conteo de plugins generalmente cae aquí.

Reemplazado por código

Plugins que inyectan HTML o JavaScript en el front-end. La mayoría de plugins SEO (los transportes de metadatos, la salida front-end es personalizada). La mayoría de plugins de formularios (reemplazados por endpoints de Next.js o por ConvertKit / HubSpot / Mailchimp). La mayoría de plugins de schema (reemplazados por plantillas escritas a mano que emiten JSON-LD más limpio de todos modos). Los banners de cookies se reescriben en TypeScript. Aproximadamente el 30-40% del conteo de plugins.

Reemplazado por servicio

Plugins que envuelven a un tercero. El plugin de incrustación de HubSpot se convierte en una llamada a HubSpot Forms API. El plugin de pago de Stripe se convierte en Stripe Elements. Zapier y Make se quedan donde están porque viven fuera de WordPress de todas formas. Aproximadamente el 10-15% del conteo.

Eliminado por completo

Plugins que existen únicamente porque el front-end de WordPress los necesitaba. Plugins de caché (Vercel se encarga de esto). La mayoría de plugins de seguridad (la superficie de ataque pública desapareció). Plugins de optimización de rendimiento (ahora es una preocupación en tiempo de compilación). Y el siempre divertido grupo de "no tengo idea por qué está aquí, ha estado desactivado durante dos años pero nunca lo eliminamos". Los conteos de plugins en el lado de WordPress típicamente caen 70-80% post-migración. Eso es parte de la victoria.

Vista previa y borradores

Los editores presionan Preview en wp-admin. WordPress genera un token JWT de vista previa. El front-end de Next.js lee el token, obtiene el borrador a través de WPGraphQL omitiendo el caché estático, y renderiza. Las URLs de borradores están firmadas, nunca son indexables, nunca se cachean públicamente. La experiencia de vista previa de un clic permanece exactamente como era. La mayoría de los editores nunca notan el día de migración en el lado editorial.

Comentarios, revisiones, roles

Sin cambios en el back-end. Los comentarios en posts pueden permanecer nativos de WordPress y renderizarse headless vía WPGraphQL, o ser reemplazados con Disqus / Giscus / un sistema personalizado si tu equipo quería eso de todas formas. Las revisiones no cambian — cada post sigue teniendo su historial completo accesible desde el editor de WordPress. Los roles de usuario, permisos, configuraciones multi-autor, todo se preserva.

Yoast y Rank Math

Ambos se transportan. Yoast SEO para WPGraphQL expone cada campo — palabra clave de enfoque, título meta, meta descripción, canónico, OG, Twitter card, schema de breadcrumb — como GraphQL consultable. Rank Math tiene el equivalente. El layout de Next.js lee la respuesta tipada y renderiza meta tags idénticas a lo que Yoast o Rank Math hubieran generado en WordPress clásico. Los editores siguen editando en la misma interfaz de plugin; la migración es invisible de su lado.

Semana 1: descubrimiento y alcance

Auditoría de plugins. Auditoría de contenido. Search Console + exportación de Ahrefs para la fuente del mapa de redirecciones. Línea base de rendimiento actual. Decisión entre camino uno versus dos versus híbrido. Resultado: SOW escrito con precio fijo y calendario de pagos por hito. Al final de la primera semana sabes exactamente qué estás pagando.

Semanas 2-4: cimentación

Repos en tu GitHub, no en el nuestro. Hosting en tus cuentas. WPGraphQL (o CMS nuevo) configurado. Scaffolding de Next.js o Astro entregado. Linter SEO e ingesta de mapa de redirecciones conectados. Design tokens migrados. Al final de la semana cuatro la base es real y el equipo está entregando páginas.

Semanas 5-10: construcción

Templates portados, página por página. Looms diarios del ingeniero líder en tu Slack. Llamada de revisión semanal a mitad del proyecto. Tickets en Linear o Jira o lo que ya uses. Edge cases detectados conforme aparecen. Este es el medio aburrido del proyecto donde se escribe la mayoría del código real.

Semanas 10-12: control de calidad previo al lanzamiento

Cross-browser manual. Auditoría móvil. Auditoría de accesibilidad en WCAG AA. Core Web Vitals en dispositivos reales (no Lighthouse de lab). Linter SEO en verde. Validador de schema en verde. Mapa de redirecciones verificado URL por URL contra exportación de Search Console. El plan de cutover escrito y ensayado.

Semana 12: lanzamiento

Cutover de DNS en una ventana que elijas. La mayoría lo hacen en martes o miércoles por la mañana, bajo tráfico. El front-end ya está corriendo en un dominio staging; el cutover es un flip de DNS. Engineering en standby durante 24 horas. Search Console enviado con el sitemap nuevo. Ahrefs y GA anotados.

Semanas 12-16: cuidado intensivo

Monitoreo diario de Search Console para detectar anomalías de indexación, advertencias de cadenas de redirección, errores de esquema. Comparación semanal de tráfico contra la línea base. Correcciones de errores priorizadas sobre nuevas funcionalidades. Para la semana 16 el sitio está estable y entregamos sin problemas o pasamos a un plan de mantenimiento continuo.