Comment optimiser un site en plusieurs langues pour les moteurs de recherche ?

Publié le 10 juin 09 à 08:28 | Catégorie : Développement Web | 26 commentaires

Hitomi Studio n’a pas pour objectif de travailler avec des clients étrangers pour le moment, mais nous envisageons néanmoins de mettre en place une version anglaise de son site très bientôt. Cross Meter, l’application Air pour les propriétaires de boutiques Magento que nous sommes en train de concevoir, a en effet vraiment une portée internationale.

Et il serait dommage que les visiteurs anglo-saxons en provenance de Cross Meter et arrivant sur le site d’Hitomi Studio se retrouvent avec un contenu uniquement en français. Du coup, comment faire pour internationaliser ce dernier, surtout en prenant en compte les problèmes de référencement ?

Détection de la langue

Il existe tout d’abord différentes méthodes pour détecter la langue d’un visiteur :

  1. Analyser l’entête Accept-Language de la requête HTTP. Cette dernière contient en effet la liste des langues préférées de l’utilisateur, classée par ordre de priorité.
  2. Utiliser l’adresse IP de l’utilisateur pour déterminer dans quel pays il se trouve et en déduire la langue (il existe des bases de données pour effectuer ce genre de correspondances).

Ensuite, plusieurs stratégies sont envisageables. Soit le site va servir de manière totalement transparente le contenu dans la langue détectée, soit il va servir la langue par défaut et alerter l’utilisateur (grâce à un simple message) sur la disponibilité d’une version dans la langue qui a été détecté. Dans tous les cas, il faut prévoir sur son site une option pour que l’utilisateur puisse changer la langue de lui-même.

Pas de modification des urls

Dans ce premier cas de figure, la langue du visiteur est détectée et le contenu est servi en fonction de cette langue, sans le rediriger sur une page ou un domaine spécifique :

  • http://www.hitomistudio.com/company

Avantages
Une seule url à communiquer (.com)

Inconvénients
Le contenu de la langue secondaire n’est pas indexé

Noms de domaine séparés

Dans ce cas, il y aura un site en .com avec le contenu anglais et un site en .fr avec le contenu en français. Coca-Cola utilise par exemple cette stratégie (voir son site italien, français, …) :

  • http://www.hitomistudio.fr/societe
  • http://www.hitomistudio.com/company

Avantages
Les deux sites seront indexés correctement et indépendamment
C’est l’approche qui semble la plus logique

Inconvénients
Il faut communiquer sur la bonne url suivant les interlocuteurs
La position des sites dans les résultats des moteurs de recherche ne sera pas identique

Nom de domaine commun avec sous-domaines séparés

Lorsque le visiteur arrive sur le site en .com, il est automatiquement redirigé sur le sous-domaine de la langue détectée. C’est l’approche adoptée par exemple par Yahoo :

  • http://fr.hitomistudio.com/societe
  • http://en.hitomistudio.com/company

Avantages
Une seule url à communiquer (.com)
Un seul site est indexé et visible dans les résultats des moteurs de recherche

Inconvénients
L’espace de nommage des sous-domaines est pollué

Urls avec identifiant de la langue

Lorsque le visiteur arrive sur le .com, il est automatiquement redirigé sur une url comportant l’identifiant de la langue détectée. IBM a choisi cette méthode :

  • http://www.hitomistudio.com/fr/societe
  • http://www.hitomistudio.com/en/company

Avantages
Une seule url à communiquer (.com)
Un seul site est indexé et visible dans les résultats des moteurs de recherche

Inconvénients
Les urls sont plus longues et plus complexes

Le système de la page de garde

L’idée ici est simplement de mettre en place une page de garde (sur le .com) qui permettra au visiteur de choisir le pays et la langue souhaités. En fonction de son choix, il se retrouvera donc par exemple sur la version anglaise ou française. Un cookie est créé avec cette information, ce qui permettra de court-circuiter cette page lors de ses prochaines visites. Ce système peut s’appliquer quel que soit la stratégie adoptée et permet ainsi de ne communiquer que sur une seule url. Air Canada et Coca-Cola ont ainsi fait ce choix.

A ne pas oublier

Cet article se focalise surtout sur le schéma d’urls à mettre en place. Outre le titre et le contenu lui-même, il ne faut pas oublier que d’autres paramètres doivent également être modifiés en fonction de la langue utilisée :

  • Attributs de la balise XHTML précisant la langue de la page : 
    <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr” lang=”fr“>
  • Metatag précisant la langue du contenu : 
    <meta http-equiv="content-language" content="fr-FR” />
  • Metatag contenant la description de la page : 
    <meta name="description" content="création de sites ecommerce …” />
  • Metatag contenant la liste des mots-clés de la page : 
    <meta name="keywords" content="boutique, vente en ligne, …” />
  • Tout autre metatag dont le contenu doit être localisé : 
    <meta name="copyright" content="© 2009, tous droits réservés” />

Et bien sûr, il faut que les urls elles-mêmes soient localisées. On aura par exemple pour le site anglais :

  • http://www.hitomistudio.com/company
  • http://www.hitomistudio.com/usecases

Et pour le site français :

  • http://www.hitomistudio.fr/societe
  • http://www.hitomistudio.fr/usecases

Petite précision

Les spécialistes de l’internationalisation et de la régionalisation auront remarqué que je fais l’amalgame entre langue et pays. Heureusement, certains sites prennent bien en compte ces deux points correctement, comme par exemple IBM et Air Canada :

  • http://www.ibm.com/us/en/
  • http://www.aircanada.com/france/en/

Pour conclure

Cet article ne constitue vraiment qu’une première approche. Mes compétences en optimisation pour les moteurs de recherche et en internationalisation étant limitées, il comporte peut-être quelques inexactitudes. Vous êtes donc tout à fait les bienvenus pour le corriger ou le compléter dans les commentaires.

Pour le moment, je pense m’orienter vers la solution suivante :

  • Détection automatique de la langue en fonction de l’entête Accept-Language
  • Redirection automatique sur la version de cette langue
  • Utilisation des urls avec identifiant de la langue
  • Ajout d’un sélecteur de langue dans le pied de page
  • Page de garde qui permet de choisir entre la version française et anglaise

La page de garde n’apparaîtra seulement que lorsque la détection de la langue aura échoué. Au niveau des urls, cela va donner le schéma suivant :

  • http://www.hitomistudio.com
  • http://www.hitomistudio.com/en/usecases
  • http://www.hitomistudio.com/fr/exemples

Qu’en pensez-vous ? A votre avis, quelle est la meilleure stratégie à suivre pour optimiser le référencement d’un site en plusieurs langues ?

A lire également

Vous pouvez continuer votre lecture sur des sujets similaires en consultant les articles suivants :

Les visiteurs qui ont vu cette page ont consulté ensuite :

A savoir

La rédaction de cet article a nécessité 2 heures et 20 minutes. Si vous le souhaitez, vous pouvez être prévenu de la parution de nouveaux articles en vous abonnant par RSS ou par email.

21 commentaires à propos de “Comment optimiser un site en plusieurs langues pour les moteurs de recherche ?” :

  1. # http://www.hitomistudio.com/en/usecases
    # http://www.hitomistudio.com/fr/exemples

    Exactement ce que fait Apple.

    ;)

    Simon André le 10 juin 2009 à 10:41 (#1)

  2. pour l’exemple de yahoo, ca dépend comment tu fais ta redirection,
    si tu la fais en javascript en fin de page, les versions fr.domaine.com et en.domaine.com sont toutes les deux indexées quand meme.
    C’est la méthode que j’ai retenue

    basile le 10 juin 2009 à 12:02 (#2)

  3. “# Détection automatique de la langue en fonction de l’entête Accept-Language
    # Redirection automatique sur la version de cette langue
    # Utilisation des urls avec identifiant de la langue”

    Je n’aime pas trop cette solution. Google va venir sur ton site et etre systématiquement redirigé vers la version EN. Ta version FR sera très peu visible des moteurs de recherche, à moins de provenir d’un lien direct vers des pages intérieures.

    Je préfère consacrer un domaine localisé par langue, tu auras des indexations différentes mais au moins le moteur de sera pas confus, ne sachant pas si ton domaine est en FR ou en EN. En +, il existe un bonus géographique. Exemple, ton domaine en .fr sera mieux jugé sur google france que son équivalent en fr.chose.com. Dernier point, ca permet pour moi (a l’image de ce que fait Coca Cola) de séparer tes actions marketing par pays, ce qui fait gagner en cohérence.

    Ensuite, il est possible d’aller bcp plus loin, avec un hébergement géolocalisé (chaque version pays est hébergée dans le pays), qui rendra ton site hyper accessible a chaque visiteur (penser au lag du visiteur de US/CA si ton serveur est a Paris), et que Google saura apprécier a sa juste valeur, mais la.. on rentre dans une tout autre dimension en terme de tps de travail! ;)

    A+
    Cedric

    cedric sadai le 10 juin 2009 à 13:26 (#3)

  4. Tout comme Cédric :)

    Brice le 10 juin 2009 à 13:58 (#4)

  5. Au niveau de la localisation, il ne faut pas oublier les différences dans le formatage des dates (jour mois année, mois jour année) et des nombre décimaux (séparateur décimal et des milliers). Facilement gérer en asp.net, je ne connais pas la technique en PHP ou si le Framework Zend a qqch pour gérer ceci.

    Cyrille le 10 juin 2009 à 13:58 (#5)

  6. Je suis d’accord avec les points mentionnées par Cédric.

    On aimerait bien pouvoir tout gérer avec une seule URL ( on a tellement l’habitude de factoriser ;o))
    Mais la solution raisonnable est d’avoir 2 url bien distinctes.

    En tout cas merci pour cet article qui défriche bien la problématique.

    Dominique le 10 juin 2009 à 16:59 (#6)

  7. @Cyrille ZF gère très bien l’internationalisation (i18n) et la localisation (l10n) via deux composants dédiés (Zend_Locale et Zend_Translate)

    @Cedric, c’est vrai que l’extension nationale peut apporter un bonus mais l’utilisation du sous domaine fonctionne aussi très bien (fr.monsite.com) à condition d’attribuer à ce sous-domaine une IP locale (chez déjà vu ça chez OVH, hébergement d’un sous domaine sur une IP locale = UK/DE/FR/etc…)

    Pour la contrainte de la langue/pays, j’opterai pour l’utilisation du sous-domaine avec le code pays (fr, de, uk, ch, etc…) et une table d’association des locales en fonction des langues du pays.
    Par exemple : fr –> fr-FR / de –> de-DE / ch –> fr-CH ou de-CH ou it-CH
    Bref, dans un pays avec une seule langue le code pays suffit à identifier la langue et le pays et dans le cas de plusieurs langues dans le pays, on fixe une langue par défault et on laisse le choix à l’utilisateur de modifier la langue (et on transmet dans ce cas là le paramètre de langue via cookie ou url)
    Exemple : fr.monsite.com /ch.monsite.com / ch.monsite.com?lg=fr

    L’avantage c’est qu’on peut coder des sous-domaines particulier comme qc.monsite.com pour le québec qui est associé à la locale fr-CA :-)

    Voilà pour les idées ;-)

    RenoV le 10 juin 2009 à 18:31 (#7)

  8. petit remarque les sous-domaine sont considérés comme des sites séparés, détail qui a de l’importance pour tout la veille de référencement SEO qu’il faudra effectuer après lancement. (tout le travail en double)

    j’utilise la reconnaissance de langue dans le navigateur depuis 2003 pour des sites mutilingues et cela marche parfaitement sauf pour les moteurs de recherche pour qui ils faut faire une regles bien particulieres (user agent).

    Ensuite tu ne mentionne pas la problématique de l’url unique dans tes exemples mais cela va etre dur de communiqué sur un domaine www.toto.com si ta solution retenu est de la forme
    xxx.toto.com
    www.toto.com/lang/

    clairement ta page d’acceuil qui a le plus fort page rank (oui j’y crois moiiii!) n’aura pas une url correspondant au backlink les plus fréquent : ton nom de domaine.

    à mon sens (et c’ets ce que j’applique)
    www.toto.fr
    www.toto.com
    + regle de lang visiteur
    + regle d’entrée pour les moteru pour qu’il indexe vraiment deux sites séparés et ne jamais avoir un contenu en francais sur le nom de domaine .com mais toujours .fr
    => cela permet d’avoir une communication en .fr sur les support francophone et en .com sur les autres.

    bon si tu vise 36 pays va falloir dejolie regles…;-)

    bonne continuation

    nicolas laustriat le 10 juin 2009 à 22:29 (#8)

  9. Noooooon ! Imposer la langue sur détection de l’adresse IP, c’est mal : d’une part parce que c’est associer abusivement un pays à une langue, d’autre part parce que je peux me pointer avec une adresse IP française et être de langue maternelle française, mais souhaiter visiter tel site en allemant parce que j’aime lire dans la langue originale et tel autre en italien parce que je révise en prévision mes prochaines vacances. Le choix de la langue doit revenir à l’utilisateur.

    Dans le cas d’un site multilingue, les autres langues doivent rester accessibles, car l’utilisateur peut souhaiter en changer en cours de visite : le cookie qui zappe la home qui proposant le choix de la langue, c’est pas idéal non plus.

    @Cyrille : Pour la gestion des dates et autres spécificités typographies dans les différentes langues : SPIP gère cela très bien, nativement, depuis 2007.

    @Renov : je préfère toujours un code langue plutôt que l’évocation du pays : http://fr.wikipedia.org/wiki/L....._ISO_639-1

    Après, chaque situation/site multilingue est particulière…

    tetue le 11 juin 2009 à 03:13 (#9)

  10. C’est “Tetue” qui a raison.

    Midas Oracle Not le 11 juin 2009 à 08:50 (#10)

  11. Bonjour,

    Sur un précédent projet, j’ai appliqué la règle suivante : le nom de domaine en .com est celui communiqué à tout le monde. Ce nom de domaine pointe en fait sur une page disposant d’un script qui renvoie l’internaute sur la bonne version (langue) du site en fonction de la langue du navigateur. Chaque langue dispose de sa propre extension. Ainsi, c’est l’extension (nom de domaine) qui détermine la langue. On limite ainsi la taille des URL. Par ce biais, chaque version est correctement référencée dans Google et on peut communiquer sur une seule et même URL sur les documents imprimés.
    Je précise qu’entre chaque version, je peux en effet naviguer vers une autre langue.
    Pour ce qui concerne le pays, j’ai utilisé la géolocalisation par IP pour déterminer le contenu propre à chaque pays directement dans le code.

    arnaud le 11 juin 2009 à 09:21 (#11)

  12. tout à fgait d’accord avec Midas Oracle Not…il n’y pas de recette miracle juste un ratio satisfaction internaute/référencemetn/monitoring à trouver.

    moi aussi l’ip n’est pas trop World Wide web…le français en session taff à Rio va avoir sont site automatique en brésilien…;bof bof, alors qu’en controlant la langue du navigateur on sait que la langue principale est en FR et donc il vos mieux lui proposer la version français e ne premiere page.

    nicolas laustriat le 11 juin 2009 à 09:29 (#12)

  13. Première remarque : l’utilisation de l’extension du nom de domaine (.fr ou .us par exemple) pour déterminer la langue du contenu n’est peut-être pas très adaptée, parce que là encore on utilise un code pays à la place du code de la langue. Si l’on reprend l’exemple du Canada dont une partie est francophone, quelle langue faudra-t-il afficher lorsque l’utilisateur arrive sur le .ca ?

    Sinon si on analyse comment fonctionne le site d’Apple, on s’aperçoit que lorsque l’utilisateur spéficie ‘www.apple.fr’ dans son navigateur, le serveur d’Apple renvoit une redirection définitive 301 avec la nouvelle adresse ‘www.apple.com/fr’. Il ne s’agit donc pas de redirection Javascript ou HTML. Que pensez-vous de cette approche en terme d’optimisation pour les moteurs de recherche ?

    Enfin je pense que tu ne m’as pas bien compris Tetue. Il ne s’agit pas d’imposer une langue à l’utilisateur, mais de détecter celle qui semble la plus appropriée et de lui laisser ensuite la possibilité d’en changer (grâce à un sélecteur de langue - de toute manière important pour le référencement - ou en attirant son attention avec un message comme le fait par exemple Yahoo).

    Ce qui est sûr, c’est que si on analyse en détail la manière dont des sites importants (Coca-Cola, IBM, …) aborde ce problème, on s’aperçoit qu’ils utilisent tous des techniques différentes…

    Stéphane le 11 juin 2009 à 09:54 (#13)

  14. Je m’étais posé la même question lors de l’internationalisation de mon CMS, après réflexion la solution de l’identifiant dans l’url c’est avéré la plus utile. Au niveau parcours d’un moteur, même si la langue est détectée par défaut, le moteur de recherche aura dans ces premiers liens à analyser : les liens de choix des langues, ce qui ne gênera en rien le référencement. D’autre part, le sitemap est là pour guider les moteur de recherche évolués…

    Tout est seulement affaire d’organisation de la page, toujours préférer un sélecteur de langues en haut à droite sous forme de liste déroulante ou non, disposer d’un sitemap.xml automatiquement mis à jour, rediriger l’internaute vers la page http://www.domain.tld/ma_langue lors de l’arrivée sur la page d’accueil. Si on respecte ça pas de soucis de référencement ni de perte de visiteurs.

    Niveau serveur, que ce soit sous GNU/Linux ou sous win il est tout à fait possible de répartir chaque langue sur un serveur distinct et de construire un système de gestion backoffice qui se connecte sur chaque bases et chaque système de fichiers afin de mettre à jour chaque enregistrement selon sa langue.

    Prometee le 11 juin 2009 à 10:00 (#14)

  15. Voilà un article de Google sur le sujet.

    Stéphane le 11 juin 2009 à 10:16 (#15)

  16. Je pense que la solution avec une page de garde est la plus simple. En plus ça permet de faciliter le référencement du site par-rapport aux autres solutions

    Referencement le 11 juin 2009 à 11:17 (#16)

  17. Je suis pour les deux techniques en même temps :).

    A savoir l’identifiant de la langue dans l’url en .com et puis la redirection des géo domaines sur ces urls au cas ou un utilisateur choisi le géo domaine.

    Mais je crois que le plus dur ça sera le travail sur l’architecture et la base de données (gettext …etc).

    Mehdi le 11 juin 2009 à 11:34 (#17)

  18. Voir aussi http://www.google.com/support/.....&hl=fr

    Dominique le 12 juin 2009 à 10:51 (#18)

  19. moi je préfère utiliser toujours la même url quelque soit la langue ,
    donc toujours http://www.domaine.com
    et suivant la langue , dynamiquement je change le contenu …
    En php , c’est facile à faire …
    je crée autant de répertoire que de langue , et dans ces répertoires , j’y met un ficher php utilisé en include … dans ce fichier il y a sous forme d’un tableau toutes les traductions (dans la langue spécifié) de tous les mots et menus.
    Bref une fois le site developpé en francais , pour rajouter une langue , il y a juste à copier
    ce fichier dans un nouveau répertoire , et traduire son contenu dans la langue spécifié

    et dynamiquement en fonction des variable serveur qui donne la langue ( je sais plus laquelle) , je change de fichier d’include

    En asp.net cela été étudié pour pouvoir le realiser , avec des fichiers (j’ai oublié le nom) de ressources.

    Apres les référenceurs , qu’ils se debrouillent pour indexer toutes les langues , et ils le font bien, sans rien faire de plus (je dois avoir de la chance) ..
    Enfin dans mon cas, j’ai pas encore fini le boulot

    1001portails le 27 juin 2009 à 01:32 (#19)

  20. A noter un défaut de taille dans l’utilisation d’un domaine ayant un TLD propre au pays visé ( .fr, .be, etc… ): Certaines extensions sont uniquement disponibles au résidants locaux. Pour le ‘.de’ , par exemple, il faudra forcément avoir une adresse en allemagne. Cette restriction est “déjouable”, mais parfois avec difficultés.

    vincent le 9 juillet 2009 à 14:13 (#20)

  21. Pour notre site on a utilisé la technique de l’Url avec identifiant de la langue. Par défaut les cms oriente vers cette solution donc je suppose que c’est la plus pertinente. Elle a des avantages pour la lisibilité, et pour le référencement. Et elle permet aussi à l’utilisateur de changer facilement de langue sans perdre ca session…

    ooKooDoo le 17 août 2009 à 10:53 (#21)

Ajouter un commentaire

Les informations obligatoires sont indiquées par une étoile rouge *.


5 rétroliens à propos de “Comment optimiser un site en plusieurs langues pour les moteurs de recherche ?” :

  1. SEO pour un site en plusieurs langues | Blog VeCrea
    Le 11 juin 2009 à 23:39
  2. Du bruit dans l’moteur : Google, Click2bet, Bing… | motrech
    Le 12 juin 2009 à 15:29
  3. BlOg’X Office #10 : petit medley du Web | Autour du Web
    Le 14 juin 2009 à 23:03
  4. Vent des blogs #41 | Fredzone
    Le 15 juin 2009 à 15:01
  5. pligg.com
    Le 16 juin 2009 à 18:21
sympa ces nouveaux bureaux. Il y a même la place pour un billard ;)

Articles Récents

Les derniers articles publiés

A Propos

Je m’appelle Stéphane Thomas et je suis Ingénieur Senior expert dans le développement d'applications web complexes. Etant également un peu Entrepreneur, j'ai tenté l'aventure de la création d'un nouveau service Internet appelé Loomiz. Je suis maintenant le cofondateur d'Hitomi Studio, un studio de développement spécialisé dans la réalisation de sites ecommerce haut de gamme pour de jolies marques.

Lire la suite…