¿Te preocupa que el caché deje mostrar el idioma equivocado, rompa traducciones o cause redirecciones infinitas en un sitio con WPML o Polylang? Esta guía concreta resuelve cómo configurar cache y compatibilidad para sitios multilingües con WPML/Polylang sin riesgos, con pasos, reglas y ejemplos listos para aplicar.
Puntos clave: lo que debes saber en 1 minuto
Compatibilidad no es automática: muchos plugins de caché necesitan ajustes para detectar idioma (cookie, URL o cabecera). No confiar en valores por defecto.Elige caché que respete Vary/Accept-Language o cookies: WP Rocket, LiteSpeed y Cloudflare ofrecen opciones específicas; comprobar antes en staging.Subdirectorios y subdominios simplifican caché: subdirectorios (/es/, /en/) son más sencillos que cookies de idioma para la mayoría de CDNs y caches.Purgado automático es esencial: la caché debe purgarse al actualizar traducciones (post, strings, menús) para evitar mostrar contenido obsoleto en otro idioma.Prueba en escenarios reales: blog, tienda WooCommerce y web corporativa requieren reglas distintas; seguir checklist evita errores comunes.
¿Quién debe usar WPML o Polylang y quién no?
Principales diferencias prácticas entre WPML y Polylang
WPML es una solución comercial con integración amplia (compatibilidad con muchos builders y plugins premium), gestión centralizada de traducciones y soporte técnico dedicado. Es recomendable para tiendas WooCommerce complejas , agencias y sitios con mucha lógica multilingüe.
Polylang tiene versión gratuita y de pago, es más ligera y fácil de mantener. Es recomendable para blogs, webs corporativas sencillas o cuando se busca minimizar costes.
Cuándo elegir WPML
Sitios con WooCommerce, multilocalización avanzada o necesidad de traducciones profesionales gestionadas desde el backend.
Cuando se requiere purga y sincronización automática de traducciones con plugins de caché y CDNs comerciales.
Cuándo elegir Polylang
Proyectos con presupuesto limitado, blogs o webs estáticas con pocas páginas por idioma.
Cuando se prefiere una estructura más ligera y control manual de traducciones.
Cuándo no usar WPML/Polylang (y alternativas)
Si la web necesita traducciones automáticas puntuales, servicios como TranslatePress o Weglot pueden ser mejores por simplicidad, aunque afectan costes y SEO.
Para prototipos muy simples, usar subdominios separados por idioma con instalaciones diferentes puede simplificar caché pero complica mantenimiento.
Cómo elegir plugins de caché compatibles con WPML
Criterios prácticos de compatibilidad
Soporte de Vary header o cookies de idioma: el plugin debe poder diferenciar caché por cabeceras (Vary: Accept-Language) o por cookies que establezca WPML/Polylang.Purgado automático al guardar traducciones: la caché debe invalidarse cuando se edita una traducción o la original.Compatibilidad probada con WooCommerce: si hay tienda, el plugin debe manejar carritos por idioma sin cachearlos.Documentación y reglas para Nginx/Apache: acceso a snippets listos para usar.
Matriz rápida: compatibilidad y recomendaciones
Plugin de caché
Compatibilidad con WPML/Polylang
Ventaja principal
WP Rocket
Alta (tiene ajustes para idiomas y purga)
Fácil de configurar para principiantes
LiteSpeed Cache
Alta (geolocalización y reglas de Vary)
Mejor rendimiento en servidores LiteSpeed
W3 Total Cache
Media (requiere ajustes manuales)
Flexible pero técnico
Cloudflare (CDN)
Alta si se configuran reglas de caché por ruta o cookie
Distribución global y Edge caching
Reglas básicas para comprobar antes de instalar
Revisar la documentación oficial del plugin y del addon de WPML: https://wpml.org/documentation/support/wp-plugins/
Probar en staging con el idioma por defecto distinto del navegador para detectar Vary/cookie fallidas.
Verificar logs de purga al guardar traducciones.
✉
¿Quieres más información? Escríbenos y te orientamos
Escenarios reales: blogs, tiendas y sitios corporativos multilingües
Blogs multilingües
Recomendación: Polylang + WP Super Cache (o WP Rocket si se puede pagar).
Por qué: los blogs suelen servir páginas estáticas por idioma. Con subdirectorios (/es/, /en/) la caché es simple y el CDN sólo necesita servir rutas distintas. Activar purga al actualizar entradas evita mostrar traducción errónea.
Errores comunes: dejar activos caching de fragmentos que no respetan idioma, o no purgar widgets traducidos.
Tiendas WooCommerce multilingües
Recomendación: WPML + WP Rocket o LiteSpeed Cache (según hosting), con reglas específicas para no cachear páginas de carrito, checkout y endpoints REST.
Por qué: WooCommerce necesita que cookies y sesiones funcionen por idioma; WPML añade metadatos de producto que deben purgarse.
Reglas clave:
- Excluir /cart, /checkout, /my-account de caché.
- Purga automática al actualizar productos o traducciones.
- Asegurar que CDN no cachee cookies del carrito.
Sitios corporativos multilingües
Recomendación: Polylang o WPML según complejidad, Cloudflare o BunnyCDN para assets y un plugin de caché ligero. Preferir subdirectorios para simplificar hreflang y canonical.
Por qué: las páginas suelen ser mayormente estáticas pero con menús y formularios traducidos. Evitar cachear páginas con formularios dinámicos sin validar idioma.
Pros y contras de cachear páginas por idioma
Beneficios de cachear por idioma
Mejora pronunciable en TTFB y LCP : servir HTML pre-renderizado por idioma acelera la entrega.Menos carga en PHP/BD: reduce consultas de traducción on-the-fly.Mejor experiencia global: usuarios reciben contenido en su idioma más rápido.
Riesgos y limitaciones
Duplicación de caché y aumento de almacenamiento: cada idioma duplica objetos en cache y en CDN.Complejidad en purga: si no se purga bien, se muestran traducciones obsoletas o mezcladas.Cabeceras Vary mal configuradas: pueden impedir caché efectivo en el edge.
Costes, riesgos y compromisos de CDNs y object cache
Costes directos
CDN (Cloudflare, BunnyCDN): gastos mensuales según tráfico y requests; Cloudflare tiene plan gratuito útil pero funciones avanzadas (Workers, Page Rules) son de pago.Object cache (Redis/Memcached): coste de servidor (gestión) o servicio gestionado. Mejora consultas de DB pero añade complejidad.
Riesgos operativos
CDN que ignora cookies puede servir idioma equivocado; requiere reglas de cacheo por ruta o cookie.Object cache mal dimensionado provoca stale objects y errores en admin si no se invalida correctamente.
Compromisos técnicos
Usar CDN con soporte para cache keys personalizadas (incluir ruta y cookie de idioma) facilita distinción por idioma.
Implementar purgado por tag cuando el CDN y el plugin lo soportan para invalidar por post_id o idioma.
✉
¿Quieres más información? Escríbenos y te orientamos
Checklist práctico: configurar caché sin romper traducciones
Verificar estructura de idioma: subdirectorios (/es/), subdominios (es.example.com) o parámetros/cookies. Preferir subdirectorios para principiantes.
Instalar plugin de caché recomendado para el caso (WP Rocket o LiteSpeed para ecommerce, WP Rocket o plugin ligero para blogs).
Configurar exclusiones esenciales: /cart, /checkout, /my-account, /wp-json/, /wp-admin/ .
Añadir cookie/cabecera de idioma a la clave de caché o activar Vary: Accept-Language si es fiable.
Activar purga automática al guardar traducciones y al editar posts/menus.
Probar en staging: cambiar idioma y recargar en sesión privada para verificar que cada idioma sirve HTML correcto.
Implementar reglas de Nginx/Apache si es necesario (snippets abajo).
Monitorizar durante 72 horas y revisar logs de purga.
Snippets útiles (Nginx)
Excluir endpoints REST y admin de caché:
location ~* /(? : wp-admin | wp-login . php | wp-json ) {
proxy_pass http : // backend ;
proxy_no_cache 1 ;
proxy_cache_bypass 1 ;
}
Añadir Vary por Accept-Language (si se usa):
add_header Vary Accept-Language;
(Usar sólo si la detección de idioma se basa en encabezados; de lo contrario usar cookie)
Activar purga automática en WP Rocket con WPML
En WP Rocket, en Herramientas -> Opciones avanzadas, añadir la cookie de idioma que usa WPML (ej. 'icl_current_language') a la lista de excepciones de caché.
En WPML -> Soporte, activar «Purgar caché» en la integración si existe.
Probar: editar traducción y comprobar que la URL traducida se purga en la lista de caché de WP Rocket.
Flujo recomendado para cache multilingüe
Flujo de cache para sitios multilingües
🌐
Paso 1 → Estructura por idioma (subdirectorios)
⚙️
Paso 2 → Plugin caché añade clave por ruta + cookie
🧽
Paso 3 → Purgado automático al publicar traducción
☁️
Paso 4 → CDN sirve assets; reglas por cookie/ruta
✅
Resultado → Cada usuario recibe HTML en su idioma sin errores
✉
¿Quieres más información? Escríbenos y te orientamos
Ventajas, riesgos y errores comunes
Beneficios / cuándo aplicar ✅
Aplicar cache por idioma cuando hay tráfico suficiente y páginas estáticas por idioma.
Usar purga automática cuando hay traducciones frecuentes.
Contratar CDN si el público es internacional.
Errores que debes evitar / riesgos ⚠️
No probar cambios en staging.
Configurar Vary sin entenderlo (puede reducir cache hit ratio).
Cachear endpoints AJAX/REST que sirven traducciones dinámicas.
Preguntas frecuentes
¿Cómo detecta WPML el idioma por defecto?
WPML usa la estructura seleccionada (URL, subdominio o cookie). La detección puede venir de la URL o de la cookie icl_current_language.
¿Qué es mejor para caché: cookie de idioma o subdirectorio?
Para principiantes, subdirectorio (/es/) es más seguro y compatible con CDNs; la cookie añade complejidad.
¿Puedo usar Cloudflare gratis con WPML/Polylang?
Sí, pero hay que crear Page Rules o Workers para diferenciar caché por idioma o usar rutas por subdirectorio.
¿Cómo probar que la caché no sirve el idioma equivocado?
Abrir una ventana de incógnito, forzar la URL con /es/ y /en/ y comprobar HTML fuente y cabeceras (X-Cache, Vary, Set-Cookie).
¿Qué reglas Nginx son críticas para multilingüe?
Excluir /wp-admin, /wp-json y añadir add_header Vary Accept-Language si se usa detección por header.
¿Cómo evitar redirecciones infinitas por idioma?
No combinar redirecciones de geolocalización en CDN con redirecciones de plugin; preferir un método de detección único y reglas claras.
¿Cuándo usar object cache (Redis) en multilingüe?
Cuando el sitio genera muchas consultas por traducción o meta; Redis acelera DB pero hay que invalidar claves al actualizar traducciones.
Pasos siguientes
Instalar el plugin de caché recomendado según el tipo de web (WP Rocket para blogs y tiendas pequeñas; LiteSpeed para hosting compatible).
Configurar exclusiones y purga automática según la checklist y probar en staging durante 48-72 horas.
Monitorizar logs y medir TTFB, LCP y errores de idioma; ajustar reglas de CDN o cookie según resultados.
