Traduction automatique et SEO : ce que Google accepte

Non, Google ne pénalise pas un texte parce qu'il a été produit avec DeepL, Google Traduction ou un modèle de langage. Il n'existe pas de « pénalité DeepL ». Ce qui pose problème, c'est de publier en masse des traductions brutes, sans relecture, qui n'apportent rien à un lecteur de la langue cible. Le critère est la valeur de la page, pas l'outil qui a écrit la première version.

La nuance est importante, car elle change la décision. Traduire automatiquement cent pages puis les mettre en ligne telles quelles est un risque réel. Traduire automatiquement, faire relire par une personne qui parle la langue, adapter les exemples et le vocabulaire de recherche, puis publier une page utile est une pratique courante et défendable. Cet article se concentre sur la qualité du texte traduit : ce que Google écrit dans ses règles, comment il évalue un contenu par langue, et comment organiser une relecture qui tient la route. La structure technique (URL, hreflang, sélecteur de langue) relève d'un autre sujet et n'est abordée ici que lorsqu'elle touche à la qualité.

Ce que dit vraiment la politique anti-spam de Google

Les consignes de Google pour les webmasters ont longtemps cité explicitement, parmi les contenus générés automatiquement, le « texte traduit par un outil automatique sans relecture ni curation humaine avant publication ». La formulation visait les pages produites sans aucun contrôle, dans le seul but d'occuper des requêtes. Depuis, les règles anti-spam ont été reformulées autour de la notion d'abus de contenu à grande échelle : produire de nombreuses pages dont l'objectif principal est de se positionner plutôt que d'aider les utilisateurs, quelle que soit la méthode employée (automatisation, humains, mélange des deux).

Deux choses ressortent de cette évolution. D'abord, la méthode de production n'est pas le critère : Google l'a dit clairement à propos du contenu généré par IA, et le raisonnement s'applique tel quel à la traduction. Ensuite, le mot qui compte est « échelle » associé à « faible valeur ». Une traduction automatique de quelques pages stratégiques, relue et corrigée, ne ressemble en rien à la duplication de dix mille fiches produits dans six langues sans aucun contrôle.

Il faut aussi rester honnête sur ce qu'on ne sait pas. Google ne publie pas de seuil (nombre de pages, taux d'erreurs toléré) au-delà duquel une traduction devient du spam. Quiconque vous donne un pourcentage précis invente. Ce que vous pouvez faire, c'est vous placer du bon côté de la règle : chaque page traduite doit pouvoir être défendue comme utile à un lecteur réel.

Pourquoi une traduction brute pose problème, même quand elle est correcte

Les outils actuels produisent souvent des phrases grammaticalement propres. Le problème n'est donc pas seulement les fautes visibles. Il tient à ce qu'une traduction fidèle transporte le contenu source tel quel : mêmes exemples, mêmes références culturelles, mêmes unités, mêmes prix, mêmes lois. Un article qui cite la réglementation américaine, des dollars et des magasins qui n'existent pas dans le pays visé reste correct mot à mot et inutile pour le lecteur.

Il y a ensuite le défaut le plus coûteux en SEO : l'intention de recherche. Les gens ne cherchent pas dans une langue comme ils traduiraient une phrase. Un terme technique anglais peut être courant tel quel en français, ou au contraire remplacé par une expression que personne n'aurait devinée en traduisant littéralement. Une page qui vise la traduction mot à mot d'une requête que personne ne tape n'a aucune chance de capter du trafic, même sans aucune pénalité.

• Exemples, prix, devises et références légales restés ceux du marché d'origine.
• Expression littérale d'une requête qui n'est pas celle que les internautes utilisent réellement.
• Ton trop formel ou trop familier par rapport aux usages du secteur dans cette langue.
• Jeux de mots, titres accrocheurs et appels à l'action traduits sans être réécrits, donc plats ou incompréhensibles.
• Termes de marque, noms de fonctionnalités ou de produits traduits alors qu'ils doivent rester intacts.

Les signaux de qualité évalués langue par langue

Google n'évalue pas un site comme une masse unique. Chaque URL est indexée et classée pour les requêtes d'un pays et d'une langue, et les utilisateurs de cette langue génèrent leurs propres signaux : clics, retours vers les résultats, temps passé, liens obtenus. Une version espagnole médiocre ne peut pas s'appuyer sur la réputation de la version anglaise pour bien se classer auprès d'un lecteur espagnol. Elle doit convaincre sur place.

Cela dit, la qualité se mesure aussi à l'échelle du site. Google a indiqué que des contenus de faible utilité en grand nombre peuvent affecter la perception d'un site dans son ensemble, notamment via les signaux issus de l'ancien système de contenu utile, intégré au classement principal en 2024. Un dossier entier de traductions bâclées peut donc peser sur des pages irréprochables du même domaine. Ce n'est pas une règle mécanique dont on connaîtrait le seuil, mais un risque qu'on gère en ne publiant pas ce qu'on ne voudrait pas voir jugé.

Les critères d'évaluation de la qualité (E-E-A-T) s'appliquent aussi. Pour une page qui donne un conseil médical, juridique ou financier, une traduction automatique non vérifiée est particulièrement risquée : l'erreur d'un terme technique n'est pas une coquille, c'est une information fausse. Sur ces sujets, la relecture par un spécialiste de la langue et du domaine n'est pas un luxe.

• Fautes, tournures étranges et terminologie incohérente d'une page à l'autre.
• Contenu qui ne répond pas à la question telle qu'elle est posée dans la langue cible.
• Absence de signaux locaux : pas d'exemples du pays, pas de coordonnées ni de mentions adaptées.
• Pages quasi identiques dans plusieurs variantes régionales sans réelle différence utile.

Les cas où la traduction automatique passe sans difficulté

Il serait faux de conclure que tout usage est dangereux. Un site d'aide documentaire, un manuel technique ou une fiche de spécifications changent peu d'un pays à l'autre ; la traduction automatique suivie d'une relecture ciblée y est souvent plus fiable qu'une rédaction improvisée. Les contenus factuels, courts et normalisés se prêtent bien à l'exercice parce que le risque de contresens ou de décalage culturel est faible.

Un second cas favorable est celui du brouillon. Beaucoup d'équipes utilisent DeepL ou un modèle de langage comme première passe, puis un rédacteur natif réécrit, raccourcit et adapte. Dans ce schéma, la machine fait gagner du temps, l'humain porte la qualité. Google ne voit pas le brouillon, il voit la page finale, et c'est elle qui est jugée.

Les contenus de pure opinion, d'expertise ou de marque demandent en revanche presque toujours une réécriture. Un article de blog qui défend un point de vue, un témoignage ou une page de présentation de l'entreprise ne peut pas être une simple conversion : le ton et la crédibilité se perdent dans l'opération.

Comment relire une traduction automatique avant de la publier

Une bonne relecture ne consiste pas à corriger les fautes d'orthographe. Elle vérifie que la page fonctionne comme si elle avait été écrite dans cette langue. Le plus efficace est de la confier à une personne dont c'est la langue maternelle, qui connaît le secteur, et de lui donner une liste de contrôle plutôt qu'un simple « vérifie que c'est bien ».

Commencez par la requête. Avant de relire le texte, recherchez vous-même le sujet dans la langue cible et regardez les pages déjà positionnées : quels mots utilisent-elles dans le titre, quelles questions traitent-elles, quel format domine ? Ajustez ensuite le titre, le H1 et les sous-titres en conséquence. C'est cette étape, plus que la correction grammaticale, qui détermine si la page peut être trouvée.

• Vérifier le vocabulaire de recherche : la requête ciblée est-elle réellement employée dans ce pays ?
• Adapter les exemples, devises, unités, dates, lois et noms d'institutions.
• Harmoniser la terminologie avec un glossaire partagé, pour que « tableau de bord » ne devienne pas trois traductions différentes.
• Protéger les noms de marque, de produits et les termes qu'on ne doit pas traduire.
• Réécrire le titre, la méta description et les appels à l'action plutôt que les convertir.
• Relire à voix haute : une phrase qui sonne étrangère à l'oreille le sera aussi pour le lecteur.
• Contrôler les liens internes, les ancres et les images contenant du texte, souvent oubliés.

Un exemple concret : une boutique en trois langues

Prenons une boutique en ligne de matériel de randonnée, avec un catalogue rédigé en anglais et quatre cents fiches produits. Première option : traduire les quatre cents fiches automatiquement en français et en allemand, puis les publier d'un coup. Le risque est double. Les descriptions sont quasi identiques d'une fiche à l'autre, ce qui donne des pages pauvres en information propre, et les termes du catalogue (taille, matière, usage) ne correspondent pas à ceux que les acheteurs emploient dans chaque pays.

Deuxième option : traduire d'abord les vingt fiches qui génèrent déjà le plus de ventes, les faire relire par un locuteur natif qui connaît la randonnée, ajouter ce qui manque pour le marché (guide des tailles local, délais de livraison, conditions de retour), puis mesurer l'indexation et les clics dans Search Console avant d'étendre. Le volume progresse plus lentement, mais chaque page publiée mérite de l'être, et l'équipe apprend quels défauts reviennent dans les traductions avant de les reproduire sur tout le catalogue.

La différence entre les deux approches n'est pas la présence d'un outil de traduction, elle est dans la décision de publier : en bloc et sans contrôle, ou par lots, avec une validation et une mesure.

Mesurer l'effet : indexation, impressions et signaux d'alerte

Après publication, Search Console vous dit ce que Google pense de vos pages traduites. Filtrez par dossier ou sous-domaine de langue et suivez le nombre de pages indexées par rapport aux pages envoyées. Un écart durable, avec beaucoup d'URL en « Détectée, actuellement non indexée » ou « Explorée, actuellement non indexée », est un signal courant que Google juge ces pages peu utiles ou trop proches les unes des autres. Ce n'est pas une preuve, mais c'est la première alerte à examiner.

Regardez ensuite les impressions et les clics par pays et par requête. Si une page est indexée mais n'apparaît sur aucune requête de la langue cible, le problème est probablement d'ordre lexical : vous ne visez pas les bons mots. Si elle apparaît sans être cliquée, le titre traduit est sans doute peu engageant. Ces deux diagnostics se corrigent en réécrivant, pas en ajoutant des pages.

Enfin, gardez en tête que la correction est possible. Une section trop faible peut être améliorée, fusionnée ou retirée de l'index en attendant d'être retravaillée. Mieux vaut avoir cinquante pages solides dans une langue que cinq cents pages dont on ne sait pas dire à quoi elles servent.

Erreurs fréquentes à éviter

Certaines erreurs reviennent presque à chaque projet multilingue. La plus répandue est de confondre traduction d'interface et traduction de contenu : un menu traduit ne fait pas un site localisé. La seconde est de recourir à un module de traduction qui s'exécute dans le navigateur du visiteur : le texte n'existe alors pas dans le code que Google reçoit et n'est pas indexable dans la langue voulue, même si l'affichage semble parfait.

Une autre erreur est de laisser des traductions automatiques non validées coexister avec des versions relues, sans les distinguer, ce qui empêche ensuite de mesurer l'effet de la relecture. Tenez un suivi simple : statut de chaque page (brute, relue, réécrite), date et relecteur. Il sert autant à la qualité qu'à décider quoi désindexer si un problème apparaît.