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.in the target language, in the target locale using Google Keyword Planner with the country set correctly, or Ahrefs with the country filter applied. These are not the same as running English research. Treat each market as a new site from a keyword perspective.
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.subdirectories are usually the right call for most businesses. Something like yoursite.com/de/ rather than de.yoursite.com or yoursite.de. The reasons are practical: all your domain authority consolidates, it's easier to manage in one place, and Google handles it well when hreflang is set up correctly.
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.yoursite.de , yoursite.fr) do send a strong local signal. If you're a serious player in a specific market and you can commit to running essentially separate sites, they're worth it. Seahawk had a fintech client that insisted on separate ccTLDs for six countries in 2020, and yes, it performed well in those markets. But their dev overhead tripled. For most agencies building for clients, that's not realistic.
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.de.yoursite.com) are the worst of both worlds in most cases. Harder to maintain than subdirectories, weaker authority signal than ccTLDs. I'd avoid them unless your CMS architecture genuinely forces the issue.
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.be consistent. Don't mix structures. I've inherited sites with /fr/ pages and a fr. subdomain running simultaneously, both indexed. It's a nightmare.
---
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. tells Google which version of a page to show to which user in which language and country. Get it wrong and you'll have your US English pages showing up in Germany, your German pages not ranking at all, or, my personal favourite disaster, your x-default pointing to a page that redirects somewhere else entirely.
Le format de la balise ressemble à ceci dans votre <head> :<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/" /> `` <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. If your German page doesn't link back to the English page, and the English page doesn't link back to German, the implementation is broken.
- 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.
hreflang="en"means "English, any region."hreflang="en-GB"means "English, United Kingdom specifically." If you're trying to target UK vs US separately, you need the region code. - 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. The German page must contain a tag pointing to the English page. The English page must contain a tag pointing back to German. Both. Always.
- 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. Your hreflang alternate URL and your canonical URL for that page must match. Exactly. Including trailing slashes.
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.Aleyda Solis's hreflang tag generator when I'm setting these up manually. And I always audit with Screaming Frog after. Always.
---
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. A link from a German .de domain to your
/de/pages carries meaningful weight. Links from French media to your French pages, same thing. Getting a link from a US blog to your German content doesn't help nearly as much as people assume. - 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. If there's any physical presence, even a registered address, set up a GBP for that location. Fill it out properly. This is table stakes for local pack visibility.
- Schema local. Ajoutez un schema LocalBusiness avec 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. Add
LocalBusinessschema with the correct country, address format, and phone number format. Don't just copy your English schema and translate the description. The structured data needs to match the locale specifics. - 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. Less important than it used to be given CDNs, but if you're using a CDN (and you should be), confirm your edge nodes are serving European users from European servers. Cloudflare's free plan handles this. It's not a huge ranking factor but it contributes to TTFB in that region, which matters.
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.look at what's actually ranking in that country, in that language, for your target query. Open an incognito window, set your Google country manually, and look at the top three results. What length are they? Do they have video? Do they have tables? Do they have user reviews embedded? That's your benchmark, not what works in English.
---
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)Google Search Console (International Targeting report, under Legacy Tools)
- 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.this takes longer than English SEO. A lot longer, sometimes.
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.Spam Policies as auto-generated content. Use DeepL or similar to get a first draft, then have a native speaker edit it properly. The editing pass is where localisation actually happens anyway.
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.es-ES for Spain and es-MX for Mexico. And ideally you have genuinely different content for each, or at minimum different metadata targeting local queries. Don't just point both hreflang codes to the same page. Google will figure out what you're doing.
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.<head>, which Google accepts. The sitemap method is actually easier to maintain at scale. Just make sure it's validating cleanly.
---
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.