Solucionar problemas
Polylang y LiteSpeed Cache al detectar el idioma del navegador
Polylang puede redirigir la página de inicio según el idioma preferido del navegador. Al combinar ese comportamiento con una caché de página, primero hay que comprobar si las distintas respuestas se almacenan de forma separada; una prueba aislada con la opción activada no demuestra que LiteSpeed Cache se haya deshabilitado.
Confirmar el comportamiento
- Anota la URL de inicio y los idiomas configurados.
- Prueba con dos perfiles limpios que tengan idiomas preferidos diferentes y no conserven la cookie de idioma de Polylang.
- Revisa en cada respuesta las cabeceras de LiteSpeed Cache y la URL final. Repite la visita para distinguir un primer
missde una respuesta cacheada. - Desactiva temporalmente la detección en staging y repite exactamente las mismas peticiones.
Si las cabeceras o el resultado cambian de forma consistente, ya tienes una comparación útil. Si no cambian, revisa antes exclusiones de caché, cookies y otras reglas de redirección.
Elegir la solución
- Si no necesitas detectar el idioma del navegador, desactiva Detectar el idioma del navegador para el idioma de las nuevas visitas en Idiomas > Ajustes. Los usuarios podrán seguir eligiendo idioma mediante el selector.
- Si necesitas la detección, conserva la función de Polylang y configura una variación o exclusión de caché compatible con la cookie y las URLs de idioma utilizadas por tu web. En LiteSpeed, tras confirmar que Polylang utiliza la cookie
pll_language, una variación por cookie puede declararse conRewriteRule .* - [E=Cache-Vary:pll_language]; hazlo primero en staging y consulta la documentación oficial de Cache Vary.
No sustituyas Polylang por una redirección genérica basada en Accept-Language. No es un comportamiento equivalente: puede ignorar la preferencia ya elegida por el visitante y, sin una estrategia de variación validada, almacenar o servir un idioma incorrecto desde caché.
Verificar el funcionamiento
Vacía la caché una vez después de cambiar la configuración. Repite las pruebas con perfiles limpios, comprueba que la elección manual de idioma se conserva y confirma que nunca se entrega contenido de un idioma bajo la URL de otro. Las cabeceras pueden variar según el servidor; compáralas con las que mostraba tu instalación antes del cambio.
Probar también la primera visita
Una visita sin cookie y otra con pll_language ya elegida no son el mismo caso. Prueba ambas, además de una URL explícita de cada idioma. La variación por cookie no separa por sí sola dos primeras visitas sin cookie que envían distintos Accept-Language.
Comprueba también las capas de caché del CDN, si existen. Conserva enlaces de idioma rastreables y URLs estables; una redirección según el navegador no sustituye a esas páginas ni a su configuración SEO. No des por válida una mejora de velocidad si muestra a un visitante la respuesta de otro idioma.
También te puede ayudar
- Errores 404 en elementos estáticos ralentizan la navegación Detecta recursos estáticos ausentes que disparan PHP y consumen CPU, los sirve como 404 ligeros y gu...
- WordPress 6.7, las traducciones no funcionan correctamente Documenta el fallo histórico de traducciones de WordPress 6.7 y orienta los casos actuales hacia ver...
- Aprender a depurar un error de WordPress Explica cómo leer un error fatal de WordPress, distinguir lo que demuestra de sus posibles causas y...
- Cómo solucionar el error cURL 60 de certificado SSL en WordPress Cómo diagnosticar y resolver el error cURL 60 de WordPress sin desactivar la verificación de certifi...
¿Algo no cuadra o ha cambiado? Cuéntanoslo y lo revisamos.