Migrar de WPML no es difícil técnicamente. Lo difícil es no perder posiciones por el camino, y ahí es donde casi todas las migraciones se tuercen: no por las traducciones, sino por las URL.
Esta guía va en el orden que funciona, con lo que sobrevive, lo que se rompe y lo que hay que hacer antes de tocar nada.
Al grano: el riesgo de esta migración no está en el contenido: los textos viven en la tabla de entradas de WordPress y sobreviven casi siempre. El riesgo está en los slugs y las URL. Si las direcciones cambian y no hay redirecciones 301 una a una, el tráfico tarda meses en volver — y a veces no vuelve del todo.
Antes de nada: ¿de verdad necesitas migrar?
Merece la pena preguntárselo, porque una migración cuesta entre un día y una semana según el tamaño. Los motivos que la justifican:
- El precio anual, si el presupuesto no da para renovar.
- El peso, si tienes un sitio grande con muchos idiomas y las consultas se notan.
- El ritmo, si traducir pieza a pieza no te está dando abasto.
Los motivos que no la justifican: que alguien te haya dicho que hay algo mejor, o que la configuración inicial te pareciera densa. WPML es un producto sólido y lo que cuesta caro es cambiar sin necesidad. Si aún estás decidiendo, mira antes las alternativas reales a WPML.
Qué sobrevive y qué no
| Elemento | Sobrevive | Por qué |
|---|---|---|
| Textos de entradas y páginas | Sí, casi siempre | Están en wp_posts, no en tablas de WPML |
| Productos WooCommerce | Sí, el contenido | Son entradas; los atributos, no |
| Relación entre idiomas | Hay que rehacerla | Cada plugin la guarda a su manera |
| Slugs traducidos | Riesgo alto | Aquí se pierden posiciones |
| Menús por idioma | Casi nunca | Cuenta con rehacerlos a mano |
| Campos personalizados | Depende | ACF suele ir; los del tema, no |
| Cadenas del tema y plugins | No | Están en las tablas de WPML |
| Widgets traducidos | No | Su configuración es de WPML |
El procedimiento, paso a paso
Paso 0. Copia de seguridad completa
Archivos y base de datos, las dos cosas, y comprueba que la copia se restaura. No es un formalismo: WPML guarda datos en varias tablas propias y una migración a medias deja el sitio en un estado difícil de razonar.
Paso 1. Inventario de URL — el paso que se salta todo el mundo
Antes de tocar nada, guarda la lista de todas tus URL indexadas. Es lo que te va a permitir comprobar después qué se ha roto.
- En Search Console, exporta el informe de rendimiento por páginas de los últimos 12 meses.
- Descarga también tu
sitemap_index.xmly guarda todas las URL. - Guarda los dos ficheros. Esta es tu lista de control.
- Anota aparte las 20 URL que más tráfico traen: son las que hay que verificar una a una al terminar.
Consejo: haz la migración en una copia de pruebas, no en producción. Casi todos los alojamientos decentes crean un staging con un clic. Migras ahí, compruebas, anotas todo lo que se rompe, y solo entonces repites el proceso en producción con la lista de problemas ya resuelta. Duplicas el trabajo y te ahorras el susto.
Paso 2. Elige destino y comprueba que hay ruta
La migración más transitada es WPML → Polylang, porque existe un plugin de migración específico que lee las tablas de WPML y reconstruye las relaciones como taxonomías de Polylang. Es la ruta con menos sorpresas.
Hacia TranslatePress no hay una herramienta equivalente, porque las arquitecturas no se parecen: WPML enlaza entradas gemelas, TranslatePress guarda cadenas. Ahí la migración es en gran parte manual.
Paso 3. Migra, con WPML todavía activo
No desinstales WPML antes de migrar: sus tablas son la fuente de datos. El orden correcto es instalar el destino, ejecutar la migración, comprobar, y solo entonces desactivar WPML.
Paso 4. Comprueba los slugs, uno a uno
Este es el momento crítico. Coge tu lista de las 20 URL con más tráfico y ábrelas todas. Tres resultados posibles:
- Responde 200 con el contenido correcto. Perfecto.
- Responde 404. La URL cambió. Hay que redirigir.
- Responde 200 con el contenido equivocado. La relación entre idiomas se rehízo mal. Corrígela antes de seguir.
Paso 5. Redirecciones 301 para todo lo que cambió
Para cada URL antigua que ya no responde, una redirección 301 a su equivalente nueva. No a la portada: a la página equivalente. Una redirección masiva a la home le dice a Google que ese contenido ya no existe, y pierdes lo que tenía.
Cualquier plugin de redirecciones sirve. Si son muchas, casi todos permiten importar un CSV con las dos columnas.
Ojo: monta las redirecciones en el mismo despliegue en que cambian las URL, no al día siguiente. Cada día con 404s en páginas indexadas cuesta posiciones que tardan semanas en recuperarse. Si la lista es larga, prepárala en la copia de pruebas y súbela a la vez que el cambio.
Paso 6. Rehacer lo que no migra
Por orden de impacto:
- Menús por idioma. Casi seguro que hay que rehacerlos.
- Cadenas del tema y plugins. Estaban en las tablas de WPML. Toca retraducirlas, con Loco Translate o con lo que traiga el nuevo plugin.
- Widgets y textos del personalizador. Revisar uno a uno.
- Metadatos SEO por idioma. Comprueba que los títulos de Yoast siguen traducidos.
Paso 7. Verificación SEO
Antes de dar la migración por buena:
- Hreflang. Ctrl+U en una página de cada tipo y comprueba que hay una línea por idioma, recíproca. Detalles en hreflang con Yoast SEO.
- Sitemap. Que vuelva a listar todos los idiomas, y vuelve a enviarlo en Search Console.
- Rutas duplicadas. Que no haya quedado la misma página respondiendo por dos direcciones.
- Cobertura en Search Console. Vigila los 404 durante las dos semanas siguientes: ahí aparece lo que se te pasó.
La revisión completa está en 9 errores de SEO multiidioma.
La alternativa que casi nadie considera
Si tu motivo para migrar es el ritmo o el precio, hay una vía que evita reconstruir las relaciones entre idiomas: volver a traducir desde el contenido original.
Suena peor de lo que es. Con traducción automática masiva, retraducir trescientas páginas es un proceso desatendido de minutos, no un proyecto de semanas. Y te libra de arrastrar relaciones a medias hechas por una herramienta de migración.
WP-Translate encaja bien en este escenario: lanzas la traducción de todo el sitio de una vez, marca cada pieza como pendiente de revisar, y guarda todo en tu base de datos con su URL por idioma y su hreflang. Traduce también las cadenas del tema y los plugins, que es justo lo que no migra desde WPML. Es pembayaran tunggal —89 €, 169 € o 289 € según el número de sitios— en lugar de la renovación anual.
Sigue habiendo que cuidar los slugs y las redirecciones: eso no lo evita ningún plugin. Puedes probarlo en tu copia de pruebas con la versión gratuita antes de decidir la ruta.
Preguntas frecuentes
¿Cuánto se tarda?
Una web de treinta páginas y dos idiomas, una tarde. Una tienda con quinientos productos y cuatro idiomas, una semana contando pruebas y verificación. La parte lenta nunca es la migración: es comprobar.
¿Pierdo posiciones seguro?
No, si las URL no cambian o si cada cambio lleva su 301. Las caídas que se ven en estas migraciones vienen casi siempre de 404s que nadie detectó a tiempo.
¿Puedo tener WPML y el nuevo plugin activos a la vez?
Solo durante la migración, y con cuidado: los dos gestionan URL y se pisan. En cuanto termines y verifiques, desactiva WPML.
¿Y si la migración sale mal?
Restauras la copia del paso 0. Por eso es el paso 0 y por eso hay que comprobar que se restaura antes de empezar.
Seguir leyendo
Esta pieza forma parte de la guía de WordPress multiidioma, donde está el recorrido completo: estructura de URL, elección de plugin, traducción automática, SEO y presupuesto.
- cambiar el idioma de WordPress — Cambiar el idioma de WordPress (y por qué no es lo mismo que traducir tu web)
- cómo traducir un plugin de WordPress — Loco Translate, archivos .po y cuándo no sirve
- poner WooCommerce en español — Cómo poner WooCommerce en español del todo (incluidos los correos y el checkout)