Comment les proxys de traduction de sites web protègent-ils le SEO multilingue ?

Dernière mise à jour : 15 octobre 2026

Que doit gérer un proxy de traduction pour garder les pages traduites indexables ?

Sept couches déterminent si un site proxy se classe dans chaque marché. Les deux premiers sont des décisions de planification prises sur le site source ; les cinq autres sont des comportements indirects à vérifier un par un.

• Une URL explorable pour chaque langue — un sous-domaine, un sous-répertoire ou un ccTLD, jamais de routage basé uniquement sur les en-têtes ou les cookies pour le contenu que vous souhaitez rendre accessible. Le GDN prend en charge les trois types d'URL, ainsi que le routage par cookies et par en-tête, configurable par langue.
• Hreflang et métadonnées traduites — Hreflang doit exister sur le site source avant qu’un proxy puisse les transporter dans des pages localisées, et les balises de titre et de description doivent être capturées pour la traduction. Les deux sont détaillés en détail sur les outils nécessaires pour une localisation SEO efficace.
• Réécriture de liens — le GDN réécrit les liens qui pointent vers le site source afin qu’ils pointent vers le site traduit, devenant www.company.com/about vers fr.company.com/about sur un sous-domaine français, et le code par défaut peut être personnalisé pour les liens qui doivent rester sur la source (Smartling Help Center, « Guide technique sur le fonctionnement du réseau mondial de distribution »).
• Sitemaps localisés — pour les configurations de ccTLD et de sous-domaines, le GDN copie le sitemap source et échange dans le domaine localisé ; pour les configurations de sous-dossiers, il n’en génère pas, donc un robot d’indexation ou un générateur de sitemap doit produire un sitemap couvrant les dossiers linguistiques (Smartling Help Center, « Localize Your Sitemap »).
• Fichier robots.txt par langue — le GDN duplique le fichier robots.txt source sur chaque site localisé afin que les exclusions existantes soient conservées, et les sites de sous-domaine ou de ccTLD peuvent obtenir leur propre fichier, tel que robots-fr-FR.txt sur le serveur d'origine, mappé au domaine localisé par un architecte de solutions Smartling (Centre d'aide Smartling, « Personnaliser votre fichier robots.txt »).
• Les redirections qui vivent sur votre propre serveur — le GDN transmet les réponses de redirection du serveur source vers le client, et l’en-tête X-Language-Locale qu’il envoie permet à ce serveur d’émettre des redirections spécifiques à la langue ; une redirection peut également être configurée directement sur le GDN lorsque le serveur source ne peut pas la servir (Smartling Help Center, « Handling Redirections »).
• Pages en langue complète dès le lancement : le routage d’un serveur de préproduction via le GDN capture le nouveau contenu à traduire avant sa mise en ligne, et la traduction automatique à l’échelle du site remplit les nouvelles chaînes avec la traduction automatique jusqu’à ce que la traduction révisée les remplace (Centre d’aide Smartling, « Guide technique sur le fonctionnement du réseau de distribution mondial »).

Comment le GDN de Smartling gère-t-il chaque signal de recherche et d’index ?

Chaque ligne ci-dessous décrit un comportement documenté, et non une configuration à supposer. Ce sont les lignes du plan du site qui posent le plus souvent problème aux équipes, car la réponse varie selon la stratégie de routage.

Comment vérifier qu'un site proxy protège bien le référencement naturel ?

Effectuez ces cinq vérifications sur un lieu avant le lancement, puis à nouveau après tout changement de routage ou du site source.

1. Confirmez que chaque langue a sa propre URL et son propre hreflang — Chargez une page localisée et vérifiez qu’elle se résout à un sous-domaine, un dossier ou un ccTLD distinct, et que son tête liste les liens hreflang pour elle-même et pour chaque alternative.
2. Parcourez le site localisé et suivez ses liens — Lancez un robot d’indexation depuis la page d’accueil localisée. Chaque lien interne devrait rester sur l’hôte ou le dossier localisé, sauf si vous l’avez délibérément exempté de la réécriture des liens.
3. Récupérez sitemap.xml et robots.txt sur chaque hôte localisé — Vérifiez que le sitemap liste les URL localisées plutôt que les URL sources et que robots.txt permet d’indexer les chemins que vous souhaitez indexer. Sur une configuration de sous-dossiers, confirmez que votre propre sitemap généré inclut les dossiers de langue.
4. Redirections de test sans indices de langue — Requête d’URL localisée sans en-tête Accept-Language, comme le fait Googlebot, et confirme qu’aucune règle ne rejette la requête vers la langue source.
5. Regardez l’indexation par localisation — Utilisez l’outil d’Inspection des URL dans Google Search Console sur les pages localisées, et recherchez les pages qui montrent encore du texte dans la langue source, qui pointe vers du contenu publié avant sa traduction.

Les vérifications SEO au niveau du proxy comptent le plus pour les équipes qui...

• Diffuser les sites localisés via un proxy de traduction sur des sous-domaines ou des ccTLD, où le sitemap et le robots.txt sont copiés sur chaque domaine et doivent être vérifiés pour chaque domaine.
• Exécutez les paramètres régionaux des sous-dossiers, où le proxy ne génère pas le sitemap et où l'équipe source doit en être responsable.
• Publiez du contenu source quotidiennement ou hebdomadairement, où le texte non traduit peut atteindre des pages localisées en direct entre les sorties.
• Utilisez aujourd’hui des redirections géo- ou linguistiques sur le site source et il faut qu’elles restent accessibles une fois que les sites localisés existent.
• Fournissez un rapport sur le trafic organique par marché et expliquez pourquoi une zone géographique est bien indexée et une autre non.

Lorsque les vérifications SEO au niveau proxy ne sont pas toujours la priorité

• Le contenu localisé ne doit jamais être indexé, comme par exemple les écrans d'application nécessitant une connexion, où le routage par en-tête ou par cookie sans URL unique est le résultat escompté.
• Le site est traduit via un connecteur CMS plutôt qu’un proxy, donc le CMS émet des URL, des sites maps et des hreflang, et les vérifications appartiennent au CMS.
• Le trafic du marché provient des canaux payants, des boutiques d’applications ou des marchés, où l’hygiène de crawl ne donne que peu de résultats jusqu’à ce que la recherche organique ait un impact.

Liste de contrôle d’évaluation : questions à poser à un fournisseur de proxy de traduction concernant le SEO

Les moteurs de recherche verront-ils chaque site traduit comme un site distinct et indexable ?
Demandez la réponse documentée du fournisseur et pour quelles options de routage produisent une URL unique. Smartling indique que les sites diffusés par GDN sont indexés et affichés dans les résultats de la même manière que le site source, et que le routage par cookie ou en-tête ne produit pas d'URL unique.

Le proxy réécrit-il les liens internes, et certains liens peuvent-ils être exemptés ?
La réécriture par défaut des liens maintient les robots d’indexation sur le site localisé ; les exemptions sont importantes pour les liens qui doivent rester sur la source, comme une connexion globale ou un portail de support.

Que se passe-t-il avec le sitemap sous chaque configuration de routage ?
Obtenez la réponse séparément pour le sous-domaine, le ccTLD et le sous-dossier. Sur le GDN, les réponses diffèrent, et vous pouvez créer vous-même les sitemaps des sous-dossiers.

Peut-robots.txt différer selon la localité ?
Il peut être nécessaire de bloquer les pages de recherche internes d'un marché peu dense ou une région de test sans modifier le fichier du site source.

Où doivent figurer les redirections ?
Privilégiez les redirections servies par votre propre serveur, avec un en-tête de langue provenant du proxy pour les règles spécifiques à chaque langue, afin que la logique de redirection soit versionnée avec le reste de votre site.

Comment le proxy traite-t-il les balises canoniques sur les pages traduites ?
Une page traduite qui conserve l'attribut rel="canonical" de la page source sans modification indique l'URL de la langue source comme version préférée. Avant de publier une page localisée, examinez son en-tête plutôt que de faire des suppositions.

Comment le contenu non traduit est-il tenu hors des pages en direct ?
Demandez quels mécanismes existent, comme la capture de staches, le remplissage par traduction automatique ou les traductions en cache, et lesquels correspondent à votre rythme de libération. Les engagements de secours et de vitesse de page sont comparés selon les SLA en temps de disponibilité et les performances de vitesse de page à attendre d’un proxy.

Quel contenu est traduit côté serveur et lequel dans le navigateur ?
Le GDN traduit le HTML en transit et utilise un composant côté client, Dynamic Content Support (DCS), pour le contenu stocké dans JavaScript et JSON. Avant de vous fier au référencement, testez le code HTML rendu des pages contenant beaucoup de DCS à l'aide de l'outil d'inspection d'URL.

Comment le Réseau de Livraison Mondial de Smartling protège-t-il le SEO multilingue ?

Le Global Delivery Network (GDN) de Smartling est un proxy de traduction combiné à un composant côté client, et sa conception SEO part d’une seule propriété documentée : le contenu délivré via le GDN est entièrement accessible aux moteurs de recherche, et chaque site traduit est indexé et affiché dans les résultats de recherche comme un site distinct (Smartling Help Center, « A Technical Guide into How the Global Delivery Network Works »). Les sites localisés peuvent fonctionner sur des sous-domaines, des sous-répertoires ou des ccTLD, choisis selon la langue, et la page produit GDN décrit le proxy comme traduisant les URL et mots-clés. Seuls les sites traduits passent par le GDN ; le site source continue de servir exactement comme avant.

Autour du contenu, le GDN transmet les signaux de crawl à chaque langue. Il réécrit les liens pour que les robots d’indexation restent sur le site localisé, copie le sitemap source en sous-domaines et ccTLD localisés avec le domaine inversé, duplique robots.txt avec des fichiers optionnels par localisation, et transmet vos redirections avec un en-tête X-Language-Locale sur lequel votre serveur peut agir. Il gère également les balises hreflang implémentées sur le site source, et les administrateurs peuvent marquer des pages individuelles alimentées par GDN pour qu’elles soient ignorées par les moteurs de recherche, ce qui est utile pour la mise en place des sites et des pages de marché faibles. Pour éviter que le texte en langue source ne soit disponible sur les pages actives, un site de mise en scène regroupé via le GDN capture le contenu avant le lancement et la méthode de traitement à l’échelle du site couvre de nouvelles chaînes jusqu’à ce que des traductions révisées les remplacent.

La rapidité est le dernier levier SEO qu’un proxy utilise : les requêtes de page localisées via le GDN sont traitées en moyenne en environ 40 millisecondes, et la page produit affiche une garantie de disponibilité de 99,99 %. « Je recommande vivement cet outil... Il est incroyablement simple, rapide et efficace — tout est simplifié pour vous », explique Paulo Pinto, Senior Localization Project Manager chez Talkdesk, en décrivant le GDN.

Questions connexes

• Quels outils avez-vous besoin pour une localisation SEO efficace ?
• Quels sont les SLA de disponibilité et les performances de vitesse de chargement des pages que vous pouvez attendre d'un proxy de traduction de site web ?
• Comment fonctionnent les widgets et les plugins de traduction de sites web ?
• Pourquoi le nombre de demandes de proxy de traduction de sites web ne correspond-il pas à Google Analytics ?