Ce billet est dans l’ère du temps, Hopwork va se décliner de façon plus concrète à l’international et cela engendre de nouvelles problématiques, notamment sur le SEO.

Profitons-en pour parler d’un sujet en apparence triviale, les noms de domaines et leurs rôles dans l’internationalisation.

 

Quelques points de rappel avant de démarrer. Par internationalisation il faut comprendre : l’ensemble des techniques à mettre en oeuvre pour qu’une application/site web puisse être décliné dans chaque pays/régions.

La localisation c’est le moment ou on décline l’application à proprement parler.

Par exemple, extraire les textes de votre application dans un fichier afin de pouvoir le traduire, c’est de l’internationalisation. Rien n’est traduit mais on a la capacité de le faire. Traduire ce fichier en Espagnol c’est de la localisation.

Ce billet ne parlera que de la stratégie d’internationalisation sur les noms de domaines et non pas de tout les autres aspects de l’internationalisation :

  • devises et paiement
  • formatage des chiffres
  • formatage des dates et les timezone
  • taille de police
  • images
  • sens de lecture
  • obligations légales (CNIL en France par exemple etc…)
  • encodage
  • etc…

Cette liste est non exhaustive. Nous en verrons peut être d’autre dans de futurs billets.

Un peu d’histoire

image4

En 2015 Hopwork n’est disponible qu’en Français sur www.hopwork.comEt nous avons également des sites hopwork.it, hopwork.de, hopwork.be etc… qui ne font que des redirections vers le .com.

Et puis en 2015 on décide de donner le choix aux utilisateurs de pouvoir utiliser le site en Anglais, fonctionnalité somme toute assez basique en principe.

Mais faisons un tour des implémentations possibles.

La stratégie Yolo

Finalement pourquoi s’embêter avec le Français, on passe tout le site hopwork.com en Anglais et on ne maintient que cette version.

On pourrait appeler cette stratégie :

“je suis américain, les autres langues n’existent pas et de toute façon j’ai le monopole, je fais ce que je veux”.

ou

“j’ai pas le temps de faire mieux”.

image2

Ca ne nous emballe pas beaucoup, c’est certainement moins de boulot mais pour les utilisateurs c’est pas super sympa. On souhaite qu’un Francais trouve un site en Francais et qui tienne compte de ces spécificités, un Espagnol attend un site en Espagnol etc…

Next.

Changement de langue à l’affichage

Qu’on aurait aussi pu appeler “Yolo 2”. On peut cette fois uniquement changer la langue lors de l’affichage du site.

L’utilisateur choisit sa langue via un sélecteur de langue et ensuite on garde cette préférence dans un cookie de session ou dans l’url monsite.com?lg=en

En bonus, lors de la première visite sur le site on essaie de deviner au mieux la langue espéré par l’utilisateur en s’appuyant sur ses infos :

  • soit via le header “Accept-Language” permettant en théorie de connaître les préférences linguistiques de l’utilisateur.
  • soit via son adresse IP. Cette technique est très hasardeuse cependant, entre les utilisations de proxy et le fait qu’il n’est pas simple d’associer une langue avec une localisation

Cette technique est fortement déconseillé pour le SEO dixit Google lui-même. Un moteur de recherche n’indexera pas votre site sur chaque variante linguistique et il ne fera même pas l’effort d’utiliser votre sélecteur de langue et/ou d’utiliser vos cookies.

Bref, on oublie.

Les sous dossiers

Certains sites utilisent des sous dossiers :

Ici aussi, on peut se baser sur la reconnaissance des headers ou adresse IP afin de rediriger l’utilisateur sur la bonne version. Même si Google ne le préconise pas.

En tout cas, ça marche. Désormais on a bien des pages différentes pour chaque versions donc tout peut être indexé par les moteurs de recherche.

Techniquement c’est simple, mais on trouve quelques inconvénients :

  • ce sera moins aisé de séparer physiquement les versions si on souhaite avoir des serveurs différents pour des zones géographiques. J’avoue, je ne rentre pas dans les détails mais croyez moi, sinon ca va dépasser le cadre de ce billet.
  • ce n’est pas forcément très visible pour l’utilisateur. Le sentiment d’immersion, le côté local n’est pas présent.

Bref, ca marche, mais on peut faire mieux.

Des sous-domaines

C’est une stratégie très proche de la précédente, sauf que cette fois on utilise des sous domaines à la place des sous dossiers.

Cette fois on casse pas mal d’inconvénients de la version précédente, on peut avoir des serveurs différents pour chaque sous domaine. La redirection DNS se fait au niveau du sous domaine et peut donc plus facilement adresser des serveurs physiques différents.

On n’a toujours pas ce côté “local” qui ressort très fortement sur l’url pour l’utilisateur.

Avouez que ce serait pas la même chose d’utiliser fr.google.com à la place de google.fr, vous vous sentez un peu plus chez vous sur la seconde option non ?

 

La stratégie full cycle (™ Van Damme)

Cette fois-ci la stratégie consiste à utiliser des domaines ccTLD

Cette fois on résout l’ensemble des points et le côté immersif est très fort.

Et on notera que c’est d’ailleurs la solution recommandée par Google (toujours dans le même article que celui mis en lien plus haut) et que c’est également la solution appliquée par de nombreux sites :

Mais aussi Blablacar, evaneos, drivy, trainline etc…

Par contre évidemment la contrainte majeure c’est qu’il faut l’ensemble des domaines. Il faut qu’ils soient disponibles et ça peut être onéreux.

Concernant le prix, un nom de domaine c’est en moyenne une dizaine d’euros par an donc ca reste très acceptable pour une entreprise qui vise l’international.

Notre choix

En fin de compte sur Hopwork nous prendrons donc ce dernier choix et nous aurons alors :

et des domaines qui n’attendent qu’une seule chose, qu’on les traduise www.hopwork.es, www.hopwork.de etc…

Manque un peu de culture là

C’est fini ?

Mais attends, il manque un truc là. Ca marche pas ton truc en Belgique. Ils parlent deux langues, le Français et le Flamand. Ils vont pas venir sur un www.hopwork.be avec une seule langue disponible. Et tu vas pas demander aux Belges francophones de venir sur www.hopwork.fr, ca fait pas sérieux !

De la même façon, tu vas pas dire à tous les hispanophones de venir sur www.hopwork.esEn plus c’est pas impossible qu’ils aient des mots parfois différents même s’il s’agit de la même langue.

Et non, c’est exact, il faut gérer les “cultures”.

Le terme “Culture” (pour les gens qui font du .net) ou “Locale” (pour ceux qui font du Java) est un terme que l’on retrouve en informatique pour désigner des paires : Pays/Langue. Par exemple fr-CA désigne le Français du Canada.

 

Ne faites pas l’erreur de confondre pays et langues !

On peut avoir des pays avec plusieurs langues officielles.

On peut parler la même langue dans plusieurs pays.

Et on n’associe certainement pas un drapeau avec une langue dans un sélecteur de langue 🙂

 

Bref on va donc utiliser ces deux indications via les domaines et sous domaines.

Par exemple pour la Belgique, nous aurons www.hopwork.be qui pourra être utilisé par les francophones (le choix est arbitraire) et nl.hopwork.be qui sera la version Flamande.

Et pour adresser l’ensemble des francophones non Francais, on pourra leur proposer une version en francais “universel” sur fr.hopwork.com.

Et cette fois-ci nous avons une solution complète.

Je vous invite à tester sur airbnb qui utilise cette technique. Nous avons également implémenté cette solution mais nous n’avons pas encore paramétré les sous-domaines. C’est juste une question de temps.

 

Et le SEO dans tout ça ?

Il y a peut être des questions qui vous sont venus à l’esprit à la lecture de ces chapitres :

  • non mais tu as du contenu en double du coup sur hopwork.fr et hopwork.be, Google il aime pas ca !
  • tu perds pas un peu de “puissance” à diviser ton contenu de cette façon ?
  • t’as du contenu que tu gères toi donc ça va mais le contenu qui est produit par des utilisateurs il est pas traduit lui ?!

Si jamais vous aviez fait ces trois remarques dans votre tête, alors méga gros pouce haut car vous aviez quand même sacrément bien suivi.

Oui, Google n’aime pas le contenu dupliqué c’est un fait.

Mais heureusement vous avez des solutions pour y remédier.

Pour toute page qui existe en multiples versions (une entrée de FAQ, des CGU etc…) vous pouvez signaler à Google (ou tout autre moteur de recherche) qu’il s’agit de la même page mais dans des versions alternatives pour chaque région. Vous pouvez donc écrire ceci dans votre header :

(Vous pouvez également utiliser cette notion dans votre sitemap)

Google comprendra alors que ces pages sont destinées à des régions différentes.

Si par contre vous estimez qu’une page a une version de référence et que les autres versions de cette même page dans d’autres pays ne sont pas pertinentes, vous pouvez utiliser une balise meta canonical pour dire au moteur de recherche que c’est uniquement cette page que vous souhaitez qu’il retienne.

Enfin dernier cas de figure, imaginons que vous ayez un contenu qui apparaît sur une version mais ne doit être indexé.

Par exemple ma page profil sur Hopwork apparaît sur la version Espagnole, mais n’étant pas hispanophone et ne cherchant pas de client en Espagne, ce n’est pas pertinent d’être indexé dans un moteur de recherche Espagnol (google.es). Dans ce cas on peut mettre cette page spécifiquement en noindex sur ce domaine (mais pas sur le .fr !)
Je vous laisse vérifier que c’est bien le cas, j’ai une balise noindex sur https://www.hopwork.es/profile/hlassiege et pas sur www.hopwork.fr/profile/hlassiege

La perte de “contenu”

Naïvement certains auraient pu dire qu’en divisant mon site, je divise le contenu entre plusieurs sites, donc qui dit moins de contenu par site, dit moins de “puissance” aux yeux d’un moteur de recherche.

Les moteurs de recherche aiment effectivement que vous ayez beaucoup de contenu (et qu’il soit intéressant sinon ca vaut rien).

Bref, en ayant des pages de freelances visibles uniquement sur certains domaines et pas d’autres, est ce que j’y perds un peu ?

En fait, pas tant que ça.

Déjà une grande partie de votre contenu est du contenu en double sur chaque domaine. Si vous avez 200 pages sur un domaine et 200 pages sur un autre, vous n’avez pas 400 pages de contenu unique. Une grande partie n’est que la traduction de l’autre (la FAQ par exemple), ce sont des versions alternatives comme on l’a vu plus haut.

Ensuite il faut savoir qu’un moteur de recherche va chercher à associer les pages de votre site à une audience (en terme de langues/pays). Si une page est en anglais, il va considérer qu’elle a du sens pour des visiteurs Anglais mais pas pour les visiteurs Français.

Exemple :

www.google.fr va vous présenter des pages qui viennent de Hopwork.fr et www.google.es va vous présenter des pages qui viennent de google.es car il comprend que l’audience est distincte.

 

Pour lui faciliter la tâche, il préférera avoir la même langue utilisée partout sur un même site mais il peut s’en sortir sans cela.

On peut même l’aider page par page en lui précisant la région ciblée via :

  • le paramètre hreflang
  • les balises alternates
  • le sitemap

ou plus globalement sur un site complet via le ciblage géographique de Google Search console (mais ça ne fonctionnera pas avec un site qui mixe des langues partout sur le site)

C’est très important pour un moteur de recherche de comprendre qui vous visez. Moins c’est précis, moins vos pages remonteront dans les résultats de recherche.

Et si vous avez des pages profiles rédigé par vos utilisateurs dans une langue donnée mais que vous essayez de l’intégrer au contenu d’une autre région, eh bien le moteur de recherche ne va pas les considérer comme étant très pertinentes. Elles vont perdre en “rank”.

En reformulant, si Google trouve le contenu Francais de ma page profile /profile/hlassiege sur la version Espagnole du site, il va pénaliser cette page.

Et enfin, il faut bien comprendre que votre réputation par région/pays ne va pas se reporter d’un claquement de doigt sur tout vos pays que vous n’ayez qu’un seul site ou plusieurs.

Si vous êtes premiers sur une recherche donnée en Français, vous ne le serez pas obligatoirement sur la même recherche mais en Espagnol.

En utilisant l’information des “alternate” Google est déjà bien assez intelligent pour comprendre que les sites sont liées, ce n’est pas le souci.

Mais chaque région doit être travaillé indépendamment sur son SEO. Etre fort en SEO sur une région nécessitera par exemple d’avoir des articles qui parlent de vous sur la région. Mais un article dans Lemonde en France ne vaut pas comme un backlink de qualité sur www.google.es. Bref, votre réputation est de toute façon à refaire sur chaque domaine.

Le contenu utilisateur

On a justement commencé à l’évoquer plus haut, autant traduire votre contenu c’est simple, autant le contenu utilisateur il y a de fortes chances qu’il ne soit pas traduit. Vous pouvez mettre toutes les fonctionnalités pour permettre à vos utilisateurs de le faire pour vous, ils ne le feront que très rarement.

 

Qui a déjà rempli son profil en deux langues sur linkedin par exemple ? Ou rédiger son annonce dans deux langues sur Airbnb ? Pourtant les deux sites le permettent. 

Bref, il va falloir vivre avec.

La solution donc, en tout cas sur Hopwork, c’est de n’indexer le contenu utilisateur (les fiches profils) que sur le domaine sur lequel c’est pertinent et de le laisser en noindex sur le autres.

 

Ok mais s’il reste du contenu en différentes langues ?

Des avis par exemple ? Ou si l’utilisateur a choisi de rédiger sa description en deux langues sur la même page ?

(ca arrive sur linkedin alors même que la fonctionnalité d’avoir deux versions existent. Loi de Murphy appliqué aux sites web : tout ce que vous ne souhaitez pas que vos utilisateurs fassent sera fait dans tous les cas)

 

Eh bien ca marchera quand même d’un point de vue SEO.

Ce sera sans doute pas optimal mais Google, pour ne citer que lui, indique qu’il essaie de comprendre le contenu multilingue sur une seule page. Mais ça reste moins efficace.

Et pourquoi ne pas traduire automatiquement le contenu ?

Pour deux raisons simples :

  • la traduction automatique reste encore assez peu qualitative aujourd’hui pour satisfaire vos utilisateurs. Ceux-ci préféreront en majorité avoir le contenu original avec éventuellement l’option de le traduire

image1

  • Google a déjà indiqué que la traduction automatique pouvait s’apparenter à de la génération automatique de contenu ce qui était contre leurs principes de fonctionnement.

Malgré tout on retrouve ce choix sur les avis de Tripadvisor. Quand on est très connu on peut se permettre deux trois entorses auprès des moteurs de recherche. Ca ne veut pas dire que vous pouvez le faire sans risque vous mêmes. En plus sur Tripadvisor les utilisateurs peuvent corriger les traductions donc ça reste qualitatif quand même.

image3

En conclusion, pour implémenter notre stratégie d’internationalisation nous avons choisi de passer par des extensions de domaines pour cibler un pays et des sous domaines pour préciser la langue quand c’était nécessaire.

Et nous avons implémenté les préconisations de Google pour faciliter le travail des moteurs de recherche en précisant les versions alternatives ou en désindexant les pages non pertinentes pour une région donnée.

 

A bientôt

Leave a Reply

Your email address will not be published. Required fields are marked *