Migrar de WordPress a headless sin perder SEO

Las migraciones de WordPress fallan en SEO casi siempre por las mismas 4 razones: redirects 301 mal mapeados, slugs distintos, schema markup perdido, y carga inicial inflada por mover plugins de PHP a JS sin optimizar. Esta guía es el checklist real que ejecutamos cuando migramos un sitio de retail con 1.800 SKUs y 9 categorías sin perder posiciones de Google.

Por qué migrar (solo migra si pasa alguno de estos)

• LCP móvil > 3s y no podés bajarlo dentro de WordPress.
• Plugins acumulados sobrescribiendo funciones core, imposibles de auditar.
• Querés UX que WordPress no soporta (configurador 3D, builder personalizado, integraciones complejas).
• Costo de mantenimiento (hosting + dev WP) supera US$1.200/mes.
• Seguridad comprometida repetidas veces.

Si ninguna aplica, optimizá WordPress (caching, CDN, image optimization, plugin cleanup) antes de migrar. La migración cuesta US$18k–60k según tamaño.

Los 11 pasos que ejecutamos

1. Inventario completo de URLs

Crawl con Screaming Frog o Sitebulb. Exportá: URL actual, status code, title, meta description, H1, canonical, structured data, last modified. Esto es tu source of truth. Sin esto, vas a perder URLs.

2. Mapeo de URL → URL nueva (1 a 1)

Spreadsheet con columnas: old_url, new_url, status (301 / 410 / keep). El default es 301 directo a equivalente. Lo que no tiene equivalente claro va a 410 explícito, no 404 implícito.

3. Análisis de páginas con mejor tráfico orgánico

Search Console: top 50 URLs por tráfico. Esas URLs no cambian de slug. El resto puede ajustarse si hay razón. La regla: si una URL ranquea, no le tocás nada salvo la velocidad.

4. Schema markup inventory

Documentá todos los schemas presentes (Product, Organization, BreadcrumbList, Article, FAQPage). Cada uno tiene que reaparecer en el nuevo sitio con la misma estructura JSON-LD. Más estrictos: mismas propiedades, mismos valores.

5. Stack target

Para e-commerce: Shopify Hydrogen + Next.js, o Shopify storefront API + Next.js custom. Para sitios de contenido: Sanity / Contentful / Strapi como CMS + Next.js. Crítico: SSG o ISR, no SSR puro — los crawlers de Google leen HTML, no esperan JS.

6. Redirects en el edge (no en aplicación)

Vercel/Cloudflare redirects rules, o Nginx en self-hosted. Hacer redirects en Next.js middleware funciona pero suma 80–200ms por request. Edge redirects son instantáneos.

7. Estructura de URLs limpia

Quitá /?page_id=, parámetros de tracking que persisten, /index.php. Si las URLs nuevas son cleaner, mucho mejor para CTR.

8. Sitemap.xml regenerado

Nuevo sitemap auto-generado (Next.js sitemap.ts) con todas las URLs nuevas, lastmod correcto, priority razonable. Enviar a Search Console el día del switch.

9. Pre-launch: staging accesible sin indexar

robots.txt con Disallow: / en staging. X-Robots-Tag: noindex headers. Si Google indexa tu staging antes de lanzar, tenés un mes de duplicate content.

10. Validación pre-launch

• Google Rich Results Test para todos los tipos de schema.
• Lighthouse mobile: LCP < 2.5s, INP < 200ms, CLS < 0.05.
• 404 check: crawl el sitio staging entero, 0 errores 404.
• Test de redirects: 30 URLs random del sitio viejo, confirmar 301 a destino correcto.

11. Switch + monitoreo intensivo (semana 1)

DNS al nuevo sitio. Search Console: enviá sitemap, "Request indexing" en las 50 URLs principales. Monitoreá errores en GSC daily por 14 días. Si aparecen 404 inesperados, agregalos al mapeo de redirects.

Errores caros que vemos seguido

1. Redirects que apuntan a otros redirects (chains). Google solo sigue 5 saltos. Cada redirect debe ir directo al destino final.
2. Trailing slash inconsistente. Definí una regla (con o sin slash) y aplicala en todas las URLs y redirects.
3. Canonical tags rotos. Cada página debe tener canonical apuntando a su URL nueva, no a la vieja.
4. Imágenes con URLs viejas (CDN de WordPress). Migrá las imágenes con redirects o reuploadlas con URLs nuevas.
5. Olvidar productos descontinuados. Si una página de producto tenía tráfico orgánico, redireccionala a la categoría — no la mates con 404.

Targets de performance (mobile, 4G)

Métrica	WordPress típico	Headless bien hecho
LCP	3.5–6.5s	1.2–2.2s
INP	250–450ms	80–180ms
CLS	0.12–0.35	0.02–0.06
Total JS	800kb–1.4Mb	120–260kb
Total Imágenes	1.5–4Mb	200–500kb (AVIF + lazy)

Cuánto tiempo lleva

Sitio de contenido (~200 URLs): 6–8 semanas. E-commerce mediano (~1.000 SKUs): 9–14 semanas. E-commerce grande (5.000+ SKUs, configurables): 16–24 semanas. La estimación pesimista incluye dev + QA + ajuste de SEO post-launch. Migraciones rápidas son las que después pierden tráfico.

¿Y si pierdo posiciones igual?

Lo normal es caída temporal de 2–4 semanas mientras Google reindexa. Si a las 6 semanas no recuperaste el 90%+ del tráfico, hubo error de implementación. Audit + fixes pueden tardar 4 semanas adicionales. Por eso el plan importa.

¿Mantengo el CMS para que marketing siga publicando?

Sí. Headless = el CMS sigue siendo amigable (Sanity, Contentful, Strapi). Marketing publica en CMS, Next.js consume API. UX para editores puede ser igual o mejor que WordPress.

¿Vale la pena para sitios chicos?

Si tu sitio tiene < 50 URLs y < 5k visitas/mes, probablemente no. WordPress con un theme decente y caching está bien. Migrar tiene sentido a partir de tráfico significativo o problemas concretos.

Lo que recomendamos

Antes de migrar, optimizá WordPress al máximo: CDN, image optimization, plugin audit, caching agresivo. Si después de 4 semanas de optimización no llegás a CWV verdes, migrá.

Para la migración: contratá agencia que haya hecho 5+ migraciones con casos verificables. Pedí ver el spreadsheet de mapeo de URLs de una migración anterior. Si no lo tienen, no firmes.