Créer un site en arabe, en français et en anglais sans ruiner son SEO

Une marque présente dans la région MENA et en Amérique du Nord finit par avoir besoin du même site en arabe, en français et en anglais. La demande ressemble à un travail de traduction. C'est surtout un travail d'architecture, et les décisions de la première semaine déterminent si le site accumule de l'autorité dans les moteurs ou la divise par trois.

Première décision : la structure des URL

Il existe trois modèles viables, et un modèle populaire qui ne l'est pas.

• Sous-répertoires — example.com/ar/, example.com/fr/. Toute l'autorité revient à un seul domaine. Le plus simple à gérer. La bonne réponse pour la grande majorité des entreprises.
• Sous-domaines — ar.example.com. Séparation plus nette si le contenu diffère réellement selon le marché, au prix de traiter chacun comme une propriété presque distincte.
• Domaines nationaux — example.tn, example.ca. Le signal local le plus fort, le coût le plus élevé, et vous gérez désormais plusieurs sites. Justifié quand l'offre, les prix et l'entité juridique diffèrent réellement selon le pays.
• Paramètres d'URL — example.com?lang=ar. À éviter. Les robots le gèrent mal et les utilisateurs ne peuvent pas partager un lien de façon fiable.

Sauf raison précise, utilisez les sous-répertoires. Tout ce que vous publiez, dans n'importe quelle langue, renforce un seul domaine plutôt que trois domaines faibles.

Deuxième décision : le hreflang, bien fait

L'annotation hreflang indique à un moteur de recherche quelle version d'une page montrer à quel utilisateur. Elle échoue plus souvent qu'elle ne fonctionne, pour des raisons purement mécaniques.

Chaque version linguistique doit référencer toutes les autres et elle-même. Les références doivent être réciproques : si la page arabe pointe vers la française, la française doit pointer en retour, sinon l'ensemble est ignoré. Utilisez des URL absolues complètes. Et déclarez une valeur x-default pour les visiteurs qui ne correspondent à rien.

Utilisez aussi les bons codes. L'arabe pour le Golfe est ar-AE; l'arabe pour la Tunisie est ar-TN; le simple ar couvre l'ensemble. Le français au Canada est fr-CA et diffère de fr-FR par un vocabulaire que les clients remarquent. Ne séparez par région que si le contenu diffère réellement ; sinon un seul code de langue est plus propre et plus difficile à casser.

Une erreur courante et coûteuse : faire pointer plusieurs valeurs hreflang vers une seule URL. Ce n'est pas un raccourci. C'est ignoré.

Troisième décision : la droite à gauche n'est pas une simple inversion de feuille de style

L'arabe inverse le sens de lecture, et avec lui la logique visuelle de la page. Le CSS moderne gère l'essentiel si le site a été construit dès le départ avec des propriétés logiques : margin-inline-start plutôt que margin-left, padding-inline plutôt que gauche et droite. Définissez dir="rtl" sur l'élément html et une mise en page bien construite se retourne en grande partie d'elle-même.

Ce qui ne se retourne pas tout seul :

• Les icônes directionnelles : flèches, chevrons et indicateurs de progression doivent s'inverser. Les logos et les boutons de lecture, non.
• Les chiffres et le texte latin : numéros de téléphone, prix et noms de marque restent de gauche à droite dans un paragraphe de droite à gauche. C'est dans le texte bidirectionnel que les mises en page se cassent.
• L'interlignage : l'écriture arabe demande plus d'espace vertical que le latin à taille égale. Copier l'échelle typographique latine donne un texte à l'étroit.
• L'allongement du texte : le français est environ 15 à 20 % plus long que l'anglais. Des boutons dimensionnés pour l'anglais déborderont.
• Les ombres et l'animation : tout ce qui a une direction a besoin d'une variante en miroir.

Les polices sont une décision de performance, pas de design

Les polices web arabes sont lourdes. Charger une famille arabe complète en plus d'une famille latine sur chaque page est un moyen simple de perdre le travail de performance fait ailleurs. Ne servez à chaque langue que la police dont elle a besoin, réduisez fortement les jeux de caractères et utilisez font-display: swap pour que le texte soit lisible avant l'arrivée du fichier.

Traduisez les métadonnées, pas seulement le corps

L'échec le plus courant des sites multilingues : le contenu visible est très bien traduit, et rien de ce que lit le robot ne l'est. Balises title, meta descriptions, textes alternatifs, données structurées, libellés du fil d'Ariane, slugs d'URL, libellés et messages d'erreur des formulaires doivent tous être traduits. Une page au corps arabe et à la balise title anglaise ne se positionnera pas sur les requêtes arabes.

Et traduisez les mots-clés plutôt que les mots. Le terme que tape un acheteur tunisien n'est souvent pas la traduction littérale du terme anglais : c'est parfois le mot français, parfois le mot anglais écrit en caractères arabes. C'est de la recherche de mots-clés, dans chaque langue, pas un travail pour une mémoire de traduction.

Ce que nous construirions réellement

Pour la plupart des entreprises dans cette situation : un domaine, des sous-répertoires par langue, un hreflang réciproque incluant x-default, des propriétés CSS logiques dès la première ligne, des polices réduites par langue et des métadonnées entièrement traduites. Rien d'exotique. Un ensemble de décisions peu coûteuses à prendre correctement au départ et chères à rattraper.

Nous produisons en arabe, en français et en anglais : ces décisions sont pour nous la règle, pas l'exception. Si vous préparez un site multilingue, nos pages développement web et SEO expliquent notre approche.