Un client s'est adressé à moi en 2021 avec un site e-commerce WordPress ciblant sept pays. Il avait engagé une agence de traduction, tout inséré dans WPML, et c'était réglé. Le trafic organique sur cinq de ces sept marchés était essentiellement nul. Pas faible. Nul. Les pages allemandes cannibalisaient les pages anglaises. Les pages arabes n'avaient aucun attribut dir="rtl" nulle part. Et les balises hreflang ? Pointant vers des URLs qui faisaient des redirections 301 vers des pages complètement différentes.dir="rtl" attribute anywhere. And the hreflang tags? Pointing at URLs that 301-redirected to completely different pages.
C'était un travail de récupération de trois mois. J'ai facturé équitablement, mais j'y pense depuis, parce que chaque problème sur ce site aurait pu être évité avec une décente liste de contrôle exécutée avant le lancement.
Voici la mienne. L'ordre exact dans lequel je la traite, les outils que j'ouvre réellement, et les choses qui coincent encore les développeurs expérimentés.
---
Commencez par la Structure d'URL (Avant de Toucher à Quoi que ce Soit d'Autre)
Cette décision est permanente. Ou suffisamment permanente pour que vous la traitiez comme telle. J'ai vu des agences modifier les structures d'URL sur des sites multilingues en direct et regarder six mois de capital de liens s'évaporer.
Vous avez trois options : les sous-répertoires (/fr/), les sous-domaines (fr.), ou les ccTLD (site.fr). La documentation de Google sur le ciblage international est assez claire : les trois fonctionnent, mais les compromis sont réels./fr/), subdomains ( fr.), or ccTLDs ( site.fr). Google's own documentation on international targeting is pretty clear that all three work, but the trade-offs are real.
Pour la plupart de mes clients, j'utilise les sous-répertoires. Un domaine, un pool d'autorité, un budget de crawl à gérer. Les sous-domaines ont du sens quand vous avez vraiment des équipes séparées qui gèrent des opérations séparées (Seahawk a eu une fois un client SaaS où les produits US et EU étaient réellement des produits réglementaires différents, les sous-domaines étaient le bon choix). Les ccTLD sont pour les entreprises avec une présence de marque locale sérieuse et le budget pour construire l'autorité de domaine séparément pour chacun.
Choisissez-en un. Documentez-le. Obtenez l'approbation avant que quiconque n'écrive une seule ligne de code de modèle.
L'Erreur du Sous-Dossier Unique que Je Vois Régulièrement
Les gens imbriquent la langue par défaut sous /en/ sans mettre en place une redirection appropriée depuis la racine. Donc site.com/ retourne un 200 sans hreflang, site.com/en/ contient tout le contenu, et Google indexe les deux comme des pages séparées et minces. Configurez votre racine pour rediriger vers la locale appropriée basée sur Accept-Language, ou faites simplement servir la racine directement par la locale par défaut. Ne la laissez pas en suspens./en/ without setting up a proper redirect from the root. So site.com/ returns a 200 with no hreflang, site.com/en/ has all the content, and Google indexes both as separate thin pages. Set your root to redirect to the appropriate locale based on Accept-Language, or just make the root serve the default locale directly. Don't leave it dangling.
---
Hreflang : Faites-le Correctement ou Ne Vous en Embêtez Pas
Hreflang est la partie qui rend la plupart des développeurs nerveux. À juste titre. C'est pointilleux.
La spécification hreflang de Google vous dit d'utiliser des codes langue-région (en-GB, fr-FR), de rendre les balises auto-référencées (chaque page se référence elle-même), et de rendre la relation bidirectionnelle (si /fr/ pointe vers /en/, alors /en/ doit pointer en retour vers /fr/). Manquez l'une de ces trois et tout s'effondre silencieusement. Google ne lancera pas d'action manuelle. Il ignore simplement vos balises et devine.hreflang spec from Google tells you to use language-region codes (en-GB , fr-FR ), make the tags self-referential (every page references itself), and make the relationship bidirectional (if /fr/ points to /en/, then /en/ must point back to /fr/). Miss any of those and the whole thing breaks silently. Google won't throw a manual action. It just ignores your tags and guesses.
Voici mon flux de travail réel :
- Construire d'abord la matrice d'URL complète dans un tableur. Chaque locale, chaque URL de page équivalente.
- Implémenter via le <head> plutôt que via les sitemaps si possible. Les sitemaps fonctionnent, mais l'implémentation <head> est plus facile à auditer en consultant simplement la source.
<head>rather than sitemaps wherever possible. Sitemaps work, but<head>implementation is easier to audit by just viewing source. - Exécuter Screaming Frog sur le site de staging avec l'audit hreflang activé. Exporter le rapport des problèmes.Screaming Frog over the staging site with hreflang auditing enabled. Export the issues report.
- Recouper avec l'audit de site d'Ahrefs pour détecter les pages de locale orphelines (pages dans une langue sans hreflang pointant vers les équivalents dans d'autres langues).
- Vérifier manuellement 10-15 pages. Consulter simplement la source. Chercher le motif.
Une chose que les gens font mal constamment : x-default. Ce n'est pas « la version anglaise ». C'est le fallback pour les utilisateurs dont la langue ne correspond à aucune de vos balises de locale. Si vous ciblez spécifiquement en-GB et en-US, un anglophone canadien a besoin d'un endroit où atterrir. C'est x-default. Pointez-le vers votre page de secours la plus pertinente, généralement la racine ou une page de sélecteur de langue.x-default . It's not "the English version". It's the fallback for users whose language doesn't match any of your locale tags. If you're targeting en-GB and en-US specifically, a Canadian English speaker needs somewhere to land. That's x-default. Point it at your most relevant catch-all page, usually the root or a language-selector page.
---
Budget de crawl et indexation
Sur les petits sites, cela n'a pas beaucoup d'importance. Sur un site avec 50 000 pages sur 8 langues, c'est absolument essentiel.
Les mathématiques sont simples : si votre site anglophone compte 6 000 pages et que vous ajoutez 7 langues, vous vous retrouvez potentiellement avec 48 000 pages qui toutes ont besoin d'être explorées et indexées. La plupart des sites n'ont ni l'autorité ni la structure de liens internes nécessaires pour supporter cela efficacement.
Ce que je fais :
- Auditer quelles pages méritent réellement une traduction. Pas tout. Les articles de blog de 2017 qui reçoivent 3 visites par mois en anglais n'ont pas besoin d'une version française.
- Utiliser des sitemaps distincts par locale (sitemap-fr.xml , sitemap-de.xml ) et tous les référencer depuis sitemap-index.xml. Google Search Console vous permet de soumettre et surveiller chacun séparément, ce qui est bien plus facile à déboguer.
sitemap-fr.xml,sitemap-de.xml) and reference them all fromsitemap-index.xml. Google Search Console lets you submit and monitor each separately, which is far easier to debug. - Vérifier les statistiques d'exploration dans Search Console par propriété si vous êtes sur des sous-domaines ou des ccTLD. Pour des sous-répertoires sur un seul domaine, utilisez le rapport de couverture filtré par chemin d'URL.
- Mettre en noindex les pages fines ou traduites par machine que vous n'avez pas révisées. Sérieusement. Une page que Google indexe comme contenu de mauvaise qualité endommage tout le domaine.
En 2019, un client du secteur du voyage avait mis en ligne 12 versions linguistiques, toutes traduites par machine via DeepL sans révision humaine. Du trafic solide en anglais, complètement détruit en 8 semaines dans toutes les autres langues. DeepL est un excellent outil (je l'utilise toujours comme première version) mais un résultat non révisé à grande échelle est un cauchemar pour le signal de confiance.
---
Traduction vs Transcréation
Cette distinction importe bien plus que la plupart des SEO techniques ne l'admettent.
La traduction convertit des mots. La transcréation convertit l'intention, le ton et le contexte culturel. Pour les landing pages, les descriptions de produits, et tout ce pour quoi vous dépensez de l'argent pour vous classer, vous voulez de la transcréation.
L'élément pratique de la checklist ici : pour chaque marché cible, faites relire par un locuteur natif au moins les 20 pages ayant le plus grand potentiel de trafic. Pas juste pour la grammaire. Pour vérifier que le texte sonne comme une vraie personne dans cette langue, ou comme une machine qui a appris la langue dans des manuels d'instructions.
La recherche de mots-clés est séparée par locale. J'utilise Ahrefs pour cela. Le mot-clé allemand pour un concept n'est pas juste le mot allemand pour le mot-clé anglais. Le comportement de recherche diffère. Sur certains marchés, les utilisateurs cherchent plus formellement. Sur d'autres, ils utilisent des abréviations ou de l'argot qui n'apparaîtrait jamais dans une traduction directe. Construisez des cartes de mots-clés spécifiques à chaque locale. Cela prend plus de temps. Ça en vaut la peine.
Que Faire Avec les Marchés Que Vous Ne Pouvez Pas Vous Permettre de Transcréer Correctement
Soyez honnête avec vous-même. Si vous ne pouvez pas faire l'allemand correctement maintenant, ne lancez pas l'allemand. Une présence multilingue médiocre est pire qu'aucune présence multilingue. Googlebot ne vous donne pas de crédit pour avoir essayé.
---
Vérifications Techniques On-Page Par Locale
C'est la partie peu glamour. Mais c'est là que se trouvent les gains.
- L'attribut `lang` sur l'élément `<html>`. Doit correspondre à la locale de la page. <html lang="fr-FR">. Vérifiez chaque template, pas seulement la homepage. Should match the locale of the page.
<html lang="fr-FR">. Check every template, not just the homepage. - L'attribut `dir` pour les langues RTL. Arabe, hébreu, ourdou, persan : <html dir="rtl">. Et vérifiez que votre CSS le supporte réellement, pas juste l'attribut HTML. Arabic, Hebrew, Urdu, Persian:
<html dir="rtl">. And check that your CSS actually supports it, not just the HTML attribute. - Les balises canoniques. Chaque page localisée doit s'auto-canonicaliser. La page française se canonicalise vers elle-même, non vers l'équivalent anglais. J'ai vu cette erreur plus de fois que je ne peux le compter. Each localised page should self-canonicalise. The French page canonicalises to itself, not to the English equivalent. I've seen this wrong more times than I can count.
- Les titres et descriptions méta. Traduits et adaptés par locale. Pas laissés en anglais. Pas générés automatiquement à partir d'un modèle avec [Page Name] | [Site Name] et un slogan traduit par machine. Translated and adapted per locale. Not left in English. Not auto-generated from a template with
[Page Name] | [Site Name]and a machine-translated tagline. - Les données structurées. Si vous utilisez le balisage Schema.org, la propriété inLanguage doit refléter la langue de la page. Pour l'e-commerce, vérifiez que priceCurrency correspond à la devise attendue par la locale. If you're using Schema.org markup, the
inLanguageproperty should reflect the page's language. For e-commerce, check thatpriceCurrencymatches the locale's expected currency. - Le texte alt des images. Traduit. Souvent oublié parce qu'il n'est pas visible. Toujours vérifié. Translated. Often overlooked because it's not visible. Always checked.
J'utilise un simple Google Sheet avec tous ces éléments comme en-têtes de colonnes. Une ligne par locale. Cochez quand vérifié. Partagez-le avec le client pour qu'il comprenne ce qui a été vérifié.
---
Recherche locale et Google Business Profile
Pour les clients avec des locaux physiques sur plusieurs marchés, le SEO multilingue ne s'arrête pas au site web.
Google Business Profile supporte plusieurs langues pour la description de l'entreprise et les listes de services. Définissez la langue principale par localisation correctement. Si vous avez un bureau à Paris, le GBP de cette localisation doit être en français, avec une description en français, non copié littéralement du profil HQ anglais.
La cohérence NAP (name, address, phone) sur les annuaires d'citations locales compte par marché également. En Allemagne, cela signifie s'assurer que l'annonce est correcte sur Das Örtliche et Gelbe Seiten, pas seulement Google. En France, PagesJaunes. Chaque marché a son propre écosystème de citations. Passer un après-midi à cartographier les 10 meilleures sources de citations par pays cible est un temps bien investi.
---
Suivi post-lancement
Le lancement n'est pas la fin. C'est le début pour découvrir ce que vous avez manqué.
Mon système de suivi post-lancement pour les sites multilingues :
- Configurez Google Search Console séparément par locale (sous-domaine ou ccTLD) ou utilisez la propriété de préfixe d'URL par chemin de répertoire.
- Vérifiez le rapport Ciblage international dans Search Console sous « Outils hérités ». Il signalera les erreurs hreflang dans les semaines suivant le lancement.
- Configurez le suivi du classement dans Ahrefs par locale, en utilisant le ciblage pays/langue correct. Un mot-clé suivi en « Anglais, États-Unis » vous donnera des positions différentes du même mot-clé suivi en « Allemand, Allemagne ».
- Surveillez la couverture de crawl mensuellement pendant les 6 premiers mois. Les pages de nouvelles locales restent parfois bloquées dans « Découvert, non indexé » pendant des semaines. Généralement un problème de budget de crawl ou de liens internes.
- Vérifiez la cannibalisation trimestriellement. Deux pages de locale en concurrence pour la même requête dans le même pays indiquent que quelque chose s'est mal passé dans la configuration de l'URL ou hreflang.
Un point que j'ai ajouté à ma checklist après une expérience pénible avec un client fintech : vérifier que les redirections basées sur l'IP n'annulent pas hreflang. Si votre CDN ou serveur redirige les utilisateurs en fonction de la géolocalisation par IP, Googlebot (qui crawle généralement à partir d'adresses IP américaines) ne verra peut-être jamais vos pages non-anglaises. Ce client fintech avait des règles CloudFront qui redirigaient agressivement les adresses IP non-américaines. Il nous a fallu deux semaines pour diagnostiquer pourquoi les pages européennes avaient zéro indexation.check that IP-based redirects aren't overriding hreflang. If your CDN or server is redirecting users based on IP geolocation, Googlebot (which usually crawls from US IPs) might never see your non-English pages. That fintech client had CloudFront rules aggressively redirecting non-US IPs. Took us two weeks to diagnose why the European pages had zero indexation.
---
FAQ
Ai-je besoin d'une propriété Google Search Console distincte pour chaque langue ?
Pas nécessairement. Si vous utilisez des sous-répertoires sur un seul domaine (comme site.com/fr/), vous pouvez utiliser une propriété de préfixe d'URL par sous-répertoire, ou simplement utiliser la propriété du domaine racine et filtrer par chemin d'URL. Si vous êtes sur des sous-domaines ou des ccTLD distincts, les propriétés séparées valent la surcharge administrative car vous obtenez des données plus claires par marché.site.com/fr/), you can use a URL-prefix property per subdirectory, or just use the root domain property and filter by URL path. If you're on subdomains or separate ccTLDs, separate properties are worth the admin overhead because you get cleaner data per market.
La traduction automatique est-elle suffisante pour le SEO en 2024 ?
Pour une première version, oui. Pour publier sans examen humain, non. DeepL et Google Translate se sont considérablement améliorés, mais ils produisent un contenu grammaticalement correct et tonalement plat. Les moteurs de recherche deviennent de plus en plus compétents pour distinguer un contenu qui se lit naturellement dans une langue d'un contenu traduit. Utilisez la traduction automatique pour aller vite, puis demandez à un locuteur natif de relire les pages à haut potentiel avant l'indexation.
Comment gérer un marché où je n'ai qu'une couverture de traduction partielle ?
Mettez un noindex sur les pages non traduites ou partiellement traduites jusqu'à ce qu'elles soient prêtes. Ne publiez pas de pages de locale inachevées juste pour les avoir en ligne. Les dégâts causés aux signaux de confiance par un contenu maigre dans une langue sont plus difficiles à inverser que le retard au lancement.
Quelle est l'erreur hreflang la plus courante ?
Oublier la balise auto-référencielle. Chaque page a besoin d'une balise hreflang pointant vers elle-même en plus de pointer vers tous ses équivalents. Les développeurs implémentent souvent les références croisées correctement et oublient l'auto-référence. Screaming Frog la détectera en environ 30 secondes, lancez-le avant chaque déploiement.
Devrais-je traduire les URL ou les garder en anglais ?
Traduisez-les. /fr/chaussures/ surpasse /fr/shoes/ dans la recherche française parce que le slug contribue aux signaux de pertinence. C'est aussi plus fiable aux yeux des utilisateurs francophones. L'effort d'implémentation supplémentaire (vous avez besoin du routage spécifique à la locale et de la traduction du slug dans votre CMS) en vaut la peine pour tout marché que vous ciblez sérieusement./fr/chaussures/ outperforms /fr/shoes/ in French search because the slug contributes to relevance signals. It also looks more trustworthy to French-speaking users. The extra implementation effort (you need locale-specific routing and slug translation in your CMS) is worth it for any market you're seriously targeting.
---
Le SEO multilingue n'est pas une case à cocher une fois. C'est une discipline. La checklist ci-dessus m'a épargné de combattre des incendies coûteux après le lancement plus de fois que je ne voudrais l'admettre, et elle évolue toujours. Chaque nouveau projet m'apprend quelque chose. Récemment : vérifiez toujours ce que le CDN fait avec les requêtes de locale non par défaut avant de déclarer un site prêt. Toujours.