it-swarm-fr.com

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 que 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-tête Accept-Language et générer du contenu côté serveur afin de 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?


UPDATE 2011-12-06

Google propose de nouvelles recommandations pour les balises meta permettant de désigner explicitement un autre contenu linguistique: nouvelle balise pour un contenu multilingue .

UPDATE 2012-05-25

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

MISE À JOUR DU 2013-06-12 Ciblage du contenu d'un site dans un pays spécifique comprend la discussion de plusieurs modèles d'URL directement pertinents pour la question.

107
artlung

Il existe de nombreuses manières acceptables de structurer votre site 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 pays de premier niveau, tels que example.com, example.es et example.de.

Avantages

  • Entièrement pris en charge par Google. Vous pouvez ajouter les sites à Google Webmaster Tools où il existe des options permettant d'indiquer à Google leur ciblage.
  • 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.uk et example.com.au destinés à un public de différents pays. Le contenu des sites peut être dupliqué avec de légères différences d’orthographe tout en restant bien classé. 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é.

Inconvénients

  • 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 tel que es, les moteurs de recherche peuvent supposer que le site ne convient que pour les utilisateurs espagnols, mais pas pour tous les hispanophones.

Sous-domaines

Achetez un seul domaine et utilisez des sous-domaines tels que en.example.com et es.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.

Inconvénients

  • 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/ et example.com/es/.

Avantages et inconvénients

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

Techniques qui sont PAS recommandées

  • Noms de fichiers : utilisez différents noms de fichiers tels que index_en.html et 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 d'URL : Utilisation de paramètres d'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 l'en-tête de langue : change automatiquement de langue en fonction de l'en-tête Accept-Language.
    • 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 en 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-tête Accept-Language et l'explorera à 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-tête Accept-Language pour suggérer aux utilisateurs de préférer une version différente du site en affichant un message lorsque le site visité ne correspond pas à l'en-tête Accept-Language.
  • Adresses IP géographiques : commutation automatique de la langue en fonction du lieu où l'adresse IP est située géographiquement.

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 balise html:

<html lang="en">

Utilisez d'autres liens vers la même page dans d'autres langues que 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, cette information peut être placée dans les 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.

90
Stephen Ostermiller

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

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, 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/.
22
mvark

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-tête Accept-Language 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.com, vous devez deviner l’anglais ou la page allemande en fonction de mon en-tête Accept-Language. 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, vous devez taper ger.domain.com et de.domain.com pour me rendre sur le site Web allemand.

19
Christian

À 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.

Analyser l'en-tête Accept-Language pour diriger l'utilisateur vers le contenu correct lors de sa première visite est une bonne idée, mais vous ne devez le faire que pour rediriger vers l'URL du dossier ou du sous-domaine. Sinon, 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.

15
Wookai

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 des marchés mondiaux, utilisez www.domain.com avec une langue utilisateur préférée (le navigateur donne les priorités de langue sur l'en-tête Accept-Language) lorsque vous l'avez ou avec votre langue de marché clé lorsque vous ne l'avez pas.

5
jrosell

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

J'ai trouvé un Nice 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 lutte 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 de poster ceci comme réponse. J'espère que ça aide quelqu'un.

5
Saif Bechan

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 si votre entreprise est de nature plus globale 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 sur .com.

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

3
Remy

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 seule langue dans ce cas. Il y aura une mauvaise expérience utilisateur en raison des différents pays ayant 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.

    Lorsque Lang et Pays sont identiques -

    • 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é, veuillez consulter Aide de Google Search Console: Gestion de sites multirégionaux et multilingues

1
Premnath321