Référencement multilangue: comment nommer les pages ?

Bonjour,

Une question tout bête, pour améliorer le référencement d'un site multilangue, est ce qu'il vaut mieux:
- utiliser un même nom de page quelque soit la langue (on change uniquement la balise "lang" des entetes)
- utiliser un nom de fichier différent par langue (index_fr.php, index_en.php)
- utiliser un dossier différent par langue (/fr/index.php, /en/index.php)
- une autre solution ?
Dans tous les cas, la langue par défaut serait celle du navigateur ou l'anglais si pas de correspondance. Et la langue serait stockée dans une variable de session.

Merci pour votre aide

Marco

Bonjour,

J'ai une certaine préférence pour un dossier différent par langue. Mais peu importe la solution retenue, il faut que le site puisse être parcouru sans variable de session (sans cookie) et laisser le choix à l'utilisateur de changer de langue comme il le souhaite. La langue du navigateur n'est pas toujours celle de l'utilisateur.

Je dirai "autre", le sous domaine (si on garde le même domaine) me semble de loin la meilleur solution.

Merci Tony,

L'internaute peut changer de langue quand il le souhaite durant la visite du site, mais lorsqu'il arrive dans le site, je ne lui propose pas le choix de la langue, je prend la langue de son navigateur, si je la trouve dans la liste des langue gérées par le site, je l'utilise, sinon, je prend l'anglais. Considérant ainsi:
- que l'immense majorité des internautes utilisent un navigateur dans la langue qu'il préfère
- que faute de mieux, l'anglais est la langue qu'il a le plus de chance de connaitre.
C'est arbitraire, mais ca me parait valable comme raisonnement.

Et ma question, n'était pas par rapport aux visiteurs, mais par rapport aux moteurs de recherche.

merci pour ton aide

Marco

Bien vu Kenor..j'y avais pas pensé...maitenant faut que je vois pour l'adapter à mon outil.

Merci pour cette bonne idée

Marco

Bonsoir,

Pour être un peu précis, «la langue du navigateur» ça n'existe pas en développement web. L'information à laquelle on a éventuellement accès c'est un en-tête HTTP, Accept-Language, généralement envoyé par les navigateurs web. Les utilisateurs peuvent personnaliser cette information dans les préférences du navigateur, et ça n'a pas d'influence sur la langue de l'interface du navigateur.

En ce qui concerne les moteurs de recherche:
- Je ne crois pas que leurs robots fassent des requêtes avec en-tête Accept-Language. Donc ils voient la langue par défaut.
- Pour éviter que les autres versions linguistiques soient ignorées, il faut donc inclure des liens vers ces versions et bien sûr chaque version linguistique d'un document doit avoir sa propre URL.
- À partir du moment où les différentes versions linguistiques sont sur un même sous-domaine (ou sur le domaine racine), peu importe que la convention de nommage soit du type /<LANG>/machin ou /machin_<LANG>.bidule ou encore /machin?lang=<LANG>. Ça n'a pas d'impact particulier.
- Par contre le fait de rester sur le même domaine/sous-domaine ou bien d'utiliser des sous-domaines ou des domaines différents, ça peut avoir un impact. Là c'est des questions d'optimisation et ça dépend pas mal du site...

Merci fvsch,

Effectivement j'utilise Accept-Language.
J'avoue ne pas me poser de question méta-physique sur le sujet.
Ce que je sais, pour l'avoir testé à maintes reprises, c'est que mon site s'affiche en anglais avec un navigateur en anglais, et en Français avec un navigateur en Français.
Après, les mecs qui vont modifier la langue dans les préférences ne m'intéresse pas (en terme de %).

Pour les moteurs, j'ai pas tout compris...


Marco

C'est pas de la métaphysique, c'est le B.A.-ba de la programmation. Tu as un input (Accept-Language) qui peut correspondre à des valeurs que tu attends, être plus complexe que dans le cas idéal, ou alors vide. Tu as une autre donnée, à savoir les attentes du visiteur, et cette donnée est 1) impossible à connaitre précisément et 2) ne correspond pas forcément à l'input reçu.

À toi de mettre en place un mécanisme qui gère les différents cas de figure. Un peu comme si tu codais une classe dans une API et que les données en input pouvaient être tout ou n'importe quoi: à toi de prévoir ce qu'il faut en documentation et en gestion des erreurs, histoire de hmm faire bien ton boulot.

Donc là c'est la même logique de base, et ça demande la même conscience professionnelle si on veut faire les choses bien. Heureusement il existe un certain nombre de bonnes pratiques qui peuvent te servir de repère, parmi lesquelles:
- Une version linguistique = une URL.
- Fournir des outils de navigation pour accéder aux différentes versions (utile aux visiteurs humains et aux robots).
- Si l'utilisateur demande une URL qui correspond à une version linguistique précise, ne pas le rediriger vers une version différente sans son consentement. (Un bandeau «ce contenu est disponible en ...» avec un lien qui va bien, c'est une bonne solution.)
- Certaines pages peuvent jouer le rôle de page de triage et rediriger automatiquement vers une version linguistique précise (en se basant sur Accept-Language). Par exemple pour un site bilingue anglais/français la page d'accueil à l'adresse / peut rediriger vers /fr/ ou /en/, et sur ces deux pages d'accueil localisées on proposera un lien vers l'autre page d'accueil (et jamais vers /).
- Stocker l'information «on va servir telle version linguistique à cet utilisateur» en cookie ou variable de session est une technique possible, mais elle est souvent contre-productive. Une bonne structure d'URLs et un bon mécanisme de navigation suffit et aura moins d'effets secondaires indésirables (visiteur qui a l'impression que le site ne fait pas ce qu'il a demandé).

Bonjour,

Marvin Le Rouge, à noter que pifoux a bien précisé au début du sujet ceci :

pifoux a écrit :
L'internaute peut changer de langue quand il le souhaite durant la visite du site, mais lorsqu'il arrive dans le site, je ne lui propose pas le choix de la langue, je prend la langue de son navigateur, si je la trouve dans la liste des langue gérées par le site, je l'utilise, sinon, je prend l'anglais.

Merci fvsch pour tes explications..après 15 ans de pratique en indépendant...j'ai encore appris des choses.
Mais j'ai mal exposé ma question au départ, car je n'ai pas de problème avec les internautes. Mon système d'imposer une langue au départ me va très bien et comme l'a re précisé Tony, je laisse toujours le choix à l'internaute dans les pages du site.
Je suis pour la simplification des choses pour moi et pour l'internaute.

Ce que je voulais c'était connaitre les solutions pour que mon site multilingue soit correctement référencé par les moteurs de recherche.
En fait, j'avoue que j'avais une petite idée sur la question (utiliser un dossier par langue), mais je voulais être sur que c'était la meilleure.
Et grâce à vous, j'ai découvert la solution des sous domaines...Tellement évidente que je la voyais pas !!

Merci à tous

Marco

Plus d'infos.

pifoux a écrit :
Et grâce à vous, j'ai découvert la solution des sous domaines...Tellement évidente que je la voyais pas !!

Attention, elle n'est pas forcément plus intéressante que celle des dossiers (enfin, des URL sur un même domaine commençant par /<LANG>/). Ça va vraiment dépendre des projets.
Il y a aussi la solution d'avoir un domaine avec ccTLD spécifique pour chaque langue. Là aussi avec des avantages et inconvénients.

Merci Patidou (encore !)

Très bien l'article..juste ce qu'il me fallait.
En résumé:
- Google se fout des attributs Lang dans les entêtes
- Utiliser des URLs spécifiques: www.xxxx.com/fr/index.php ou fr.xxx.com/index.php
- Traduire les nom des pages: Helloworld.html > Bonjourmonde.html (attention aux caractères spéciaux)
- Permettre le changement de langue dans toutes les pages
- Eviter les redirections automatiques basées sur la détection automatique de la langue du visiteur
- Travailler en UTF-8
- Eviter d'utiliser plusieurs langues dans la même page

Perso, je fais tout bien, sauf la redirection...et je n'ai jamais eu de problème de référencement majeur.
Malgré tout, je vais développer une page de choix de langue que je mettrai devant chaque page si nécessaire (début de session)...Ensuite ca sera le client qui décidera si il souhaite l'appliquer ou non

Encore merci à tous

Marco