Comment dois-je structurer mes URL pour le référencement et la localisation?

Lorsque je configure un site dans plusieurs langues, comment dois-je configurer mes URL pour les moteurs de recherche et la convivialité?

Disons que mon site est www.example.com, et je traduis en français et en espagnol. Quel est le meilleur pour la convivialité et le référencement?

Option de répertoire:

http://www.example.com/sample.html
http://www.example.com/fr/sample.html
http://www.example.com/es/sample.html

Option de sous-domaine:

http://www.example.com/sample.html
http://fr.example.com/sample.html
http://es.example.com/sample.html

Option de nom de fichier:

http://www.example.com/sample.html
http://www.example.com/sample.fr.html
http://www.example.com/sample.es.html

En-tête Accept-Language:

Ou devrais-je simplement analyser l'en- Accept-Languagetête et générer du contenu côté serveur pour l'adapter à cet en-tête?

Y a-t-il une autre façon de faire cela? Si les différentes versions linguistiques ne comportent pas d'URL différentes, que dois-je faire pour les moteurs de recherche?

MISE À JOUR 2011-12-06

Google propose de nouvelles recommandations pour les metabalises permettant de pointer explicitement vers d'autres contenus linguistiques: Nouveau balisage pour les contenus multilingues .

MISE À JOUR 2012-05-25

Liés mais pas précisément: annotations de sites multilingues et multinationaux dans Sitemaps

MISE À JOUR 2013-06-12 Le ciblage du contenu de site vers un pays spécifique inclut la discussion de plusieurs modèles d'URL directement pertinents pour la question.

Il existe de nombreuses manières acceptables de structurer votre site à la fois pour le référencement et l'internationalisation. Chacun a des avantages et des inconvénients.

Domaines de premier niveau

Achetez le même nom de domaine dans plusieurs domaines de pays de premier niveau tels que example.com, example.eset example.de.

Avantages

• Entièrement pris en charge par Google. Vous pouvez ajouter les sites à Google Webmaster Tools où des options vous permettent d'indiquer à Google comment ils sont ciblés.
• Souvent préféré par les utilisateurs qui ont tendance à aimer le contenu publié sur le TLD pour leur pays
• Le nom de domaine lui-même peut être localisé. De nombreux utilisateurs internationaux peuvent mal réagir aux mots anglais ou à un nom de domaine à consonance anglaise. Cela peut être particulièrement important pour les langues qui n'utilisent pas l'alphabet latin.
• Prend en charge la localisation par pays. Vous pouvez avoir des sites distincts tels que example.co.uket example.com.audestinés à des publics dans différents pays. Le contenu des sites peut être dupliqué avec de légères différences d’orthographe tout en conservant un bon classement. En fait, plusieurs sites bien localisés dans la même langue peuvent se classer mieux qu'un site unique dans cette langue.
• L'hébergement peut être localisé en faisant pointer DNS vers un serveur Web du pays ciblé.

Désavantages

• Cher et prenant beaucoup de temps pour acheter plusieurs domaines. Surtout si vous devez faire face à des squatters.
• Les cookies ne peuvent pas être partagés entre plusieurs paramètres régionaux, ce qui signifie que les utilisateurs doivent se connecter séparément à chaque site.
• Aucune bonne option pour localiser uniquement par langue, car plusieurs langues ont plusieurs pays et aucun pays ne peut être le code de langue. Même dans les cas où le TLD correspond au code de langue es, les moteurs de recherche peuvent supposer que le site ne convient que pour les utilisateurs espagnols et non pour tous les hispanophones.

Sous-domaines

Achetez un seul domaine et utilisez des sous-domaines tels que en.example.com, etes.example.com

Avantages

• Entièrement pris en charge par Google.
• Prend en charge la localisation par pays ou par langue.
• L'hébergement peut être localisé en faisant pointer DNS vers un serveur Web situé à proximité des utilisateurs.
• Facile et peu coûteux à mettre en œuvre par rapport à l’achat de plusieurs domaines.
• Les cookies peuvent être partagés à travers tous les paramètres régionaux, permettant ainsi une connexion unique pour une expérience utilisateur plus transparente.

Désavantages

• Aucune possibilité de localiser le nom de domaine lui-même
• Peut paraître moins local pour les utilisateurs par rapport à un domaine de premier niveau.

Sous-répertoires

Achetez un seul domaine et utilisez des sous-répertoires tels que example.com/en/, etexample.com/es/

Avantages et inconvénients

• Identique aux sous-domaines, à la différence qu'il existe une entrée DNS qui empêche l'hébergement de votre site dans plusieurs pays pour des paramètres régionaux différents.

Techniques non recommandées

• Noms de fichiers : Utiliser différents noms de fichiers tels que index_en.htmlet index_de.html. Cette technique n'est pas entièrement prise en charge par Google. Par exemple, il n’existe aucun moyen de définir le ciblage dans les outils pour les webmasters.
• Paramètres URL : Utilisation de paramètres URL tels que lang=en. Il n'est pas recommandé pour la même raison que des noms de fichiers différents ne soient pas recommandés.
• Accepter en-tête de langue : changer automatiquement de langue en fonction de l'en- Accept-Languagetête.
  • De nombreux utilisateurs n'ont pas cet en-tête défini correctement. Cela est particulièrement vrai pour les utilisateurs voyageant à l'étranger qui utilisent peut-être l'ordinateur d'un ami ou un cybercafé. C'est également souvent le cas des utilisateurs internationaux qui installent un navigateur Web anglais et maîtrisent suffisamment l'anglais pour se déplacer, mais préfèrent un contenu dans une langue différente.
  • Google vient d'annoncer que Googlebot enverra l'en- Accept-Languagetête et l'analyse à partir de différents emplacements géographiques . Toutefois, Google recommande toujours que vous ayez des URL distinctes pour le contenu dans différentes langues.
  • Vous pouvez utiliser l'en- Accept-Languagetête pour suggérer aux utilisateurs de préférer une version différente du site en affichant un message lorsque le site qu'ils visitent ne correspond pas à l'en- Accept-Languagetête.
• Adresses IP géographiques : commutation automatique de la langue en fonction de la localisation géographique de l'adresse IP.
  • Les bases de données géo-ip sont inexactes. Jusqu'à 10% des visiteurs peuvent être affectés à un pays incorrect .
  • Certains pays (comme le Canada) utilisent plus d'une langue
  • Vous pouvez utiliser le pays d’adresse IP pour suggérer une ou plusieurs langues pouvant intéresser un utilisateur.

Balisage sur la page

Lorsque vous prenez en charge plusieurs langues, vous devez clairement identifier les méta-données de langue.

Utilisez l'attribut lang dans la htmlbalise:

<html lang="en">

Utilisez d'autres liens vers la même page dans d'autres langues, comme suggéré par Google :

<link rel="alternate" hreflang="es" href="http://www.example.com/" />
<link rel="alternate" hreflang="es-ES" href="http://es-es.example.com/" />
<link rel="alternate" hreflang="es-MX" href="http://es-mx.example.com/" /> 
<link rel="alternate" hreflang="en" href="http://en.example.com/" />

Alternativement, ces informations peuvent être placées dans des fichiers de sitemap .

Parlez de votre site à Google

Vous devez ajouter chaque langue (ou paramètres régionaux) de votre site à Google Webmaster Tools . Cela peut être fait pour les domaines de premier niveau, pour les sous-domaines ou pour les sous-répertoires.

Si votre site est ciblé par pays, vous devez utiliser les outils du Webmaster pour définir le ciblage par site. Accédez à "Configuration" -> "Paramètres" -> "Cible géographique" et choisissez de cibler le bon pays dans la liste déroulante.

Répondant à une question similaire à la votre sur son blog, Matt Cutts suggère :

Si vous avez des sites avec, par exemple, des versions française et allemande pour une entreprise, mes préférences seraient les suivantes:

1. ccTLDS tels que exemple.fr ou exemple.de
2. Après que, les sous-domaines tels que fr.example.com ou de.example.com.
3. Si ce n'est pas possible, j'utiliserais des sous-répertoires tels que exemple.com/fr/ ou exemple.com/de/.

En tant qu'utilisateur allemand, je déteste quand un site Web ne me laisse pas apparaître sur la page anglaise car il pense qu'il sait mieux ce que je veux. Les Américains ont peut-être du mal à comprendre, mais certaines personnes parlent plus d'une langue.

Parfois, je souhaite consulter les sites Web allemands et parfois celui en anglais.

Analyser simplement l'en- Accept-Languagetête pourrait me rendre fou.

Cela est particulièrement vrai si votre page allemande est une traduction peu coûteuse de votre page anglaise.

Pour faciliter la tâche de votre utilisateur, la version anglaise doit également comporter une localisation telle que domain.com/en/ou en.domain.com.

Lorsque je tape, domain.comvous avez l’impression de me donner l’anglais ou la page allemande en fonction de mon en- Accept-Languagetête. Si toutefois je n'aime pas votre choix, je devrais pouvoir simplement échanger la langue du nom de domaine.

Conseil supplémentaire: Si vous avez la langue devant le nom de domaine en tapant ger.domain.com, vous de.domain.comdevriez m'amener sur le site Web allemand.

À mon avis, vous devriez utiliser l'approche par dossier ou par sous-domaine, car ils sont plus intuitifs pour l'utilisateur. Lequel est une question de goût personnel, je trouve personnellement l'approche de dossier plus claire. L'option de nom de fichier est beaucoup moins intuitive.

L'analyse de l'en- Accept-Languagetête pour diriger l'utilisateur vers le contenu correct lors de sa première visite est une bonne idée, mais vous ne devriez le faire que pour rediriger le dossier ou l'URL du sous-domaine. Dans le cas contraire, il serait impossible de créer un lien vers du contenu dans une langue spécifique et l'indexation de votre site Web serait un désastre.

Utilisez l'option de sous-domaine si vous utilisez des versions localisées (c'est-à-dire France! = French). Utilisez des sous-domaines, mais je pense qu’il est préférable d’utiliser des répertoires si ce pays utilise différentes langues. Par exemple:

us.domain.com (USA)
us.domain.com/en/sample.html (USA - english)
us.domain.com/es/ejemplo.html (USA - spanish)
es.domain.com (Spain)
es.domain.com/es/ejemplo.html (Spain - spanish)
es.domain.com/ca/exemple.html (Spain - catalan)

Bing s'appuie sur des balises géo-méta, mais pour Google, vous devez utiliser Google Webmaster Tools.

Si vous souhaitez cibler les marchés mondiaux, utilisez www.domain.comune langue utilisateur préférée (le navigateur donne les priorités de la langue sur l'en- Accept-Languagetête) lorsque vous l'avez, ou avec votre langue de marché clé lorsque vous ne l'avez pas.

C'est la même question que j'ai posée à Stack Overflow . Et j'ai une ressource pour cela, que je posterai comme réponse ici.

J'ai trouvé une bonne ressource de Google sur les choix que vous pouvez faire. Il y a une section avec les avantages et les inconvénients de chaque méthode que vous pouvez utiliser.

Je me bats avec les sites Web multilingues depuis un moment maintenant. Il y a certainement des points dans l'article qui ne sont pas mentionnés dans les réponses mentionnées. C'est pourquoi j'ai ressenti le besoin d'afficher ceci comme réponse. J'espère que ça aide quelqu'un.

Je n'utiliserais pas de sous-domaines. En termes de référencement, c'est moins utile: http://www.hobo-web.co.uk/seo-blog/index.php/blog-subdomain-or-subfolder-which-is-best/ .

Discussion similaire ici: sous- domaine ou sous-répertoire .

Si vous regardez de gros sites, le plus souvent, utilisez des sous-domaines.

Cela dépend également de la nature de votre entreprise, qu'elle soit mondiale ou locale. Nous sommes une agence de droit d'auteur, donc pour utiliser ses activités plus locales. Par conséquent, les domaines de premier niveau sont meilleurs que de tout exécuter .com.

Le nom de fichier est un concept que je n'ai pas encore vu.

La dernière adoption dans cette direction, comme l’application de page unique (SPA) pour les produits à base de SAAS -

1. Utiliser différents sites Web pour différents pays entraînera une perte de liens qui irait autrement vers notre principal domaine de marque. Exemple: - https://www.example.in/, https://www.example.fr/etc. (Amazon, le grand géant du commerce électronique a commis cette erreur dans le passé.)

2. Utiliser le même domaine avec SPA et rediriger tous les visiteurs vers ce sera bien, mais nous ne pourrons cibler qu'une langue dans ce cas. Il y aura une mauvaise expérience utilisateur en raison du fait que différents pays ont besoin de différentes langues.

3. Il y a beaucoup de meilleurs exemples dans cette affaire (par exemple, Microsoft et Uber). Personnellement, j’aime ce qu’ils font et je pense qu’ils utilisent les meilleures pratiques de référencement.

   When Lang - Anglais avec différents pays.

   • https://www.example.com/en-in (Pour l'Inde)
   • https://www.example.com/en-au/ (Pour l'Australie)
   • etc.

   ou

   • https://www.uber.com/en/in/ (Pour l'Inde),
   • https://www.uber.com/en/au/ (Pour l'Australie)
   • https://www.uber.com/fr/ (Pour la France)
   • etc.

   Quand Lang & Country sont pareils -

   • https://www.example.com/fr-fr/ou https://www.example.com/fr/fr/(pour la France)
   • https://www.example.com/ru-ru/ou https://www.example[dot]com/ru/ru/(pour la Russie)
   • etc.

Pour plus de clarté, consultez l' aide de Google Search Console: Gestion de sites multirégionaux et multilingues