Conception d'un site langue UK & et hébergement

[Nicolas]

Bonjour à tous,

Je fais un appel à la communauté du Hub afin d'avoir des pistes sur une problématique que je n'ai jamais eu dans le passé...

Je possède un site en version FR et je viens de créer la version anglaise d'un site qui sera destiné principalement à un public US.

Le code gère les 2 versions (version FR et version US) cela permet d'avoir un seul code et une seule bd à maintenir pour 2 versions de sites. Il contient donc toutes les traductions en variables globales.

Tout fonctionne bien au niveau de la conception sauf que la version US est donc aussi hébergée en france (mêmes fichiers que la version FR qui est sur un serveur FR) ce qui peut poser des problèmes de temps d'accès pour les visiteurs US.

- Est-ce que ca peut vraiment poser des problèmes de temps d'affichage ainsi que pour le référencement (critère aussi pris en compte pour le classement google) ?

- Est-ce que ca serait pas mieux de dupliquer le code et de le mettre sur un serveur basé aux US ? en étant obligé de maintenir 2 codes mais vu que le dev le plus important a été fait est-ce vraiment un problème ?

- Autres solutions ?

Merci d'avance

[yuston]

Salut,

Est-ce que les versions (langues) sont distinguées par un sous domaine ? (fr.blabla.com, us/en.blabla.com)

Si oui, il doit être possible de géolocaliser par IP le sous-domaine.

[Nicolas]

Non c'est l'extension qui diffère.

Je peux bien sur mettre une adresse UK (ou p-e US?) sur la version anglaise mais ca changera pas le problème de temps d'accès (en estimant que ca pose réellement un problème ce qui n'est pas sûre).

[karnabal]

L'utilisation de ccTLD suffit pour géolocaliser du contenu (en termes de SEO) quel que soit le pays où se trouve le serveur.

• Il s'agit de quelle typologie de site ?
  
• Combien de pages (environ) ?
  
• Budget/ROI attendu, en fait, envergure du projet ?
  

En fonction des réponses tu peux peut-être t'orienter (ou non) sur du CDN.

J'ai travaillé le référencement naturel de sites e-commerce ou institutionnels plus ou moins volumineux et ceux-ci n'utilisent pas de système de content delivery network alors qu'ils sont hébergés respectivement au même endroit et qu'ils ont des publications et une stratégie de nom de domaine adaptées à l'international. Je n'ai jamais eu de retour négatif de leur part sur la question de la localisation physique du serveur d'hébergement vis-à-vis du temps de chargement des pages ou encore du ranking.

Toutefois, j'ai pu échanger avec les gens de Vivastreet lors d'un entretien d'embauche et il m'ont demandé si j'avais déjà bossé le SEO d'un site en CDN ; nous n'avons pas développé le sujet mais le fait que je n'ai jamais bossé sur un tel mode d'acheminement de l'information n'a pas été rédhibitoire. Bon, j'arrête de raconter ma vie, là ! Il y a cependant peut-être certains aspects auxquels je ne pense pas. Si Cariboo ne répond pas ici tu peux lui faire un MP, je suis sûr qu'il aura la réponse.

.co.uk pour les US n'est pas adapté. .usc'est mieux. .com semble encore préférable (avec géolocalisation IP ou site via hébergement ou GWT, etc.), mais difficile de te conseiller efficacement sans connaître ton projet dans sa globalité (typologie de site, activité, objectifs de développement par pays, historique...).

[Nicolas]

Merci pour les réponses.

La version Fr est sur le .com et la version US sur le .net. A l'époque je n'avais pas prévu de version US et le .fr n'était pas encore très répandu.

La version FR a 1400 pages indexées. La version US aura certaines le double voir le triple (et p-e plus encore).

Le trafic est modeste pour la version FR et presque nul pour la version US (elle vient d'être lancée et je n'ai pas encore fait le référencement à part au niveau de la structure des pages).

Karnabal >> Je suis un peu embeté car je ne voudrai pas refaire de gros dev ou une mise en place couteuse pour un site qui pour le moment a un trafic presque nul (la verison US). Mais si les temps d'accès posent pb aux visiteurs et aux moteurs je risque pas d'en avoir ;-) mais tu sembles dire que ca ne pose pas de problèmes même pour des sites assez importants en contenu et en nombre de visiteurs quotidiens donc ca devrait aller.

La solution serait peut être alors de laisser comme ça au début et de mettre en place un CDN ou autre architecture si le site devient important et génère de gros revenus.

[karnabal]

Yep, lance ça sur un serveur unique.

J'ai bossé sur ce site de vente de pantalons sur mesure ; site internationalisé, serveur dédié, sans CDN. Ils ont bossé les temps de téléchargement il y a quelques mois. Je pense que s'il y avait eu un souci sur les versions étrangères auprès de l'audience non française ils l'auraient remarqué (taux de rebond plus important, moins de pages vues, etc. / serveur hébergé en France).

Quant à la question .com ou .us pour les States, ça dépend du marché que tu privilégies ; si c'est clairement les US, et compte tenu des faibles résultats actuellement sur la version FR, tu peux te permettre de basculer le .com sur les US quitte à le sucrer côté français (bien entendu, utiliser alors le .fr pour la version béret et baguette).

[Nicolas]

Merci !

Pour les extensions je suis d'accord sauf que le référencement est plus que correct pour la version FR (pas mal de backlinks y compris sur des pages autres que la homepage, termes importants qui ressortent de la top10, des pages qui ont plusieurs années d’existence etc ...) donc je suis pas très chaud pour changer ;-)

Est-ce que le .net peut poser problème pour un référencement us ?

[karnabal]

Ben moi j'évite les gTLDs si le site n'est pas hébergé (ou géoloc hébergeur) dans le pays ciblé. Bien sûr, on peut généralement géolocaliser le site avec les tools des moteurs de recherche mais si le .com n'est pas retenu, je préfère alors me rabattre sur le ccTLD adapté.

[Nicolas]

Merci.

Je vais tester le .net pour la version us ... on verra bien. Au pire je pourrai toujours changer si le référencement n'évolue pas trop.

[karnabal]

Géolocalise le bien via ton hébergeur s'il te le permet ainsi que par les outils des moteurs de recherche type GWT. Ce qui va faire la différence c'est surtout le netlinking, si tu parviens à obtenir des liens depuis des sites US ce sera une excellente chose, laquelle contribuera à bien géolocaliser cette version.

[Nicolas]

Merci pour les infos :-)

[Cariboo]

Anthony t'a tout expliqué pour "géolocaliser" correctement ton serveur aux US.

Concernant les inconvénients : le temps de réponse pour tes utilisateurs américains va augmenter de 200 à 300 ms en moyenne(parfois plus, ça dépend de l'hébergeur et du FAI de tes utilisateurs). Mais ce délai supplémentaire ne suffit pas à décourager un utilisateur, les rendering times pouvant eux monter à plusieurs secondes.

Bref une page qui se génère et se charge rapidement dans un browser restera suffisamment rapide pour les utilisateurs US pour que tout se passe bien.

Ensuite pour Google, pas de problème, tant que le temps de génération de la page + le temps de réponse du serveur + le temps d'acheminement des paquets = le temps de téléchargement vu par google, n'atteint pas des niveaux élevés. Rajouter des centaines de ms est embêtant, mais pas pour un petit site (quelques milliers de pages) et pas si tes perfs moyennes actuelles sont bien inférieures à la sec (genre 400/500 ms).

Après si ça coince, un simple reverse proxy aux US résoudra le problème, si ton site est suffisamment "statique".

[Nicolas]

Merci Cariboo,

Quand tu parles de reverse proxy c'est dans le but de créer un cache situé aux stats ?

Dans ce cas oui tout peut être mis en cache sauf le module de recherche.

[Cariboo]

Oui exactement,

Même sur le module de recherche, tu pourrais avoir un cache dynamique pour les pages les plus demandées.

Après la difficulté technique, c'est de rediriger tes utilisateurs US sur le reverse proxy, et les autres sur ton serveur en Europe. Après si tu envoies tout le monde sur le proxy, c'est plus simple...

Merci Cariboo,

Quand tu parles de reverse proxy c'est dans le but de créer un cache situé aux stats ?

Dans ce cas oui tout peut être mis en cache sauf le module de recherche.