Comment gérer un site international très complexe de… 2 pages ?

C’est une discussion avec l’ami @david_libert au dernier SMX Paris qui m’a motivé à gratter ce billet. On discutait de la difficulté à bien gérer « techniquement » un site multilingue qui peut augmenter de manière exponentielle. Imaginons le scénario suivant : un e-commerçant qui souhaite décliner son site en plusieurs langues, plusieurs devises, et dont les produits sont également déclinés en plusieurs coloris, le tout sur un site proposant à ses visiteurs une version pour les dispositifs mobiles sur des URLs distinctes en sous-domaine (avec redirection transparente vers la pages équivalentes). Chaud devant !!!

Illustration SEO international

Il sera bien sûr question de la gestion des attributs rel canonical, rel alternate et hreflang, avec un soupçon de redirection. On abordera le duplicate content, le DUST, le near duplicate, et bien entendu la gestion des langues, des pays, et des devises. Tout ça mélangé, perversion assurée ^^
Sujet 100% technique, 100% pratique, 100% SEO !

Pour illustrer cet article et pousser la complexité à son paroxysme, je m’appuierai sur un site e-commerce fictif, volontairement minimaliste qui comporte 2 pages : la homepage -forcément-, et une page produit, soit 2 URLs au départ. Au fur et à mesure, on compliquera la structure des URLs avec divers paramètres jusqu’à obtenir une architecture absolument indigeste pour les moteurs. Dans la 2nd partie de l’article, on s’attachera à rendre toute cette bouillie d’URLs totalement optimisée pour le SEO.
Go !

Nos 2 URLs de départ :
2 URLs au départ

Simple.

L’éditeur du site n’a pas l’intention de se contenter du marché français. Il a faim, il veut gagner des parts de marché, et souhaite s’étendre sur la Suisse et l’Allemagne. Partant du principe que la langue par défaut est le français, il se retrouve avec des URLs déclinées de la manière suivante :

4 URLs

On passe à 4 URLs.

Comme le CMS utilisé n’est pas hyper optimisé niveau SEO, des URLs en DUST (« Duplicate URL Same Text ») font leur apparition :

Légende :
legende

5 URLs

5 URLs… et encore j’ai simplifié pour le DUST, c’est souvent bien pire dans la réalité.

Notre e-commerçant vise donc 3 pays, et 2 langues. Qui dit e-commerce dit monnaie, et dans notre exemple la Suisse joue les trouble-fête ;-) Ils ne veulent pas de l’euro (et on peut les comprendre). Bref, l’éditeur souhaite donc afficher des devises différentes en fonction des pays ciblés. CHF pour la Suisse, Euro pour la France et l’Allemagne. Aussi, notre éditeur est un marketeux aguerri, et il en profitera également pour faire du « content marketing » ciblé en fonction des pays (et non des langues). Par défaut, le site affiche des devises en euro et cible la France. On obtient alors :

Il y a la Suisse romande, et la Suisse alémanique, donc deux langues pour un seul et même pays, avec un focus marketing, et une devise spécifique (CHF).

9 URLs

Vous me suivez toujours ? Avec cette architecture d’url on peut normalement gérer les 3 pays indépendamment de la langue. Le hic, c’est que le DUST et le near duplicate s’invitent de partout.

Aller, vas-y Maurice, pousse le bouchon encore plus loin ! Supposons maintenant que le produit existe en 2 versions : blanc et noir. Vous trouverez certainement ça un peu tordu, mais ça n’a tellement rien d’exceptionnel… Le colori blanc du produit est la couleur par défaut, et ne génère pas de paramètre d’URL. Cela nous donne quelque chose comme ça :

13 URLs

De 3, on est passé à 13 URLs ! Et en prime, le duplicate content (DC) inonde le site, partant du principe que les déclinaisons couleur ne méritent pas de page dédiée (seule l’image change).

J’enfonce le clou : notre éditeur est plein de bon sens. Il sait que le trafic mobile est en train de dépasser celui du desktop, et il faut proposer une version adaptée. Le responsive webdesign n’a pas été retenu, au profit d’une déclinaison du site en sous-domaine (on discute pas, c’est comme ça) :

26 URLs !

GooglebotBim 26 URLs ! Ca devient pervers hein ? Je vous épargne les versions d’URLs avec et sans « www », https, etc.
Sincèrement, ne pensez pas que c’est caricatural, au contraire ! C’est presque un lieu commun, des sites comme ça j’en rencontre souvent dans ma région. Sans parler des CMS comme Drupal par exemple qui peuvent créer des quantités abyssales d’URLs dans ce genre de contexte.

Le site « bi-page » est maintenant plongé dans le chaos, et les profondeurs de Google. He oui, le Googlebot ne sait plus où donner de la tête, passe moins souvent, et le « jus » est totalement dilué. Notre éditeur est largué car il se retrouve face à une véritable problématique SEO qui nécessite une bonne maîtrise technique. Le référenceur du dimanche est lui aussi dans les choux. Avec ça, si on me dit que le SEO est mort…

Ok, c’est quoi le plan d’action ?

Phase I : Implantation du rel canonical pour éradiquer le duplicate content

Précisons d’amblé que le rel canonical doit être étendu à toutes les URLs du site et pas uniquement à celles générant du DC ou du DUST.

Mettons de côté pour le moment les URLs mobile qui recevront un traitement particulier. Avec l’implantation du rel canonical ça donne ça :

  1. domaine.fr
    <link rel="canonical" href="http://domaine.fr/" />
  2. domaine.fr/index.html
    <link rel="canonical" href="http://domaine.fr/" />
  3. domaine.fr/index.html?pays=ch
    <link rel="canonical" href="http://domaine.fr/index.html?pays=ch" />
  4. domaine.fr/index.html?lang=de
    <link rel="canonical" href="http://domaine.fr/index.html?lang=de" />
  5. domaine.fr/index.html?lang=de&pays=ch
    <link rel="canonical" href="http://domaine.fr/index.html?lang=de&pays=ch" />
  6. domaine.fr/produit.html
    <link rel="canonical" href="http://domaine.fr/produit.html" />
  7. domaine.fr/produit.html?pays=ch
    <link rel="canonical" href="http://domaine.fr/produit.html?pays=ch" />
  8. domaine.fr/produit.html?lang=de
    <link rel="canonical" href="http://domaine.fr/produit.html?lang=de" />
  9. domaine.fr/produit.html?lang=de&pays=ch
    <link rel="canonical" href="http://domaine.fr/produit.html?lang=de&pays=ch" />
  10. domaine.fr/produit.html?couleur=noir
    <link rel="canonical" href="http://domaine.fr/produit.html" />
  11. domaine.fr/produit.html?pays=ch?couleur=noir
    <link rel="canonical" href="http://domaine.fr/produit.html?pays=ch" />
  12. domaine.fr/produit.html?lang=de?couleur=noir
    <link rel="canonical" href="http://domaine.fr/produit.html?lang=de" />
  13. domaine.fr/produit.html?lang=de&pays=ch&couleur=noir
    <link rel="canonical" href="http://domaine.fr/produit.html?lang=de&pays=ch" />

Comme on peut le voir sur le graphique ci-dessous, le rel canonical fixe partiellement le problème. Le DUST à disparu, et le duplicate n’est plus un problème pour les URLs correspondant aux déclinaisons de couleurs (manifestez-vous si je me trompe), mais on reste toujours dans un contexte « near duplicate » où les pages ont un contenu très proche, aucune n’étant réellement unique aux yeux des moteurs.

Les URLs en DUST peuvent également faire l’objet d’une redirection permanente (301). Cette redirection sera déclarée dans l’entête HTTP, ou via une directive serveur (Apache) selon les cas.

Rel canonical

Phase II : Implantation du rel alternate et hreflang pour désigner des déclinaisons de langue, et de pays

L’idée n’est pas de vous exposer de manière exhaustive les vertus du rel alternate et hreflang puisque Google le fait très bien dans ses guidelines. Juste de vous montrer son intégration sur un scenario particulier, en cohabitation avec d’autres attributs.

Dans les grandes lignes rel alternate combiné à hreflang désigne aux moteurs toutes les déclinaisons linguistiques existantes d’une page (URL).

2 gros avantages pour les moteurs de recherche :

  1. Plus de problématique de duplicate content
  2. Meilleure distribution et positionnement dans les SERPs en fonction des pays

Concrètement, pour chaque page, on indique toutes les urls alternatives, y compris elle-même. Exemple avec les URLs découlant de produit.html :

  1. domaine.fr/produit.html
    <link rel="alternate" href="http://domaine.fr/produit.html" hreflang="fr-fr" />
    <link rel="alternate" href="http://domaine.fr/produit.html?pays=ch" hreflang="fr-ch" />
    <link rel="alternate" href="http://domaine.fr/produit.html?lang=de&pays=ch" hreflang="de-ch" />
    <link rel="alternate" href="http://domaine.fr/produit.html?lang=de" hreflang="de-de" />
    <link rel="canonical" href="http://domaine.fr/produit.html" />
  2. domaine.fr/produit.html?pays=ch
    <link rel="alternate" href="http://domaine.fr/produit.html" hreflang="fr-fr" />
    <link rel="alternate" href="http://domaine.fr/produit.html?pays=ch" hreflang="fr-ch" />
    <link rel="alternate" href="http://domaine.fr/produit.html?lang=de&pays=ch" hreflang="de-ch" />
    <link rel="alternate" href="http://domaine.fr/produit.html?lang=de" hreflang="de-de" />
    <link rel="canonical" href="http://domaine.fr/produit.html?pays=ch" />
  3. domaine.fr/produit.html?lang=de
    <link rel="alternate" href="http://domaine.fr/produit.html" hreflang="fr-fr" />
    <link rel="alternate" href="http://domaine.fr/produit.html?pays=ch" hreflang="fr-ch" />
    <link rel="alternate" href="http://domaine.fr/produit.html?lang=de&pays=ch" hreflang="de-ch" />
    <link rel="alternate" href="http://domaine.fr/produit.html?lang=de" hreflang="de-de" />
    <link rel="canonical" href="http://domaine.fr/produit.html?lang=de" />
  4. domaine.fr/produit.html?lang=de&pays=ch
    <link rel="alternate" href="http://domaine.fr/produit.html" hreflang="fr-fr" />
    <link rel="alternate" href="http://domaine.fr/produit.html?pays=ch" hreflang="fr-ch" />
    <link rel="alternate" href="http://domaine.fr/produit.html?lang=de&pays=ch" hreflang="de-ch" />
    <link rel="alternate" href="http://domaine.fr/produit.html?lang=de" hreflang="de-de" />
    <link rel="canonical" href="http://domaine.fr/produit.html?lang=de&pays=ch" />
  5. domaine.fr/produit.html?couleur=noir
    <link rel="canonical" href="http://domaine.fr/produit.html" />
  6. domaine.fr/produit.html?pays=ch?couleur=noir
    <link rel="canonical" href="http://domaine.fr/produit.html?pays=ch" />
  7. domaine.fr/produit.html?lang=de?couleur=noir
    <link rel="canonical" href="http://domaine.fr/produit.html?lang=de" />
  8. domaine.fr/produit.html?lang=de&pays=ch&couleur=noir
    <link rel="canonical" href="http://domaine.fr/produit.html?lang=de&pays=ch" />

C’est ok ? Remarquez que je n’ai pas traité les URLs avec les déclinaisons de couleurs avec rel alternate. Facultatif voir inutile étant donné qu’elles ne sont pas destinées à se positionner dans les moteurs, ni à être indexées, l’attribut canonical renvoyant vers l’url canonique sans paramètre de couleur. Inutile également d’intégrer une balise meta noindex.

Cas particulier : Selon les cas, il se peut que l’éditeur ne souhaite pas assigner un pays spécifique à sa home page pour couvrir le plus de pays possible. La valeur de l’attribut hreflang doit être alors "x-default".

A partir de là, croyez-vous que le duplicate est définitivement éradiquée ? Et non, Toujours pas de drapeaux verts ! La version mobile est toujours là pour dupliquer le site !

Duplication avec mobile

Phase III : Le rel alternate, ce n’est pas que pour les langues ou les régions !

He oui, vous l’avez compris, on va encore ajouter une ligne rel alternate sur chacune des pages du site (desktop) pointant vers les pages correspondantes du site parallèle pour mobile en sous-domaine.

Par exemple, pour l’URL domaine.fr/produit.html?pays=ch on doit retrouver dans la partie <head> de la page l’ensemble des annotations suivantes :
<link rel="alternate" href="http://m.domaine.fr/produit.html?pays=ch" media="only screen and (max-width: 640px)" />
<link rel="alternate" href="http://domaine.fr/produit.html" hreflang="fr-fr" />
<link rel="alternate" href="http://domaine.fr/produit.html?pays=ch" hreflang="fr-ch" />
<link rel="alternate" href="http://domaine.fr/produit.html?lang=de&pays=ch" hreflang="de-ch" />
<link rel="alternate" href="http://domaine.fr/produit.html?lang=de" hreflang="de-de" />
<link rel="canonical" href="http://domaine.fr/produit.html?pays=ch" />

Et ce n’est pas terminé ! Côté URL mobile, c’est-à-dire http://m.domaine.fr/produit.html?pays=ch il faut intégrer un rel canonical renvoyant vers l’URL desktop, C’est impératif :
<link rel="canonical" href="http://domaine.fr/produit.html?pays=ch" />

Bingo ! Les drapeaux verts sont revenus ;-)

Rel alternate + canonical

A partir de là on peut considérer que techniquement, le site est optimisé pour le multilingue, et « DC free ».

Ne jamais rediriger systématiquement l’ensemble du trafic vers une langue ou un pays spécifique ! Le crawl des robots d’indexation pourrait s’en retrouver faussé, et pénaliser le référencement. Le bon usage veut que le choix de la langue soit en premier lieu celle proposée par le moteur de recherche lors de la requête, puis celle de l’internaute qu’il aura choisi de lui-même (choix mémorisé par un cookie).

De l’utilité du sitemap.xml

Il m’est arrivé d’entendre dans la sphère SEO que le fichier sitemap.xml n’avait pas grand intérêt du moment que le site était facilement indexable. Oui, mais non ! Si il y a une part de vrai, le rôle du sitemap.xml ne se cantonne pas qu’à la découverte des URLs par les robots d’indexation ! Dans le contexte d’un site multilingue, il est tout à fait possible de faire passer les annotations rel alternate directement dans le fichier sitemap.xml. Cela peut s’avérer très utile quand l’intégration technique de ces dernières s’avère compliquée (et ça arrive hélas souvent).

Voici un exemple de fichier sitemap.xml exploitant les attributs rel alternate et hreflang :

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
  xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>http://domaine.fr/produit.html</loc>
    <xhtml:link 
                 rel="alternate"
                 hreflang="fr-fr"
                 href="http://domaine.fr/produit.html"
                 />
    <xhtml:link 
                 rel="alternate"
                 hreflang="de-de"
                 href="http://domaine.fr/produit.html?lang=de"
                 />
    <xhtml:link 
                 rel="alternate"
                 hreflang="de-ch"
                 href="http://domaine.fr/produit.html?lang=de&pays=ch"
                 />
    <xhtml:link 
                 rel="alternate"
                 hreflang="fr-ch"
                 href="http://domaine.fr/produit.html?pays=ch"
                 />
  </url>
  
  (...)
</urlset>

Reste une ombre au tableau : le jeu de redirections entre site desktop et mobile.

Bonus : Stratégies de redirections par détection du « user-agent » (du site desktop vers site mobile)

Pas question de faire ça à l’ancienne et à l’arrache en redirigeant tout le trafic mobile vers la racine du site mobile (m.domaine.fr). Le mobinaute devra être redirigé de manière transparente vers la page correspondant à sa recherche (la plus adaptée au cas échéant), le tout en détectant automatiquement son dispositif (Kindle, tablette, phablette, smartphone etc).

Stratégie de redirection pour mobiles

Redirections via .htaccess vs entête HTTP

Premier point très important, dans ce genre de scenario, il ne faut pas créer de table de redirection dans le .htaccess pour des raisons évidentes de maintenance et de charge serveur. En effet, le fichier .htaccess est interprété par le serveur web à chaque affichage de page, et plus il y aura de règles de redirection, plus la charge du serveur augmentera. La redirection doit donc s’opérer au niveau de l’entête HTTP de la page appelée, via une fonction PHP (par exemple) si le site utilise ce langage. Par ailleurs on préférera toujours les redirections « server side » aux redirections « client site » en JavaScript.

La redirection mise en place devra donc renvoyer les mobinautes vers l’URL désignée dans l’attribut rel alternate de la page source.

Syntaxe appropriée et conforme aux consignes de Google

Google a récemment clarifié ses consignes pour les développeurs au sujet des redirections spécifiques aux dispositifs mobiles. Concernant notre scénario, Google préconise une redirection 302 :

« redirigez correctement le contenu optimisé pour les smartphones vers la nouvelle URL dédiée aux smartphones à l’aide de redirections HTTP côté serveur 302 (nous vous conseillons de ne pas utiliser les redirections JavaScript), et configurez un en-tête HTTP « Vary: User-Agent » pour faciliter la détection du user-agent. »

Ce qui donne ce type de syntaxe PHP :

<?php
header("Status: 302 Moved Temporarily", FALSE, 302);
header("Vary: User-Agent");
header("Location: http://mobile.monsite.com/" . $_SERVER['REQUEST_URI']);
exit();
?>

Détection du user agent (en PHP) avec la classe Mobile_Detect

Voilà une classe PHP qui facilite grandement la détection des dispositifs mobiles. Bien plus pratique que de maintenir à jour une liste complexe de user-agent, terminaux, OS, etc. avec les erreurs que cela peut induire. Cette classe peut être consultée et téléchargée sur Github.

Exemple d’intégration et d’utilisation :

include 'Mobile_Detect.php';
$detect = new Mobile_Detect();
 
if ($detect->isMobile()){
// Action pour un mobile
}
 
if($detect->isTablet()){
// Action pour une tablette
}
 
if($detect->isiOS()){
// Action pour un appareil sous iOS
}
 
if($detect->isAndroidOS()){
// Action pour un appareil sous Android
}

Pour conclure et aller encore plus loin…

Drapeaux du monde
Mon article ne fait qu’effleurer le SEO international, et la complexité est très souvent plus grande et plus vicieuse sur le « terrain ». Je n’ai abordé que l’aspect technique avec un focus sur les URL, dans un contexte bien précis. Le SEO international et multisupport doit également puiser dans le marketing, l’étude de mots clés, et plans d’action tactiques et stratégiques. Souvent les éditeurs et marketeux qui se lancent la fleur au fusil sur l’international, ne se rendent pas compte des pré-requis nécessaires, causant parfois de véritables naufrages SEO/SEM.

On dit parfois qu’on reconnaît un bon SEO par sa faculté à maîtriser pleinement le volet international. J’adhère complètement. C’est aussi pour ça que j’aime creuser ce genre de sujet, et paradoxalement, plus je creuse, plus je me rends compte qu’il me reste encore beaucoup à apprendre (surtout sur le plan marketing).

Quelques ressources complémentaires sur le sujet :
Establishing Your International SEO Strategy: How to Start Your International Web Presence (Par l’incontournable Aleyda Solis) (EN)
– Consignes de Google sur l’optimisation pour smartphones et phablettes : ici et ici
– Détecter les terminaux mobiles avec la classe PHP Mobile Detect par Netmacom.fr
Spécial SMX Paris 2014 :
– Les slides d’Aymeric Bouillat tirées de sa conférence « Site mobile et SEO – les erreurs à ne pas commettre »
– Les slides d’Aleyda Solis (encore elle) tirées de sa conférence « Taking your International SEO to the next level »
Vous pouvez avoir un lien en DoFollow si :
  • Vous ne faites pas de lien optimisé (brand ok).
  • Votre contribution apporte de l'eau au moulin et ne se contente pas de remercier (même si c'est toujours appréciable).
  • Vous ne donnez pas l'impression de ne pas avoir lu l'article.
  • Votre site doit graviter dans l'univers du SEO / web marketing / IT.
  • Nouveau : Se suivre mutuellement sur Twitter (oui ça fait copinage, et j'assume !).
Le but n'étant pas d'être plus sévère, mais au contraire plus équitable et... naturel. N'oubliez-pas : moins de spamco = meilleur jus !

26 réflexions au sujet de « Comment gérer un site international très complexe de… 2 pages ? »

  • Aurélien, encore un article qui va devenir incontournable. J’ajouterai une évidence : faire les liens entre les différentes versions linguisitiques. La page en allemand propose un lien vers l’équivalent français et l’équivalent italien (j’ajoute une couche frontalière) par exemple. Ce lien « en dur » possède bien entendu son hreflang et permet à quiconque arriverait sur une page mieux positionnée dans une langue étrangère de s’y retrouver immédiatement. Ça peut paraître évident mais l’internaute ne maîtrise pas toujours sa configuration (géolocalisation, langue par défaut du navigateur), ou au contraire très bien (proxy, plugin qui change l’user agent, etc) et peut se retrouver un peu coincé.

  • Bonjour Aurélien,

    Encore un excellent article. :)

    Pourquoi n’aborde-tu pas tout les possibilités comme les sous domaines en fr.monsite.com / ch.monsite.com / de.monsite.com ou encore le dépôt d’un ndd par pays ?

  • Wow !
    Au départ, je ne savais pas quoi mettre d’autre dans le commentaire, car « WOW » résume quand même bien le fond de ma pensée.
    Bref, tu m’as réconcilié avec le sitemap.xml, c’est fort, et tu as raison sur cette utilisation exemplaire.

    En fait, je n’ai pas souvent ce type de problème sur nos devs sur mesure, en revanche, dès que l’on s’attaque à des CMS, on découvre souvent ce genre de chose et on part à la lampe spéléo.

    Sylvain

  • Excellente démonstration.

    Tu fais bien de préciser qu’en cas d’installation des balises hreflang il faut ajouter la balise qui pointe vers la page elle-même (URL canonique) car ce n’est absolument pas clair dans l’aide de GG.

  • Salut Aurélien

    Il est tres tres bon cet article – moi qui suis dedans je peux dire que ca se complique meme encore plus que cela – puisque ‘en prime je dois gérer du multi-domaine dont certains multilingues et crois mois quand tu as des sites sur les US (5 entitées au total) / UK / CA (en + Fr) / AU et NZ tu n’a pas que le DUST a gérer – tu as aussi le pur duplicate, la concurrence entre entitées, le fait que les canadiens et les US ont tendances a faire leurs achats sur un des pays ou l’autre en fonction des variations de prix et le taux de change… Il faut aussi penser au nouveau produits a ceux qui sortent de l’inventaire, au produits en rupture de stock, au soft 404 etc … bref je suis au commande d’une usine a gaz –

    Par contre ce que je trouve dommage c’est que tu partes d’entrée de jeu sur de mauvais choix – Alors oui c’est fait expres pour des raisons d’illustration des principes mais bon entre nous si un de tes clients e-commerce veut faire du Fr et du De sur 3 pays dont un multilingue a priori moi je vais lui conseiller du multidomaine tout de suite – rester surt un .fr et faire changer les langues seulement c’est quand meme se compliquer la vie a la base tu ne trouves pas???

  • Très bon article, complet et instructif. J’ai lu les Guidelines de Google sur le sujet et j’avoue que des exemples en français c’est bien utile.

    J’ai eu à me démener récemment avec certaines personnes d’une agence de traduction dont j’ai refait le site pour leur expliquer que les redirections forcées en fonction de l’IP n’était pas une bonne idée, et c’est dur à avaler pour eux.

    Je trouve l’installation des balises alternate encore plus complexes que les canonical.
    A ce sujet, j’ai lu qu’il ne fallait pas utiliser à la fois canonical et hreflang, mais je ne comprends pas pourquoi. Peux-tu me donner ton avis sur ce sujet.

    Christophe

  • @Sylvain : Je suis un piètre développeur, et je ne sais pas si la maintenance d’un fichier sitemap.xml est plus simple que d’implanter / développer une fonction au coeur du CMS. Ca a le mérite d’être une bonne alternative en tout cas.

    @Le Juge : On est complètement d’accord sur le fond. Mais comme tu l’as souligné, c’est pour l’exemple, pour simplifier un scénario déjà bien complexe, et pour me concentrer uniquement sur l’aspect technique et les annotations. Le multidomaine est plus un choix stratégique qui demandera sans doute plus de maintenance. J’en parlerai sans doute dans un autre billet sur l’international (vaste sujet). Ton expérience montre en tout cas à quel point ça peut être complexe !

    @hilmoine : Ou as-tu lu qu’il ne fallait pas utiliser rel canonical et hreflang ?

  • Merci Aurélien pour cet article bien tourné, notamment sur le plan didactique.
    Concernant l’utilisation du sitemap au lieu des annotations, le risque est peut-être que le sitemap ne soit pas exhaustif (et donc que certaines pages n’aient pas d’annotations alors qu’elles devraient en avoir).

    Autre détail : tu as utilisé un .fr dans ton exemple. Trouves-tu que ce soit approprié d’utiliser un .fr pour viser le marché de l’Allemagne et de la Suisse ? Ne conseilles-tu pas d’utiliser soit un .com soit .de + .ch ?

  • Concernant canonical et hreflang, ils en parlent ici : http://dejanseo.com.au/canonical-vs-hreflang/ et je crois l’avoir lu ailleurs.

    Une autre question, la logique que tu expliques est-elle la même si les pages dans une autre langue sont sur un autre sous-domaine ou domaine, par exemple de.domaine.com/produkt.html serait la version allemande de domaine.fr/produit.html ?

    En d’autres termes, peut–on mettre des urls externes dans les attributs alternate ?

  • @hilmoine : Merci pour ton retour. Effectivement, il y a une mise en garde (par Google) sur l’utilisation conjointe du hreflang ET du canonical, mais cela concerne surtout un contexte bien particulier comme le cross-domain (au passage ces annotations peuvent être cross-domain, oui). Dans notre scenario, cela ne pose pas de problème puisque le rel canonical pointe toujours vers la langue&pays ciblé. Google devrait donner plus de détails sur ce point.

  • Bonjour Aurélien,

    Ton article est évidemment une parfaite synthèse technique, mais je rejoins totalement Le Juge sur le multidomaine. Ne pas utiliser les tld par pays ciblé, c’est se priver d’un critère très important pour le SEO. On connait la personnalisation des serps (selon historique perso, recherches, …) depuis quelques temps, mais la personnalisation selon chaque version nationale de Google est bien plus ancienne encore, preuve que c’est un critère important pour le moteur. Attention toutefois à ne pas verser dans l’excès inverse, un tld N’EST PAS équivalent à un critère de langue (la confusion est souvent entretenue sur différents blogs) En clair, utiliser un .de pour cibler la communauté suisse allemande n’est pas une bonne idée, tant d’un point de vue SEO que marketing.
    Pour rester sur le point purement technique, mais moins seo (quoique qui sait si ce n’est pas un critère de l’algo, certes forcément très léger), l’utilisation de l’utf-8 s’impose !!

  • @David Alexandre, @Olivier, @Omnireso : désolé vous étiez dans les indésirables ! Rhooo….

    @David Alexandre : parce que je voulais partir d’un scénario précis pour faciliter la compréhension de l’utilisation des annotations rel alternate et hreflang. Tout couvrir le chapitre international demanderait beaucoup plus de temps et de pages… Un jour peut-être je ferai un billet spécifique sur le choix entre tld, sd, répertoire, ou paramètre d’url pour gérer les pays/langues.

    @Olivier : Pour mon exemple, j’aurais peut-être du utiliser un .com, plus « neutre », certes. Cela dit, hreflang (ou un choix de langue dans GWT) devrait permettre de lever toute ambiguïté sur le TLD (.fr). D’ailleurs j’ai déjà vu des NDD 100% français jouer avec le TLD .de , et ne souffrir (a priori) d’aucun problème.

    @Omnireso : oui merci pour ces précisions ;) Y’a beaucoup à dire sur ce sujet, et je ne pouvais tout aborder en une seule passe…

  • Encore une petite réflexion, la balise link rel= »alternate » ne semble donner aucun jus à la page ciblé. C’est une observation basée sur quelques cas et non une analyse. J’aimerais savoir si d’autres ont constaté la même chose que moi?
    Si tel était le cas, je trouve ça dommage que les moteurs ne donnent pas cette carotte supplémentaire aux webmasters pour implémenter correctement ces balises, puisque c’est dans leurs intérêts également.

  • @Fred H : heu… je ne peux pas te répondre avec certitude sur le fait que le rel alternate passe le jus ou pas, mais je ne pense pas. Mais cela ne veut pas dire qu’il n’y aura pas d’impact sur le ranking pour autant. Perso, je n’ai pas besoin d’une carotte avec un transfert de « jus » à la clé pour m’inciter à implanter et recommander l’utilisation de cette annotation.

  • On est bien d’accord sur le ranking, si elle est crawlée et indexée grâce à l’annotation, elle peut ranker si elle est pertinente. Je l’utilise ou recommande également systématiquement, mais outre l’argument en faveur des webmasters, je trouve ça plutôt illogique que ça ne transfert pas un peu de jus. C’est quand même une « recommandation » forte envers une page, pour moi, presque au même titre qu’un lien dans du contenu.

  • « un choix de langue dans GWT) devrait permettre de lever toute ambiguïté sur le TLD (.fr) »
    justement non, car ce paramétrage n’existe pas dans GWT : on peut seulement spécifier un pays

  • Salut Aurélien
    Merci pour cet excellent article. En plein dans le mille !!
    Effectivement cette discussion au smx m’a fait prendre conscience que j’avais pas mal de boulot :-)) 17 pays avec la Belgique (2 langues), la Suisse (2 langues) et l’allemand qu’on retrouve sur 3 pays (allemagne, suisse alémanique et autriche)
    Pour notre part on est sur des tld propres à chaque pays et des sous-domaines pour les pays multilangues : f.domaine.ch et de.domaine.ch. Mais ton exemple permet de bien comprendre les href et alternate.
    Le gros problème que je suis en train de résoudre c’est l’automatisation des href lang. Les mêmes produits ont des url optimisées dans leurs langues. Quand tu crées un produit dans une nouvelles langue il faut donc générer un hreflang qui reprendra automatique les différentes url pour le même produit dans les autres pays….
    Bref débuter le SEO sur du multi-langue c’est bien sympa :-)
    Pas mal du tout le coup du 302 pour le mobile.
    Bref je digère tout ça, je relis doucement, comme avec beaucoup de tes articles et j’applique :-))
    A plus

  • Très bon résumé, je me demandais si tu allais parler du sitemap pour simplifier la mise en place de l’alternate et du hreflang, c’est surement l’un des aspects les plus pratiques qui prouve qu’il est encore utile pour bosser son SEO, surtout dans une configuration aussi complexe. Pour la V2 de cet article il pourrait etre intéressant de décrypter le choix à faire lors de l’ouverture sur un pays : sous-domaine, domaine avec extension différente ou encore répertoire ?
    Je partage !

  • Tu parlais de 2 pavés en préparation…..
    J’attends le 2ème avec impatience maintenant ;-)

    Sinon je me réjouis d’avoir le retour de David et de ce qu’il y a pu mettre en place.
    Parce que souvent on oublie les facteurs bloquants au sein de l’entreprise qui t’empêche de pouvoir faire les modifications nécessaires…pour des bonnes ou mauvaises raisons.

  • @Patrick : oui il reste un « pavé »… encore qu’au point ou j’en suis (environ 6000 mots) je ne sais plus si on peut appeler ça un pavé ^^ Publication semaine prochaine si tout va bien :)

  • Bonjour Aurélien,

    Merci pour cet article. Il est béton.

    Question: Si j’ai des noms de domaines différents par pays dont plusieurs sont en plusieurs langues (monsite.fr, monsite.co.uk, monsite.be, etc…), le procédé est le même à ton avis?

    En l’occurrence, j’ai opté pour le sitemap.xml. Si je fais des alternate pour chaque version Langue-Pays est-ce que ça te paraît ok?

    Merci pour ta réponse.

    D.

  • @dmaradona : Dans le cas d’une stratégie multilingue en ccTLD (.fr, .co.uk, .it etc), le procédé peut varier (voir plus haut avec par exemple le rel canonical). Sinon, pour les rel alternate dans un sitemap.xml + ccTLD, je ne vois pas de problème à priori.

  • Merci.

    Au fait, ça fait quelques temps que je suis ton blog, et je trouve qu’il est bestial. Il n’y a pas un seul article de qualité moyenne. Tous très, très bons.

    D.

  • Très bon article !

    Mais j’ai eu récemment affaire à un gros mic mac, lié au fait que des clients espagnols, avec un navigateur en es-es sûrement, ont commandé depuis le … Mexique, non désservi par la plateforme logistique européenne.

    Existe t’il, hormis les scripts de géolocalisation PHP (qui bloquent les validations d’annonces AdWords à cause de l’URL à afficher et nous empêchent de faire de la pub, ce b..d.l !!!! ) une solution propre en SEO pour traiter l’utilisateur par zone de connexion et non par langue de configuration du navigateur ? Ceci afin d’éviter les appels au service client de clients furax de ne rien voir venir … Alors qu’ils ont commandé et que la redirection les a renvoyé vers notre site et non le site américain… et ça arrive de plus en plus souvent :/

Les commentaires sont fermés.