Los equipos llegan a esta decisión por tres razones que se repiten: el editor de WordPress va lento incluso en servidores decentes, el panel está saturado de plugins que nadie recuerda haber instalado, y las Core Web Vitals no mejoran por mucho que se cambie de tema. Migrar a una arquitectura headless no es una bala de plata, pero sí devuelve control sobre el rendimiento, la seguridad y el flujo editorial. Lo que sigue es la receta que aplicamos cuando un cliente nos pide salir de WordPress sin perder posiciones en buscadores ni meses de trabajo de redacción.
-
Auditoría. Antes de tocar nada, inventariamos todo: tipos de contenido (posts, páginas, custom post types), campos personalizados (ACF, Meta Box), taxonomías, shortcodes generados por plugins, número total de entradas y el reparto por autor. Si hay 12.000 posts y la mitad usa un shortcode de un plugin descontinuado, eso condiciona el plan. Documentamos cada uno en una hoja con su recuento y su destino en el nuevo sistema.
-
Elegir stack. Para sitios con redacción frecuente y varios autores recomendamos Next.js con un CMS headless tipo Sanity o Contentful. Para blogs técnicos con uno o dos editores, Markdown estático más Decap CMS es más barato, más rápido y se versiona en Git. La regla práctica: si los editores no son técnicos y publican a diario, paga el CMS; si son devs o publican semanalmente, basta con MD.
-
Exportación. Usamos la WP REST API para extraer JSON limpio o WXR cuando hay que conservar metadatos. Los puntos de dolor habituales son tres: los IDs de adjuntos en el contenido, los shortcodes de oEmbed que sólo WordPress resuelve, y el JSON de bloques Gutenberg que viene mezclado con HTML. Escribimos un transformador que normaliza todo a Markdown o al esquema del CMS de destino.
-
Mapa de URLs. Listamos cada URL pública del sitio actual, decidimos cuál es la canónica en el nuevo, y preparamos el plan de redirecciones 301. Sin este paso se pierde tráfico orgánico durante meses. El mapa va a un CSV con tres columnas: origen, destino y código de respuesta esperado.
-
Medios. Las imágenes pueden quedarse en wp-content/uploads detrás de una redirección, o moverse a S3 o Cloudflare R2 reescribiendo los srcset. Si el sitio supera unos cientos de megas, mejor mover y servir desde CDN: la mejora en LCP suele ser inmediata.
-
Periodo en paralelo. Levantamos el nuevo sitio en staging.dominio.com con robots.txt en noindex, damos acceso a los editores y dejamos que prueben durante dos o tres semanas. Es el momento de cazar bugs sin presión.
-
Cutover. Cambiamos el DNS en una franja de bajo tráfico, validamos el sitemap nuevo en Search Console y solicitamos reindexación. Las primeras 48 horas vigilamos rastreo y errores 404 con detalle.
-
Formación editorial. Hacemos una sesión grabada con el nuevo CMS, documentamos el flujo en un README dentro del repo o en Notion y dejamos contactos claros para soporte.
Lo que no migramos: hilos de comentarios de hace diez años, páginas de categorías vacías y enlaces de afiliados rotos. Es la mejor oportunidad para tirar lo que no aporta.