De WordPress a Next.js: migración sin perder SEO (caso real con números)

Cliente del sector legal-tech con 6 años de WordPress, 340 URLs indexadas, autoridad de dominio razonable (DA 38) y posiciones en top 10 para 28 keywords comerciales. Su problema: la web cargaba en 4.2s en móvil, el panel de WordPress estaba lleno de plugins en conflicto y cada actualización de WooCommerce rompía algo. Querían migrar a Next.js pero tenían pánico al "voy a perder todo el SEO que llevo 6 años construyendo".

Resultado a 8 semanas tras el go-live: tráfico orgánico estable (-2% el primer mes, +14% el segundo, +27% el tercero), 0 keywords perdidas en top 10, LCP de 4.2s a 0.9s en móvil, conversión del formulario de contacto +35%, factura de hosting bajó de 89€/mes (servidor compartido + Cloudflare) a 18€/mes (Vercel hobby + Supabase). El secreto no fue la velocidad: fue que NO rompimos ni una URL, ni un schema, ni una etiqueta canónica.

Matriz de decisión: ¿debes migrar? Migra SI: (1) tu LCP móvil está sobre 3s y has agotado plugins de caché. (2) tu equipo dev sufre con cada actualización WP/plugin. (3) necesitas funciones que WordPress hace mal: dashboards en tiempo real, integración con IA/Claude, multi-tenant, internacionalización seria. (4) crece tu tráfico móvil y los Core Web Vitals te frenan. NO migres si: (a) tu CMS es operado por marketing sin equipo técnico — pierdes la libertad editorial visual. (b) usas WooCommerce con +500 productos y plugins muy específicos. (c) tienes contenidos editoriales (blog grande con redactores no técnicos) — busca primero un headless tipo Sanity/Payload antes de irte a estático puro.

El plan de redirects 301 (esto es lo más infravalorado): descarga sitemap.xml completo de WordPress + Search Console URLs (las que reciben clics). Cruza ambas en un CSV. Para cada URL legacy escribe la URL nueva. Hay 4 casos: (1) misma URL → no hace falta redirect. (2) URL cambia ligeramente (ej. /sobre-nosotros/ → /about/) → 301 directo. (3) URL desaparece sin sucesor → 301 a la sección padre, NUNCA a la home (Google lo marca como soft 404). (4) URL desaparece sin contexto → 410 Gone, no 404. Implementa los redirects en next.config.js o, si son >100, en una Cloudflare Worker rule que se ejecuta antes del Next.js.

Replicar el schema.org existente — lo que el 80% se olvida: WordPress con Yoast o Rank Math emite automáticamente Organization, BreadcrumbList, BlogPosting, FAQPage, Person. Tu Next.js debe emitir EXACTAMENTE los mismos schemas, con los mismos @id, los mismos URL y la misma estructura. Pásate el Schema.org Validator en 20 URLs representativas ANTES del lanzamiento y AL DÍA SIGUIENTE. Si una migración pierde el BlogPosting.dateModified o el Organization.@id, Google empieza a re-evaluar todo el site y pierdes 30% tráfico durante 4-6 semanas.

Performance: WordPress vs Next.js — el benchmark real del proyecto: home WordPress con 12 plugins activos y caché WP Rocket → LCP 4.2s, CLS 0.18, TTI 6.1s, peso 2.4MB. Home Next.js con SSG + ISR + next/image → LCP 0.9s, CLS 0.02, TTI 1.4s, peso 380KB. Eso son números reales medidos con PageSpeed en producción. La mejora viene de 3 sitios: (1) imágenes WebP/AVIF generadas en build vs WordPress sirviendo PNG 1MB. (2) JavaScript que se hidrata por componente vs WordPress cargando jQuery + 8 plugins en cada página. (3) HTML estático cacheado en CDN vs WordPress generando HTML on-demand a cada visita.

Las 5 cosas que SIEMPRE rompen (te ahorro 3 semanas de pánico): (1) Las imágenes con extensión .webp custom de WP Smush rompen el next/image — solución: build-time pipeline con sharp que vuelve a generar TODO desde los originales. (2) Los shortcodes embebidos en posts (cuadros de Elementor, formularios CF7) — solución: identifica los 8-10 patrones más comunes y crea componentes React equivalentes. (3) WooCommerce sessions: si migras el catálogo a Shopify/Stripe, las sesiones de usuarios se invalidan — comunícalo 7 días antes a clientes y prepara recuperación de carrito. (4) Schema markup con @id legacy — replícalo IDÉNTICO los primeros 90 días. (5) Hreflang en sites multilenguaje — Next.js tiene quirks con i18n en App Router; usa <link rel='alternate' hreflang> explícito en cada page metadata.

Timeline real del proyecto (6 semanas): S1 — auditoría completa: sitemap, schema, performance, plugins, integraciones externas, dependencias críticas. CSV de migración aprobado por cliente. S2 — desarrollo Next.js skeleton: layout, header, footer, sistema de tipografía, design tokens, primeras 5 plantillas. S3 — migración de contenidos: scraping sistemático del WP existente, conversión a estructura Next.js (MDX o JSON), regeneración de imágenes en sharp pipeline. S4 — replicar schemas, redirects, integraciones (Google Analytics, Tag Manager, formularios, CRM). S5 — staging completo con dominio temporal, QA exhaustivo (clientes prueban 100 URLs aleatorias), parche de últimos bugs. S6 — DNS swap durante ventana de bajo tráfico (típicamente domingo madrugada), monitoreo 72h, ajustes finos. WordPress legacy queda 30 días en pre-prod como rollback de emergencia.

Coste orientativo de una migración real en 2026 (precios SprintMarkt): site corporativo simple (15-30 URLs, sin e-commerce, sin multi-idioma): 4.500€-6.500€. Site con blog grande (100-300 URLs) + multi-idioma: 7.000€-11.000€. Site corporativo + WooCommerce con +200 productos a Stripe/Lemon Squeezy: 12.000€-18.000€. Site con dashboard cliente / panel de gestión personalizado: 16.000€-25.000€. Todos los presupuestos incluyen plan de redirects, replicación de schema, regeneración de imágenes, testing en staging con 5 rondas de cliente y monitoreo 60 días post-go-live.