web-dev-qa-db-fra.com

Lorsque l'URL racine d'un domaine ne comporte pas de site spécifique, comment les visiteurs doivent-ils être dirigés vers des dossiers de langue?

Ma question n’est pas technique (comment le faire en utilisant la technologie X), il s’agit de choisir la bonne approche qui soit bonne pour le référencement.

La description

Disons que j'ai un site web example.com. C'est un site multilingue, mais il y a pas de langue par défaut au niveau racine. Au lieu de cela, je voudrais rediriger vers le sous-répertoire approprié basé sur http_accept_language (ou toute autre condition, peu importe) pour que les choses restent cohérentes. La condition n'a pas d'importance pour le moment, mais simplifions avec l'exemple:

example.com     # redirects to …
example.com/es  # … /es if spanish is accepted language
example.com/da  # … /es if danish is accepted language
example.com/en  # … /en otherwise

Ce sont en fait les mêmes sites Web, avec le contenu traduit. Par conséquent, si example.com/en/items/1 existe, /es/items/1 et /da/items/1 existent également. Bien sûr, toutes les pages ont des liens alternatehreflang etc.

Question

Est-ce un bon design? Pouvez-vous me dire pourquoi sinon? Et comment devrait-il être fait?

seoredirectsmultilingualhomepage
5
pfff

De nombreux sites multilingues n’ont pas l’étiquette de langue pour la langue par défaut/principale dans l’URL¹, mais je pense que il est préférable de l’inclure . Donc oui, à mon avis, ce n’est pas seulement un bon design, c’est le meilleur.

Cela suggère d’utiliser la page racine comme un sélecteur de site/de langue. Je pense que cette page peut fonctionner de trois manières différentes:

  • Rediriger (selon certaines conditions²)
  • Afficher une liste de liens
  • Afficher une liste de liens et présélectionner/mettre en évidence le choix le plus probable (selon certaines conditions²)

Cette page est probablement non pertinente pour le référencement , car les moteurs de recherche n'auraient généralement aucun intérêt à présenter une page de choix de langue à leurs utilisateurs. Une telle page n’a (devrait pas) de contenu pertinent, et si elle redirige, il serait inutile de diriger les utilisateurs vers cette page de redirection au lieu de la page cible de redirection (les moteurs de recherche connaissent ou supposent connaître leurs utilisateurs). la langue).

Le plus important (et comme vous l’avez déjà mentionné), c’est que ce n’est pas le seul moyen de choisir la langue. Les utilisateurs (et les moteurs de recherche) devraient pouvoir passer aux traductions de la page en cours avec un lien de langue/alternate + hreflang.

En dehors de cela, en ce qui concerne les moteurs de recherche:

  • Pour la recherche Google , vous pouvez le lier avec rel="alternate" hreflang="x-default":

    […] La valeur réservée "x-default" sert à indiquer les sélecteurs de langue/redirecteurs qui ne sont pas spécifiques à une langue ou à une région, par ex. votre page d'accueil montrant une carte du monde cliquable

    (Je ne comprends pas pourquoi cela pourrait être utile, et je pense que c'est mal conçu (car la page de sélection n'est pas la traduction d'une page d'accueil spécifique à une langue) mais ils le mentionnent dans leur documentation, donc je pense qu'il est préférable de le noter ici aussi.)

  • Si vous redirigez, n’utilisez pas 301. Comme la redirection est basée sur des conditions changeantes/spécifiques à l’utilisateur, elle n’est pas permanente. Et vous ne souhaiterez probablement pas qu’il soit mis en cache pour un utilisateur (qui pourrait par exemple modifier les langues acceptées dans son navigateur et revenir à la page racine).

    302 ( ou peut-être 307? ) semble être le bon code d'état.

  • Peut-être que vous pourriez envisager de noindex cette page racine, s’il s’agit vraiment d’une simple liste de liens.

¹ Soit dit en passant, pour les sites qui utilisent des sous-domaines (en.example.org, da.example.org) au lieu de segments de chemin d'accès pour les balises de langue, la même question se pose: que faire avec example.org/www.example.org? Je pense que la solution est la même dans ce cas.

² Les conditions peuvent être l’en-tête Accept-Language, l’adresse IP ou tout ce qui a du sens dans votre contexte.

4
unor

Je pense que la manière la plus conviviale pour le référencement serait de définir une langue par défaut. Ce contenu serait servi à partir de /. Les pages d'accueil de toutes les autres langues viendraient de/lang /. Et le modèle proposé par @unor peut toujours être appliqué: préfixez tout le contenu avec/lang /, par exemple/lang/about-xy/- pour la langue par défaut également, comme il est de pratique courante.

Pourquoi pourrait-il être préférable de servir une vraie/page? J'ai eu des cas où il y avait une fois une/page, mais ensuite le système est passé à 302 redirections pour toutes les langues. Et puis l'original/a été conservé indexé et affiché dans les résultats de recherche (avec une balise de titre obsolète, etc.) pendant des siècles. Donc, voici le point: votre URL la plus importante, le /, est redirigée avec un 302! Ou cela montre une liste de liens de langue (je ne voudrais certainement pas "noindex" le /), inutile en termes de référencement, gaspillant ainsi votre potentiel. Si vous utilisez des ccTLD, vous pouvez éviter ce problème complètement. En outre, j'ai entendu des gens dire qu'il devrait être préférable que la page traite 200 réponses. Mais je ne peux plus trouver ce post.

0
benzkji