Le site multilingue qui marchait hier et qui casse aujourd’hui
Imaginons un cas typique (fictif) : un site WordPress en français passe au mode sous-domaines de GTranslate pour vendre en anglais et en hébreu. Sur le papier, dix minutes de configuration dans le plugin. Dans les faits, en.site.com renvoie une erreur de certificat, he.site.com boucle en redirection infinie, et le lendemain la traduction automatique s’arrête complètement sans message d’erreur visible.
Rien de tout ça n’est une fatalité. GTranslate en mode sous-domaines (par opposition au mode “query string” ?lang=en ou au mode sous-dossier /en/) fonctionne comme un proxy : il intercepte les requêtes sur en.site.com, va chercher la page française sur ton serveur, la traduit à la volée, puis la sert. Ce mécanisme demande une chaîne technique complète — DNS, certificat, routage — qui doit être configurée dans le bon ordre. Un seul maillon cassé, et tout s’effondre en cascade.
La bonne nouvelle : c’est un problème de configuration, pas de code. Une fois qu’on sait où regarder, ça se corrige en une session.
Pourquoi ça casse (les causes réelles)
- DNS incomplet : les sous-domaines
fr.,en.,he.n’ont jamais été créés, ou pointent encore vers l’hébergeur au lieu du proxy GTranslate. - Certificat SSL trop étroit : ton certificat couvre
site.cometwww.site.com, mais pas*.site.com. Résultat : cadenas barré ouERR_CERT_COMMON_NAME_INVALIDsur chaque sous-domaine de langue. - Proxy GTranslate mal associé : dans le dashboard GTranslate, chaque langue doit être liée explicitement à son sous-domaine. Un oubli, et le proxy renvoie une 404 ou redirige vers la mauvaise langue.
- Hreflang cassé ou absent : Google voit plusieurs sous-domaines avec un contenu quasi identique. Sans balises
hreflangcorrectes, il risque de les traiter comme du duplicate content et de mal indexer les versions traduites. - Boucle de redirection : ton plugin de sécurité ou ton
.htaccessforce HTTPS/www avant que le proxy GTranslate ait pu router la requête. Le navigateur tourne en rond jusqu’à l’erreurERR_TOO_MANY_REDIRECTS. - Fail2Ban trop agressif (le piège classique) : GTranslate génère un flux de requêtes rapprochées depuis ses propres serveurs pour aller chercher tes pages. Vu de ton serveur, ça ressemble à du scraping ou du brute-force. Une jail Fail2Ban mal calibrée bannit purement et simplement les IP de GTranslate — et la traduction s’arrête net, sans log explicite côté plugin.
1. Vérifier le mode GTranslate actuellement actif
Avant de toucher au DNS, confirme dans les réglages GTranslate quel mode est réellement utilisé : “Query String” (?lang=en), “Sub-directory” (/en/) ou “Sub-domain” (en.site.com). Le passage en sous-domaines est le seul qui exige une infrastructure DNS/SSL dédiée. Si tu n’as pas de besoin SEO fort par pays, le mode sous-dossier évite une bonne partie de ces galères — c’est un arbitrage à faire avant, pas après la casse.
2. Créer les enregistrements DNS pour chaque sous-domaine
Chaque langue active doit avoir un enregistrement CNAME pointant vers l’adresse proxy fournie par GTranslate dans ton tableau de bord (généralement un domaine du type xx.gtranslate.io). Pas de wildcard DNS automatique par défaut : il faut créer une entrée par sous-domaine (fr, en, he…). Si tu gères tes DNS chez Hostinger ou IONOS, suis pas à pas le guide correspondant : configurer ses DNS sur Hostinger ou configurer ses DNS sur IONOS. Si après propagation le sous-domaine ne répond toujours pas, le guide DNS qui ne propage pas couvre les causes classiques (TTL, cache, mauvaise zone).
3. Étendre le certificat SSL en wildcard
Un certificat classique ne couvre que le domaine racine et www. Pour des sous-domaines de langue illimités, il faut un certificat wildcard (*.site.com), généré via une validation DNS (challenge TXT) chez Let’s Encrypt ou directement dans le panel de ton hébergeur. Sans ça, chaque navigateur affiche une alerte de sécurité sur les versions traduites. Si tu vois une erreur de certificat après la bascule, le guide sur le certificat SSL expiré ou invalide donne la marche à suivre, wildcard compris.
4. Associer chaque sous-domaine à sa langue dans GTranslate
Dans le dashboard GTranslate, section “Sub-domain URL Structure”, vérifie que chaque langue active est bien reliée au sous-domaine correspondant, et que l’option de détection automatique de la langue du navigateur ne redirige pas de force les visiteurs français vers en.site.com. C’est une source fréquente de perte de trafic silencieuse : le visiteur arrive, se fait rediriger, rebondit.
5. Corriger les balises hreflang
GTranslate génère en principe les balises hreflang automatiquement, mais elles doivent pointer vers les bonnes URLs de sous-domaines et inclure une valeur x-default. Vérifie le code source (Ctrl+U) de la page d’accueil sur chaque langue : les balises <link rel="alternate" hreflang="..."> doivent lister toutes les versions, y compris elles-mêmes. Un site vraiment multilingue avec RTL (hébreu) ajoute une couche supplémentaire de complexité SEO et technique, détaillée dans le guide site bilingue FR/HE avec RTL.
6. Casser les boucles de redirection
Si un sous-domaine boucle en ERR_TOO_MANY_REDIRECTS, le conflit vient presque toujours d’une règle de forçage HTTPS ou www dans le .htaccess ou dans un plugin de sécurité, qui entre en conflit avec le routage du proxy GTranslate. Désactive temporairement les règles de redirection custom, teste le sous-domaine seul, puis réintroduis-les une par une. La procédure complète est dans ERR_TOO_MANY_REDIRECTS sur WordPress.
7. Le piège Fail2Ban : whitelister les IP de GTranslate
C’est le point le plus sournois, parce qu’il ne donne aucun message d’erreur clair. Si ton serveur tourne sous Fail2Ban (courant sur VPS géré ou hébergement mutualisé avancé), une jail trop stricte (nginx-limit-req, wordpress-hard, ou une jail custom sur les tentatives de connexion) peut bannir automatiquement les IP utilisées par le proxy GTranslate, perçues comme un flux de requêtes suspect.
Vérifie les IP actuellement bannies :
fail2ban-client status
fail2ban-client status <nom-de-la-jail>Compare la liste avec les plages IP publiées par GTranslate dans leur documentation technique. Si tu retrouves une correspondance, débannis immédiatement :
fail2ban-client set <nom-de-la-jail> unbanip <IP>Puis whiteliste durablement ces plages dans /etc/fail2ban/jail.local, section ignoreip, pour que le blocage ne se reproduise pas à chaque cycle de bannissement automatique. Si tu ne sais pas exactement quelles jails tournent sur ton serveur ni comment on t’y bloque l’accès légitime, le raisonnement est le même que pour une erreur 403 Forbidden : un mécanisme de sécurité trop zélé qui punit un acteur légitime.
Tableau récapitulatif
| Symptôme | Cause probable | Solution |
|---|---|---|
| Sous-domaine ne répond pas | CNAME manquant ou mal pointé | Créer l’enregistrement DNS vers le proxy GTranslate |
| Cadenas barré / erreur de certificat | SSL non-wildcard | Générer un certificat *.site.com |
| Traduction absente sans erreur visible | IP GTranslate bannie par Fail2Ban | Débannir + whitelister dans jail.local |
| Boucle infinie de redirection | Conflit HTTPS/www vs routage proxy | Isoler et réordonner les règles de redirection |
| Pages dupliquées mal indexées | Hreflang absent ou incorrect | Vérifier et corriger les balises dans le head |
| Redirection forcée vers la mauvaise langue | Détection auto du navigateur trop agressive | Désactiver ou affiner la détection dans GTranslate |
FAQ
Faut-il un certificat wildcard même avec seulement deux langues ?
Oui, dès qu’un seul sous-domaine supplémentaire (en.site.com) est créé, ton certificat racine ne le couvre pas. Le wildcard évite de régénérer un certificat à chaque nouvelle langue ajoutée.
Comment savoir si Fail2Ban est la cause exacte de la panne de traduction ?
Consulte /var/log/fail2ban.log et cherche des bannissements récents correspondant aux plages IP publiées par GTranslate. Si le blocage coïncide avec l’arrêt de la traduction, c’est confirmé.
Le mode sous-dossier (/en/) évite-t-il tous ces problèmes ?
Il évite le DNS et le certificat wildcard, mais garde les enjeux hreflang et de configuration du proxy. C’est un choix plus simple techniquement, à privilégier si le SEO par pays n’est pas une priorité absolue.
Pourquoi Google indexe-t-il mal mes pages traduites ?
Le plus souvent à cause de hreflang manquants ou incohérents entre sous-domaines, combinés à un contenu perçu comme dupliqué. Vérifie aussi qu’aucune règle de redirection ne bloque le crawl des versions traduites.
Dois-je whitelister GTranslate même si je n'utilise pas Fail2Ban ?
Si ton hébergeur ou ton pare-feu applicatif (WAF) applique un rate-limiting équivalent, oui — le principe est identique : identifier le mécanisme de blocage et y ajouter une exception pour les IP du proxy.
Quand passer la main à un pro
Si après ces sept étapes le sous-domaine reste inaccessible, ou si tu ne sais pas où se trouve ta configuration Fail2Ban (VPS géré, hébergement mutualisé avancé, serveur derrière un reverse-proxy Nginx), c’est le moment de passer la main. Un mauvais réglage sur un certificat wildcard ou une jail de sécurité peut aussi bien exposer le site que le rendre totalement injoignable — pas un terrain pour l’essai-erreur en production.
Ce problème, Peechy s'en occupe
Plutôt que de tout gérer seul, confiez votre site à une agence qui s'occupe de tout — hébergement, sécurité, maintenance et corrections. Encore plus simple en abonnement : on règle les soucis avant même que vous les remarquiez.
Confier mon site à Peechy