De WordPress a Next.js sin perder SEO: la guía técnica completa (2026)

El miedo es siempre el mismo: "llevo años construyendo mi SEO en WordPress, ¿y si al migrar a Next.js lo pierdo todo?". Es un miedo razonable — una migración mal ejecutada rompe URLs, pierde schemas y tira posiciones. Pero también es evitable al 100%: la pérdida de SEO en una migración nunca viene de la tecnología nueva, viene de los detalles que se rompen por el camino. Esta guía es la lista completa de esos detalles.

Desde dónde te hablamos: en SprintMarkt construimos en Next.js a diario — nuestra propia web (sprintmarkt.com) es un Next.js con App Router, export estático e i18n en dos idiomas, y la operamos y optimizamos nosotros mismos. Sabemos dónde brilla (velocidad, control total del SEO técnico, cero plugins en conflicto) y dónde duele (los quirks del framework que verás más abajo). Todo lo que sigue es el procedimiento que aplicaríamos a tu migración, no teoría.

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: por qué Next.js gana (y por qué no es automático): la ventaja estructural viene de 3 sitios: (1) imágenes WebP/AVIF generadas en build vs WordPress sirviendo PNG de 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. Pero ojo: Next.js no te salva de tus propios errores — en nuestra propia web encontramos (con PageSpeed, midiendo de verdad) un vídeo de 23MB cargando en una sección de la home y logos servidos a 10 veces su tamaño de render. La velocidad no es el framework: es la disciplina de medir. Audita SIEMPRE con PageSpeed antes y después de migrar, con números reales, no con sensaciones.

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 realista de una migración (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 en 2026 (tarifas 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.