Vos URL existants ne sont pas modifiés. Des versions traduites sont ajoutées à côté d'eux, de sorte que rien de ce que vous avez déjà publié ne bouge ou ne casse.
Rien ne change sur vos pages d'origine
example.com/pricing/ continue de fonctionner exactement comme avant, à la même URL, dans la même langue. Universally ajoute example.com/es/pricing/ à côté.
Cela signifie :
- Aucun lien existant, interne ou externe, ne casse
- Aucun classement de recherche existant n'est perturbé, car la page n'a pas bougé
- Votre langue source reste à la racine, sans préfixe
Ce que les visiteurs suivent
Sur une page traduite, les liens internes sont réécrits pour maintenir le visiteur dans sa langue. Depuis /es/pricing/, un lien vers /features/ devient /es/features/, de sorte que la navigation ne retombe pas silencieusement dans la langue source.
Certains chemins ne doivent pas être réécrits, tels que les URL d'assets, les points d'API et les flux. Ceux-ci sont listés sous Exclure la localisation des liens. Voir Exclure la localisation des liens.
Comment les visiteurs accèdent à une page traduite
Via le sélecteur de langue, ou par un lien vers l'URL traduite, ou depuis les résultats de recherche, car les pages traduites sont indexées en propre.
Il n'y a pas de redirection automatique basée sur la langue du navigateur. Rien ne lit la préférence linguistique du navigateur, donc un premier visiteur arrivant à votre URL racine obtient votre langue source, quelle que soit la demande de son navigateur. Si vous souhaitez une redirection basée sur la langue, elle doit être implémentée à votre propre niveau de périphérie ou de serveur.
Ceci est délibéré plutôt qu'une lacune : la redirection linguistique automatique est une source fréquente de problèmes, car elle remplace un choix explicite et les robots d'exploration voient quelque chose de différent des utilisateurs.
La langue qu'un visiteur a choisie est mémorisée
Le propre choix d'un visiteur est une autre affaire, et voici le comportement à connaître avant de configurer un cache.
La visualisation de toute URL traduite stocke cette langue dans un cookie universally_lang pendant 30 jours. Tant qu'il est défini, une requête vers une URL sans préfixe de langue est redirigée vers la même page dans la langue stockée. Ainsi, un visiteur de retour sur votre URL racine n'obtient pas la langue source, il obtient la sienne.
Le chemin du retour est le lien de langue source du sélecteur, qui porte ?universally_switch=source. Cela efface le cookie et renvoie le visiteur à l'URL sans préfixe. Un simple lien vers l'URL source ne l'efface pas, donc la redirection se produit à nouveau.
La redirection est ignorée pour les chemins système de WordPress (/wp-admin/, /wp-json/, wp-login.php et le reste), pour tout ce qui ressemble à un fichier (sitemap.xml, robots.txt, favicon.ico), et pour les chemins sous Exclure les pages.
Parce que la réponse à une URL sans préfixe dépend maintenant du visiteur, c'est le seul comportement d'Universally qu'un cache de page complète casse réellement. Voir Mise en cache et CDN.
Redirections que Universally effectue
Cinq, et il est bon de les connaître lorsque vous déboguez un 301 ou 302 inattendu :
| Redirection | Statut |
|---|---|
| Un chemin exclu demandé à son URL traduite, envoyé à la page d'origine, chaîne de requête préservée | 301 |
/es sans la barre oblique finale, envoyé à /es/ |
301 |
| Une URL sans préfixe pour un visiteur avec une langue stockée, envoyé à cette langue | 302 |
?universally_switch=source, envoyé à l'URL propre après avoir effacé la langue stockée |
302 |
| Toute redirection WordPress sur une page traduite conserve le préfixe de langue sur sa destination | inchangé |
Voir Exclure des pages pour le premier cas.
Si vous changez une URL sur votre site
Sur WordPress, cela est en grande partie géré pour vous. Le préfixe de langue est supprimé avant que WordPress ne traite la requête, donc une redirection existante de /old-page/ vers /new-page/ s'applique aussi pour /es/old-page/, et le préfixe est remis sur la destination : le visiteur atterrit sur /es/new-page/, toujours en espagnol. Cela couvre les plugins de redirection et tout ce qui redirige via WordPress.
Deux cas nécessitent toujours leur propre règle pour le chemin préfixé :
- Redirections dans la configuration de votre serveur web ou de votre CDN, qui voient
/es/old-page/tel qu'il arrive - Redirections écrites en PHP avec un appel
header()brut plutôt que via WordPress