WPML rompe URLs en WordPress, cómo arreglar
WPML rompe URLs: corrige 404, slugs, idiomas y redirecciones en WordPress con revisiones prácticas y recupera visibilidad cuanto antes.
Si WPML rompe URLs en WordPress, lo más útil suele ser revisar en este orden: estructura de idiomas, enlaces permanentes, traducción de slugs, caché, reglas de reescritura y posibles conflictos con plugins, tema o servidor. En muchos casos, el problema no está en una sola opción, sino en cómo se combinan WPML, los permalinks y la capa de caché o redirección.
La señal más clara es que una o varias versiones por idioma empiezan a devolver 404, redirigen donde no toca, mezclan slugs traducidos o dejan de indexarse correctamente. Para arreglarlo sin tocar a ciegas, conviene validar primero qué tipo de fallo hay, en qué idiomas ocurre y si afecta a entradas, páginas, taxonomías, productos o archivos.
Qué suele pasar cuando WPML rompe URLs en WordPress
Cuando WPML altera la estructura de URLs, el comportamiento puede variar según la configuración multidioma y el tipo de contenido. No siempre se manifiesta igual, y esa diferencia importa mucho para diagnosticar.
- Una URL funciona en el idioma principal, pero devuelve 404 en otro idioma.
- El slug traducido no coincide con la ruta que WordPress espera según sus reglas de reescritura.
- Las páginas redirigen al idioma por defecto aunque la URL del idioma secundario exista.
- Se abren rutas duplicadas, con o sin prefijo de idioma, y eso puede generar señales SEO contradictorias.
- Productos, categorías o taxonomías personalizadas fallan solo en determinadas traducciones.
- Tras una actualización, migración o cambio de dominio, el idioma carga, pero las rutas internas no resuelven bien.
Desde el punto de vista técnico, el problema suele aparecer cuando WordPress, WPML y el servidor no están interpretando igual la misma ruta. Eso puede deberse a reglas de reescritura sin regenerar, slugs sin sincronizar, caché obsoleta, redirecciones heredadas o configuraciones de idioma que han cambiado respecto al estado anterior.
Antes de aplicar cambios, conviene anotar qué URLs fallan, qué idiomas afecta, qué código de respuesta devuelve y si el problema se reproduce con sesión iniciada y sin iniciar sesión. Ese contraste ahorra tiempo y evita arreglos parciales.
Causas más habituales de URLs rotas con WPML
No hay una causa única. En sitios WordPress multidioma, las URLs pueden romperse por varias capas a la vez. Estas son las revisiones más habituales y técnicamente plausibles.
1. Enlaces permanentes desactualizados
WordPress depende de sus reglas de reescritura para resolver URLs amigables. Si se ha cambiado la estructura de idioma, un slug traducido, un tipo de contenido o una taxonomía, puede hacer falta regenerar los permalinks para que WordPress reconstruya esas reglas.
2. Slugs traducidos incoherentes o incompletos
WPML permite traducir contenidos y, según la configuración y la compatibilidad del sitio, también slugs o bases de taxonomías. Si un slug traducido no coincide con lo que espera la ruta final, puede producirse un 404 o una redirección incorrecta. Esto se nota especialmente en páginas hijas, custom post types y categorías de WooCommerce.
3. Configuración de idioma por directorio, subdominio o dominio
Cambiar entre idiomas en directorios, subdominios o dominios distintos puede afectar a la resolución de rutas. Según el servidor, la CDN, el DNS o los certificados, algunas combinaciones necesitan ajustes adicionales para que cada idioma responda correctamente.
4. Caché a varios niveles
Una caché antigua puede servir rutas obsoletas incluso después de guardar los ajustes correctos. Esto puede pasar con plugins de caché, caché del hosting, proxy inverso, CDN o reglas del navegador. En webs multidioma, además, la caché mal segmentada por idioma puede mezclar respuestas.
5. Conflicto con plugins, tema o personalizaciones
Plugins de SEO, redirecciones, seguridad, membresía, filtros de WooCommerce o snippets que manipulan rewrite rules, canonical o detección de idioma pueden alterar el comportamiento esperado. También puede ocurrir con temas que registran tipos de contenido o taxonomías de forma poco compatible.
6. Reglas del servidor o del .htaccess
Si Apache, Nginx o una capa intermedia tienen reglas de redirección antiguas, forzado de slash final, limpieza de parámetros o redirección de idioma por geolocalización, la URL puede resolverse de forma distinta a como WordPress la genera.
7. Migraciones, clonados o cambios de entorno
Tras mover la web entre dominios, staging y producción o cambiar de hosting, pueden quedar rutas guardadas, redirecciones, indexables o cachés asociadas al estado anterior. En multidioma, estos detalles suelen notarse antes porque cada idioma añade más combinaciones posibles de URL.
Cómo revisar la configuración de idiomas, slugs y enlaces permanentes
Antes de tocar código o desactivar extensiones, conviene hacer una revisión ordenada. El objetivo es comprobar si la URL generada por WordPress coincide con la que el sitio realmente sirve.
- Identifica el patrón del fallo. Comprueba si afecta solo a páginas, entradas, productos, categorías, etiquetas, archivos o tipos de contenido personalizados. Si el error solo aparece en una familia de URLs, probablemente la causa está en su registro, su slug base o su traducción.
- Revisa la estructura de idiomas en WPML. Verifica si la web usa idiomas en directorios, subdominios o dominios separados. Si esto ha cambiado recientemente, conviene validar que todas las rutas y redirecciones respondan como se espera en cada idioma.
- Guarda de nuevo los enlaces permanentes. En WordPress, entra en Ajustes de enlaces permanentes y guarda sin necesidad de modificar la estructura. En muchos casos esto fuerza la regeneración de reglas de reescritura.
- Comprueba slugs traducidos. Revisa si el contenido afectado tiene slug distinto por idioma y si la traducción es coherente con la URL final. Conviene validar especialmente categorías, atributos, páginas padre e hijos, y bases de CPT o taxonomías.
- Comprueba la URL canónica y la URL real. Si una página genera una URL y luego responde otra distinta por redirección, ahí ya tienes una pista. La causa puede estar en WordPress, en un plugin de SEO, en reglas del servidor o en una CDN.
- Vacía todas las cachés implicadas. No solo la del plugin de caché. Si hay hosting con caché de página, Varnish, Cloudflare u otra CDN, conviene purgarlo todo antes de concluir que un ajuste no ha funcionado.
- Prueba con un conflicto controlado. Si el fallo persiste, puede ayudar desactivar temporalmente, en entorno seguro, plugins que gestionan SEO, redirecciones, seguridad, caché o URL rewriting. Si hay child theme o snippets, también conviene revisar esa capa.
Si necesitas una referencia general sobre cómo WordPress maneja los enlaces permanentes y la reescritura, la documentación oficial puede servir como base técnica: Customize Permalinks.
| Comprobación | Qué revisar | Señal típica |
|---|---|---|
| Permalinks | Guardar estructura y probar URLs | 404 tras cambios de slugs o idioma |
| Idiomas | Directorios, subdominios o dominios | Redirecciones al idioma incorrecto |
| Slugs | Traducción de rutas y bases | URL generada distinta a la publicada |
| Caché | Plugin, hosting, CDN y navegador | Cambios guardados que no se reflejan |
| Conflictos | Plugins, tema, snippets y servidor | Fallo intermitente o solo en ciertos tipos de URL |
Pasos para arreglar errores 404, redirecciones y conflictos de reescritura
Aquí conviene trabajar con un método práctico. No todas las acciones serán necesarias en todos los sitios, pero este orden suele ayudar a aislar el problema sin introducir más cambios de los necesarios.
- Haz una copia de seguridad o prueba en staging. Si el sitio tiene tráfico o comercio electrónico, es preferible evitar cambios directos en producción.
- Regenera permalinks. Guarda los enlaces permanentes y vuelve a probar las URLs afectadas por idioma. Si el problema era de reescritura no regenerada, aquí puede notarse enseguida.
- Revisa y vuelve a guardar el contenido traducido afectado. En determinadas situaciones, una traducción antigua, un cambio de slug no sincronizado o una relación incorrecta entre original y traducción puede dejar la ruta inconsistente.
- Purge completo de caché. Vacía caché de WordPress, del hosting, de servidor y de CDN. Si existe minificación o reglas automáticas de redirección, conviene comprobarlas también.
- Valida las redirecciones activas. Comprueba si hay redirecciones 301, 302 o reglas automáticas que estén capturando prefijos de idioma, slugs antiguos o rutas sin slash. Muchas incidencias se deben a redirecciones previas que siguen activas después de cambiar la estructura multidioma.
- Descarta conflicto con plugins. Si usas un plugin de redirecciones, SEO, seguridad, optimización o WooCommerce con extensiones, prueba desactivación controlada y temporal. Si al hacerlo la URL vuelve a funcionar, ya tienes un foco claro para afinar compatibilidad.
- Cambia temporalmente a un tema por defecto si el entorno lo permite. Algunos temas registran taxonomías, archivos o slugs propios. Si el fallo desaparece, conviene revisar cómo ese tema declara sus rewrite rules o su integración con WPML.
- Comprueba servidor y CDN. Si WordPress genera bien la URL pero el servidor devuelve otra respuesta, revisa reglas en .htaccess, Nginx, panel del hosting, proxy y CDN. Esto es especialmente importante si el problema afecta solo a una variante con o sin prefijo de idioma.
- Vuelve a probar con códigos HTTP reales. No basta con abrir la página en el navegador. Conviene verificar si responde 200, 301, 302, 404 o 410, y hacia qué destino exacto redirige.
Señales de alerta frecuentes
- La home por idioma funciona, pero no las páginas internas.
- El sitemap muestra una URL y el navegador acaba en otra distinta.
- El slug traducido se ha cambiado, pero las rutas antiguas no redirigen de forma controlada.
- Los productos cargan, pero categorías o atributos devuelven 404.
- El problema solo aparece detrás de la CDN o solo para usuarios no logueados.
Si nada de lo anterior lo corrige, puede hacer falta revisar a nivel más técnico el registro de tipos de contenido y taxonomías, la compatibilidad declarada por los plugins implicados o personalizaciones que filtren URLs, canonical o consultas por idioma. Solucionar el error 404 en WordPress tras migración.
Qué comprobar si el problema afecta al SEO o a WooCommerce
Cuando WPML rompe URLs, el impacto puede ir más allá del error visible en pantalla. Si hay SEO multidioma o tienda online, conviene revisar varias capas adicionales.
SEO técnico multidioma
- Indexación: revisa en Search Console si aumentan los 404, páginas excluidas, soft 404 o redirecciones inesperadas por idioma.
- Sitemap: confirma que las URLs enviadas coinciden con las que responden realmente y que no incluyen rutas antiguas o mezcladas entre idiomas.
- Canonical: comprueba que cada idioma apunte a su versión correcta y no consolide por error hacia el idioma principal.
- Hreflang: si tu configuración lo usa mediante plugin o capa SEO compatible, conviene validar que las URLs referenciadas existan y devuelvan 200.
- Cobertura por idioma: prueba varias URLs reales, no solo plantillas. En webs con miles de páginas, los errores pueden afectar solo a parte del contenido.
WooCommerce y estructuras traducidas
- Productos, categorías, etiquetas y atributos pueden depender de slugs traducidos y de reglas de reescritura específicas.
- Si fallan solo categorías o filtros, conviene revisar taxonomías, bases de archivo y extensiones que añadan filtros por URL.
- Si una ficha de producto carga pero el carrito o checkout redirigen mal por idioma, puede haber interacción con caché, moneda, geolocalización o reglas de redirección.
- Después de actualizaciones de WooCommerce o de sus complementos, es recomendable volver a validar URLs clave por idioma.
En SEO y comercio electrónico, el mayor riesgo no siempre es el 404 inmediato. A veces el problema deja páginas accesibles, pero duplicadas, mal canonicalizadas o servidas en el idioma incorrecto. Eso puede reducir visibilidad orgánica y complicar el rastreo incluso aunque el usuario vea contenido.
Cómo prevenir que vuelva a ocurrir tras una actualización o migración
La prevención en WordPress multidioma no consiste en evitar cambios, sino en introducirlos con validación. Si WPML, WooCommerce, el tema o el entorno cambian, conviene tener un pequeño protocolo de control.
- Actualiza en staging siempre que sea posible. Prueba antes cambios de WPML, WordPress, tema y plugins que toquen URLs o taxonomías.
- Documenta la estructura de idiomas. Anota si trabajas con directorios, subdominios o dominios por idioma y qué reglas adicionales requiere el servidor.
- Mantén inventario de slugs críticos. Categorías principales, páginas de servicio, productos estratégicos y taxonomías deben revisarse después de migraciones o cambios masivos.
- Controla redirecciones heredadas. Una migración o rediseño puede dejar reglas antiguas que entran en conflicto con la estructura actual.
- Purge y validación tras cambios. Después de actualizar, regenera permalinks si procede, purga cachés y prueba URLs clave de cada idioma.
- Supervisa Search Console y logs. Los primeros indicios suelen aparecer ahí antes de que el tráfico caiga de forma visible.
- Evita combinar demasiadas capas que manipulen URLs. Cuantos más plugins gestionen redirecciones, SEO técnico, idioma y caché, más importante es revisar compatibilidad entre ellos.
Mini FAQ rápida
¿Guardar enlaces permanentes puede arreglarlo?
En muchos casos ayuda cuando el origen está en reglas de reescritura desactualizadas, pero no sustituye revisar slugs, redirecciones, caché o conflictos.
¿Por qué falla solo un idioma?
Suele indicar una diferencia en slug traducido, estructura de URL, caché segmentada o redirección específica de esa versión.
¿Puede afectar aunque la página siga cargando?
Sí. Puede haber canonical incorrecto, duplicidad, rutas alternativas indexadas o redirecciones que perjudiquen el SEO multidioma.
En resumen, cuando WPML rompe URLs, lo prudente es no asumir que todo se resuelve con un único ajuste. Conviene revisar permalinks, slugs traducidos, configuración de idiomas, caché, redirecciones y compatibilidad del entorno. Los riesgos más frecuentes son arreglar solo la parte visible, dejar rutas antiguas indexables o no validar cada idioma por separado.
Si el sitio ya ha perdido tráfico, devuelve 404 en masa o combina WPML con WooCommerce, redirecciones y caché avanzada, el siguiente paso razonable suele ser una revisión técnica completa para reparar la incidencia y dejar un mantenimiento WordPress que reduzca recaídas tras futuras actualizaciones o migraciones.
¿Necesitas orientación personalizada?
Te ayudamos a entender tus opciones y el siguiente paso.