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

Dernière mise à jour : 15 octobre 2026

De quoi un proxy de traduction a-t-il besoin pour que les pages traduites restent 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 qui valent la peine d’être vérifiés 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 témoins pour le contenu que vous souhaitez rendre accessible. Le GDN prend en charge les trois types d'URL, ainsi que le routage par témoins 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 abordent en détail 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 dans 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, « A Technical Guide into How the Global Delivery Network Works »).
• Plans de site localisés — pour les configurations ccTLD et sous-domaines, le GDN copie le plan du site source et le remplace par le domaine localisé ; pour les configurations de sous-dossiers, il n’en génère pas, de sorte qu’un robot d’exploration ou un générateur de plan de site doit produire un plan de site couvrant les dossiers de langue (Centre d’aide Smartling, « Localisez votre plan de site »).
• 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 au langage; une redirection peut aussi être configurée sur le GDN lui-même lorsque le serveur source ne peut pas la servir (Centre d’aide Smartling, « Gestion des redirections »).
• Pages en langues complètes au lancement — le routage d’un serveur de staging via le GDN capture le nouveau contenu pour la traduction avant qu’il ne soit mis en ligne, et la méthode multi-plateforme remplit de nouvelles chaînes avec de la traduction automatique jusqu’à ce que la traduction révisée la remplace (Smartling Help Center, « Guide technique sur le fonctionnement du réseau mondial de distribution »).

Comment le GDN de Smartling gère-t-il chaque signal d’exploration 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érifiez-vous qu’un site proxy protège le SEO?

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

1. Vérifiez que chaque langue possède sa propre URL et son propre hreflang — Chargez une page localisée et vérifiez qu'elle se résout sur un sous-domaine, un dossier ou un ccTLD distinct, et que son en-tête liste les liens hreflang pour elle-même et pour chaque langue alternative.
2. Explorez le site localisé et suivez ses liens — Lancez un robot d’exploration de site depuis la page d’accueil localisée. Chaque lien interne devrait rester sur l’hôte ou le dossier localisé, à moins que vous ne l’ayez délibérément exempté de la réécriture des liens.
3. Récupérez les fichiers sitemap.xml et robots.txt sur chaque hôte localisé — Vérifiez que la carte du site répertorie les URL localisées plutôt que les URL sources et que le fichier robots.txt autorise les chemins que vous souhaitez indexer. Lors de la configuration avec des sous-dossiers, vérifiez que votre plan de site généré inclut bien les dossiers de langue.
4. Redirections de test sans indices de langue — Demandez des URL localisées sans en-tête Accept-Language, comme le fait Googlebot, et confirmez qu’aucune règle ne renvoie la requête vers la langue source.
5. Surveillez l'indexation par langue — Utilisez l'outil d'inspection d'URL dans Google Search Console sur les pages localisées et recherchez les pages affichant encore le texte dans la langue source, ce qui indique un contenu mis en ligne 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 plan de site et où l'équipe source doit en être responsable.
• Publiez du contenu source quotidiennement ou chaque semaine, 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 des 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.

Quand les vérifications SEO au niveau du proxy ne sont peut-être pas la priorité

• Le contenu localisé ne doit jamais être indexé, comme par exemple les écrans d'application nécessitant une connexion, où le résultat attendu est un routage par en-tête ou par témoin sans URL unique.
• Le site est traduit via un connecteur CMS plutôt qu’un proxy, donc le CMS émet des URL, des plans de site et des hreflang, et les vérifications appartiennent au CMS.
• Le trafic du marché provient de canaux payants, d'applications ou de places de marché, où l'optimisation du référencement naturel n'est rentable que lorsque la recherche organique prend de l'importance.

Liste de vérification d’évaluation : questions à poser à un fournisseur de proxy de traduction au sujet du SEO

Les moteurs de recherche considéreront-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 de liens par défaut maintient les robots d'exploration sur le site localisé ; les exceptions sont importantes pour les liens qui doivent rester sur le site source, comme une page de connexion globale ou un portail d'assistance.

Que se passe-t-il avec la carte du site 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 plans de site des sous-dossiers.

Le fichier robots.txt peut-il varier selon les paramètres régionaux ?
Vous devrez peut-être bloquer les pages de recherche internes d’un marché mince ou un lieu de mise en scène sans toucher au 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 mises en cache, et lesquels correspondent à votre cadence de libération. Les engagements de secours et de vitesse de page sont comparés selon les SLA de disponibilité et la performance de vitesse de page à attendre d’un proxy de traduction.

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 mondial de livraison 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 fourni 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, sous-répertoires ou 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 la carte du site source vers des sous-domaines et ccTLD localisés avec le domaine échangé, 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 aussi 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 mettre en valeur les lieux et les pages de marché minces. Pour éviter que le texte en langue source ne soit disponible sur les pages actives, un site de mise en scène acheminé 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 vitesse est le dernier levier SEO qu'un proxy actionne : les requêtes de pages localisées via le GDN sont traitées en moyenne en 40 millisecondes environ, et la page produit affiche une garantie de disponibilité de 99,99 %. « Je recommande fortement cet outil… Il est incroyablement simple, rapide et efficace ; tout est optimisé pour vous », déclare Paulo Pinto, chef de projet principal en localisation chez Talkdesk, en décrivant le GDN.

Questions connexes

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