Un client m'a approché en 2021 avec un produit SaaS qui avait été en ligne en cinq langues depuis deux ans. Trafic en provenance d'Allemagne : 38 sessions par mois. De la France : 22. Ses pages en anglais classaient bien, mais chaque version localisée était pratiquement invisible. Ils avaient payé une agence pour traduire la copie, quelqu'un avait installé WPML, et puis tout le monde avait supposé que le travail était fait.
C'était loin d'être terminé.
Le SEO de localisation est l'un de ces domaines où faire 60 % du travail correctement est quasi identique à ne rien faire. Rater hreflang. Choisir la mauvaise structure d'URL. Sauter les signaux locaux. Résultat : Google ignore complètement vos pages traduites ou, pire, les traite comme du contenu dupliqué et les filtre. J'ai résolu ce problème sur des centaines de sites au cours des neuf dernières années chez Seahawk, et le motif d'échec est presque toujours le même.
Examinons donc ce qui marche vraiment.
---
La traduction n'est pas la localisation
C'est la première chose que je dis à chaque client. La traduction, c'est convertir des mots d'une langue à une autre. La localisation, c'est reconstruire l'intention d'une page pour un marché spécifique.
Prenez un client de l'e-commerce britannique que nous avions fin 2022. Il vendait des couteaux de cuisine haut de gamme. Ses pages allemandes étaient une traduction mot-à-mot du texte anglais, incluant des phrases comme « parfait pour les rôtis du dimanche ». Les Allemands ne font pas de rôtis du dimanche. Le texte était grammaticalement correct et complètement faux.
Mais au-delà de la culture, les implications SEO sont réelles. Les volumes de mots-clés ne se traduisent pas. La requête anglaise « best chef knife » génère environ 8 100 recherches par mois au Royaume-Uni. L'équivalent allemand « bestes Kochmesser » en génère bien moins, mais « Kochmesser Test » (grosso modo « test/avis sur les couteaux de cuisine ») est énorme. Si votre page traduite cible la traduction littérale de votre mot-clé anglais, vous optimisez pour la mauvaise chose.
Avant d'écrire un seul mot de contenu localisé, lancez une recherche de mots-clés dans la langue cible, dans la région cible en utilisant Google Keyword Planner avec le pays défini correctement, ou Ahrefs avec le filtre de pays appliqué. Ce n'est pas la même chose que de lancer une recherche en anglais. Traitez chaque marché comme un nouveau site du point de vue des mots-clés.
Ce que « Localisé » signifie réellement en pratique
- Tarification en devise locale, avec références aux modes de paiement locaux
- Dates, adresses et unités formatées pour ce pays (JJ/MM par rapport à MM/JJ a son importance)
- Exemples, idiomes et références qui résonnent localement
- Signaux de confiance spécifiques au pays (les acheteurs allemands font confiance aux certifications locales ; les acheteurs français réagissent à des preuves sociales différentes de celles des Brésiliens)
---
Structure des URLs : vous tromper là-dessus et rien d'autre n'aura d'importance
J'ai vu cet argument faire dérailler tant de projets. ccTLD vs sous-domaine vs sous-répertoire. Les gens en font une question de principe.
Voici mon analyse honnête après avoir construit et migré des centaines de sites internationaux : les sous-répertoires sont généralement le bon choix pour la plupart des entreprises. Quelque chose comme yoursite.com/de/ plutôt que de.yoursite.com ou yoursite.de. Les raisons sont pratiques : toute votre autorité de domaine se consolide, c'est plus facile à gérer en un seul endroit, et Google gère bien cela quand hreflang est configuré correctement.
Les ccTLD (yoursite.de, yoursite.fr) envoient un signal local fort. Si vous êtes un acteur sérieux sur un marché spécifique et que vous pouvez vous engager à gérer essentiellement des sites distincts, ils en valent la peine. Seahawk avait un client fintech qui insistait sur des ccTLD distincts pour six pays en 2020, et oui, cela a bien fonctionné sur ces marchés. Mais leur surcharge de développement a triplé. Pour la plupart des agences construisant pour des clients, ce n'est pas réaliste.
Les sous-domaines (de.yoursite.com) sont le pire des deux mondes dans la plupart des cas. Plus difficiles à maintenir que les sous-répertoires, signal d'autorité plus faible que les ccTLD. Je les éviterais à moins que votre architecture CMS ne force vraiment la question.
Quel que soit votre choix : soyez cohérent. Ne mélangez pas les structures. J'ai hérité de sites avec des pages /fr/ et un sous-domaine fr. fonctionnant simultanément, tous deux indexés. C'est un cauchemar.
---
Hreflang : la partie la plus couramment cassée de l'international SEO
Si vous ne retenez qu'une chose de cet article, que ce soit celle-ci.
Hreflang indique à Google quelle version d'une page afficher à quel utilisateur, dans quelle langue et quel pays. Si vous vous trompez, vous risquez que vos pages en anglais américain s'affichent en Allemagne, que vos pages en allemand ne se classent pas du tout, ou, mon scénario catastrophe préféré, que votre x-default pointe vers une page qui redirige ailleurs.
Le format de la balise ressemble à ceci dans votre <head> :
`` <link rel="alternate" hreflang="de" href="https://yoursite.com/de/page/" /> <link rel="alternate" hreflang="en-GB" href="https://yoursite.com/en-gb/page/" /> <link rel="alternate" hreflang="x-default" href="https://yoursite.com/page/" /> ``
Voici quelques points qui font régulièrement trébucher les gens :
- Chaque page doit référencer tous les alternats, y compris elle-même. Si votre page en allemand ne renvoie pas vers la page en anglais, et que la page en anglais ne renvoie pas vers l'allemand, l'implémentation est cassée.
- Codes de langue versus codes de langue-région.
hreflang="en"signifie « anglais, toute région ».hreflang="en-GB"signifie « anglais, Royaume-Uni spécifiquement ». Si vous essayez de cibler le Royaume-Uni et les États-Unis séparément, vous avez besoin du code de région. - Balises de retour. La page en allemand doit contenir une balise pointant vers la page en anglais. La page en anglais doit contenir une balise pointant vers l'allemand. Les deux. Toujours.
- Cohérence avec les balises canoniques. Votre URL hreflang alternatif et votre URL canonique pour cette page doivent correspondre. Exactement. Y compris les slashes finales.
J'utilise le générateur de balises hreflang d'Aleyda Solis quand je les configure manuellement. Et j'audit toujours avec Screaming Frog après. Toujours.
---
Signaux locaux : le détail que tout le monde oublie après le lancement
Un hreflang correct et une page bien localisée vous mènent peut-être à 50 % du chemin. L'autre 50 %, c'est le signal : Google a-t-il une raison de croire que vous êtes une entité légitime sur ce marché ?
Pour la plupart des sites, cela signifie :
- Des backlinks locaux. Un lien d'un domaine allemand .de vers vos pages
/de/a un poids significatif. Des liens issus de médias français vers vos pages françaises, c'est la même chose. Obtenir un lien d'un blog américain vers votre contenu allemand n'aide pas près autant que les gens le supposent. - Google Business Profile. S'il y a une présence physique, même une adresse enregistrée, créez un GBP pour ce lieu. Remplissez-le correctement. C'est l'essentiel pour la visibilité du local pack.
- Schema local. Ajoutez un schema
LocalBusinessavec le bon pays, le format d'adresse correct et le format de numéro de téléphone correct. Ne copiez pas simplement votre schema anglais et ne traduisez pas la description. Les données structurées doivent correspondre aux spécificités de la locale. - Emplacement de l'hébergement. Moins important qu'avant avec les CDN, mais si vous utilisez un CDN (et vous devriez en utiliser un), confirmez que vos nœuds périphériques servent les utilisateurs européens à partir de serveurs européens. Le plan gratuit de Cloudflare gère cela. Ce n'est pas un énorme facteur de classement mais cela contribue au TTFB dans cette région, ce qui compte.
En 2019, j'avais un client dans l'espace des compléments alimentaires qui essayait de se classer en Espagne. Sa localisation était bonne. Son hreflang était correct. Mais il n'avait zéro backlinks espagnols, son GBP pour son adresse à Madrid n'était pas revendiqué, et son schema listait toujours un numéro de téléphone britannique. Corriger ces trois choses sur environ quatre mois les a fait passer de la page 4 à la page 1 pour trois de leurs termes cibles.
---
La profondeur du contenu varie selon le marché
C'est quelque chose que la recherche de mots-clés ne vous dira pas complètement. Certains marchés ont une forte demande informationnelle ; d'autres convertissent sur des pages produit minimalistes.
L'Allemagne est réputée pour être très minutieuse. Les chercheurs allemands ont tendance à vouloir du contenu de comparaison détaillé, des tableaux de spécifications et des politiques de retour claires avant d'acheter quoi que ce soit. Une page produit de 300 mots qui convertit au Royaume-Uni pourrait avoir besoin de 900 mots avec une section FAQ pour performer en Allemagne.
Le Japon en est un autre. Les résultats de recherche japonais pour les requêtes commerciales présentent souvent du contenu très détaillé et long format. Le SERP est différent, le comportement des utilisateurs est différent, et les attentes en matière de contenu reflètent cela.
Je ne dis pas d'écrire 2 000 mots pour chaque marché juste parce que vous le pouvez. Je dis : regardez ce qui classe réellement dans ce pays, dans cette langue, pour votre requête cible. Ouvrez une fenêtre incognito, réglez manuellement votre pays Google, et regardez les trois premiers résultats. Quelle est leur longueur ? Ont-ils une vidéo ? Ont-ils des tableaux ? Ont-ils des avis utilisateurs intégrés ? C'est votre benchmark, pas ce qui fonctionne en anglais.
---
La Liste de Vérification d'Audit Technique Avant le Lancement
Avant que tout site international ne soit lancé depuis Seahawk, nous passons en revue ceci dans l'ordre :
- Confirmez que la structure URL est cohérente sur toutes les locales
- Validez les balises hreflang sur chaque type de page (accueil, catégorie, produit, blog) en utilisant Screaming Frog
- Vérifiez que les balises canoniques s'alignent exactement avec les URL alternatives hreflang
- Vérifiez que x-default est défini et pointe vers une page active, sans redirection
- Testez les paramètres de ciblage géographique dans Google Search Console (rapport Ciblage international, sous Outils hérités)
- Confirmez que le sitemap XML inclut toutes les URL localisées et est soumis par locale si vous utilisez des propriétés distinctes
- Vérifiez la vitesse des pages depuis les régions cibles avec WebPageTest en utilisant un nœud européen ou asiatique
- Validez le schéma LocalBusiness avec l'outil Test des résultats enrichis de Google pour au moins une page représentative par locale
Ce ne sont pas tous les contrôles que nous effectuons. Mais si ces huit éléments sont en ordre, la fondation est assez solide pour commencer à construire dessus.
---
Le Jeu de la Patience : Délais et Attentes
Voici quelque chose que j'aimerais pouvoir afficher sur un panneau publicitaire pour chaque client qui nous consulte pour le SEO international : cela prend plus de temps que le SEO anglophone. Beaucoup plus longtemps, parfois.
Quand vous lancez une nouvelle section localisée, vous lancez essentiellement un nouveau site du point de vue de Google sur ce marché. Vous n'avez pas d'historique de backlinks locaux. Vous n'avez pas de signaux d'engagement locaux. Vous n'avez pas d'historique de requêtes. Google est prudent.
Calendrier réaliste : 3 mois pour voir du mouvement, 6 mois pour commencer à tirer des conclusions, 12 mois pour évaluer réellement si votre stratégie de localisation fonctionne. Je sais que ce n'est pas ce que tout le monde veut entendre. Mais les clients qui commencent avec cette attente sont beaucoup moins susceptibles d'abandonner au mois 4 quand ils ne sont pas en première page.
Le client SaaS dont j'ai parlé au début ? Nous avons reconstruit toute son architecture internationale au Q1 2022. Au Q4 2022, son trafic allemand était passé de 38 sessions par mois à environ 1 400. La France était à 800. Cela a pris neuf mois de travail constant. Pas de raccourcis. Juste une architecture correcte, du contenu vraiment localisé, et une création de liens patiente dans chaque marché.
---
FAQ
Ai-je besoin d'une propriété Google Search Console séparée pour chaque langue ?
Non si vous utilisez des sous-répertoires. Une propriété GSC couvre l'ensemble du domaine, et vous pouvez filtrer par préfixe d'URL pour voir les données par locale. Si vous utilisez des ccTLD, alors oui, chaque domaine a besoin de sa propre propriété. Les sous-domaines peuvent être configurés séparément ou couverts sous une propriété de domaine. Je préfère séparé pour des données plus nettes.
Puis-je utiliser la traduction automatique pour le contenu localisé ?
Réponse courte : non, pas comme résultat final. Google peut détecter le contenu traduit automatiquement et c'est couvert par ses Politiques anti-spam en tant que contenu généré automatiquement. Utilisez DeepL ou similaire pour obtenir un brouillon, puis faites-le corriger correctement par un locuteur natif. C'est à l'étape de la révision que la localisation se fait vraiment.
Comment gérer une langue parlée dans plusieurs pays ? Comme l'espagnol pour l'Espagne vs le Mexique ?
Vous utilisez des codes hreflang séparés : es-ES pour l'Espagne et es-MX pour le Mexique. Et idéalement vous avez du contenu réellement différent pour chacun, ou au minimum des métadonnées différentes ciblant les requêtes locales. Ne pointez pas simplement les deux codes hreflang vers la même page. Google comprendra ce que vous faites.
Et si mon CMS ne supporte pas hreflang nativement ?
La plupart le font via des extensions. WPML et Polylang gèrent tous deux hreflang correctement sur WordPress. Pour les développements sur mesure, vous pouvez générer les balises via votre sitemap XML plutôt que dans le <head>, ce que Google accepte. La méthode du sitemap est en réalité plus facile à maintenir à grande échelle. Assurez-vous simplement qu'elle valide correctement.
---
L'optimisation SEO locale est lente, délicate, et souvent sous-dotée en ressources. Sur la plupart des sites que j'ai audités, le contenu traduit existe mais la couche technique est soit absente soit cassée. Corriger d'abord l'architecture. Puis construire les signaux locaux. Le contenu, c'est la partie facile, honnêtement. C'est les trucs barbants qui font la différence.