Tus URLs existentes no se modifican. Se agregan versiones traducidas junto a ellas, por lo que nada de lo que ya hayas publicado se mueve o se rompe.
Nada cambia en tus páginas originales
example.com/pricing/ sigue funcionando exactamente como antes, en la misma URL, en el mismo idioma. Universally agrega example.com/es/pricing/ junto a ella.
Eso significa:
- Ningún enlace existente, interno o externo, se rompe
- Ningún ranking de búsqueda existente se ve alterado, porque la página no se movió
- Tu idioma de origen permanece en la raíz, sin prefijo
Qué enlaces sigue un visitante
En una página traducida, los enlaces internos se reescriben para mantener al visitante en su idioma. Desde /es/pricing/, un enlace a /features/ se convierte en /es/features/, por lo que la navegación no regresa silenciosamente al idioma de origen.
Algunas rutas no deben reescribirse, como las URL de activos, los puntos de conexión de API y los feeds. Esas se enumeran en Excluir localización de enlaces. Consulta Excluir localización de enlaces.
Cómo los visitantes llegan a una página traducida
A través del selector de idioma, o mediante un enlace a la URL traducida, o desde los resultados de búsqueda, ya que las páginas traducidas se indexan por derecho propio.
No hay redirección automática basada en el idioma del navegador. Nada lee la preferencia de idioma del navegador, por lo que un visitante que llega por primera vez a tu URL raíz recibe tu idioma de origen, sin importar lo que solicite su navegador. Si deseas una redirección basada en el idioma, debe implementarse en tu propia capa de borde o servidor.
Esto es deliberado en lugar de una omisión: la redirección automática de idioma es una fuente común de problemas, porque anula una elección explícita y los rastreadores de búsqueda ven algo diferente de los usuarios.
Se recuerda el idioma que eligió un visitante
La propia elección de un visitante es un asunto diferente, y este es el comportamiento que debes conocer antes de configurar una caché.
Ver cualquier URL traducida almacena ese idioma en una cookie universally_lang durante 30 días. Mientras esté configurada, una solicitud a una URL sin prefijo de idioma se redirige a la misma página en el idioma almacenado. Por lo tanto, un visitante que regresa a tu URL raíz no recibe el idioma de origen, sino el suyo.
El camino de regreso es el enlace de idioma de origen del selector, que lleva ?universally_switch=source. Eso borra la cookie y devuelve al visitante a la URL sin prefijo. Un enlace simple a la URL de origen no la borra, por lo que la redirección vuelve a ocurrir.
La redirección se omite para las rutas del sistema de WordPress (/wp-admin/, /wp-json/, wp-login.php y el resto), para cualquier cosa que parezca un archivo (sitemap.xml, robots.txt, favicon.ico), y para las rutas en Excluir páginas.
Debido a que la respuesta en una URL sin prefijo ahora depende del visitante, este es el único comportamiento de Universally que una caché de página completa realmente rompe. Consulta Caché y CDN.
Redirecciones que realiza Universally
Cinco, y vale la pena conocerlos cuando depuras un 301 o 302 inesperado:
| Redirección | Estado |
|---|---|
| Una ruta excluida solicitada en su URL traducida, enviada a la página original, cadena de consulta conservada | 301 |
/es sin la barra final, enviada a /es/ |
301 |
| Una URL sin prefijo para un visitante con un idioma almacenado, enviada a ese idioma | 302 |
?universally_switch=source, enviada a la URL limpia después de borrar el idioma almacenado |
302 |
| Cualquier redirección de WordPress en una página traducida mantiene el prefijo de idioma en su destino | sin cambios |
Consulta Excluir páginas para la primera.
Si cambias una URL en tu sitio
En WordPress, esto se maneja en su mayor parte. El prefijo de idioma se elimina antes de que WordPress procese la solicitud, por lo que una redirección existente de /old-page/ a /new-page/ también se activa para /es/old-page/, y el prefijo se vuelve a colocar en el destino: el visitante aterriza en /es/new-page/, todavía en español. Eso cubre los plugins de redirección y cualquier otra cosa que redirija a través de WordPress.
Dos casos aún necesitan su propia regla para la ruta con prefijo:
- Redirecciones en la configuración de tu servidor web o CDN, que ven
/es/old-page/tal como llega - Redirecciones escritas en PHP con una llamada
header()directa en lugar de a través de WordPress