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 !!!

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 :

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 :

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 :

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 :

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 :

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) :

Bim 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

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.

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

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.

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 !

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 ;-)

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

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

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.

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…

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