Le conseil standard en SEO international, ce sont les sous-dossiers.
site.com/de/ pour l'allemand.site.com/fr/ pour le français.site.com/ja/ pour le japonais.
Ce conseil est faux. Pas un peu faux. Fondamentalement faux. Et le suivre coûte aux opérateurs des quantités énormes de trafic et de revenus.
Voici pourquoi.
Quand Google explore site.com/de/, il voit une page allemande sur un domaine anglais. L'autorité du domaine, son profil de backlinks, son ancienneté et sa confiance — tout cela est ancré dans la langue et le marché principaux du domaine racine. Le sous-dossier allemand est, pour l'essentiel, un invité dans la maison d'un autre.
Quand Google explore de.site.com, il voit autre chose. Un site web allemand. Avec sa propre identité. Sa propre structure hreflang pointant vers 68 autres variantes linguistiques. Sa propre autorité canonique. Adossé à toute l'autorité de domaine de la racine, mais exprimé comme une véritable présence web allemande.
Google les traite différemment. Je l'ai vu se produire en temps réel.
Moins de 24 heures après le lancement de pl.pornfreetrial.com — le sous-domaine polonais d'un site que j'ai reconstruit cette semaine —, nous étions classés #3 sur le Google polonais pour notre principal mot-clé cible.
24 heures.
Sur un domaine qui venait d'être migré de WordPress vers une stack FastAPI sur mesure.
Cela n'arrive pas avec des sous-dossiers. Cela arrive parce que Google a vu un vrai site polonais, avec des textes en polonais, une devise polonaise (zł3.74 — « Praktycznie Za Darmo », pratiquement gratuit), des balises hreflang correctes pointant vers 68 autres variantes de locale authentiques, et une couche de détection d'IP qui servait automatiquement le contenu polonais aux visiteurs polonais.
C'est là la différence entre traduction et localisation.
Traduire, c'est changer les mots.
Localiser, c'est changer l'expérience.
L'infrastructure que j'ai construite avec TreeChain fait cela dans 69 langues à partir d'une seule base de code. Un seul offers.json. Un seul service FastAPI. Un DNS wildcard sur Cloudflare qui pointe *.domain.com vers un serveur unique. Une détection d'IP qui achemine automatiquement les visiteurs vers leur locale.
Résultat : 69 présences web authentiques, chacune avec sa devise locale, des textes locaux qui se lisent naturellement (pas de traduction automatique) et une structure SEO correcte — toutes déployées simultanément dès le premier jour.
La plupart des opérateurs passent des années à construire correctement un seul marché. Cette infrastructure construit tous les marchés en même temps.
L'erreur que tout le monde commet est de croire que l'i18n est un problème de traduction. C'est un problème d'infrastructure. Réglez-le au niveau de l'infrastructure et la traduction devient une conséquence, pas un projet.
La théorie des sous-domaines n'est pas une astuce. C'est à ça que ressemble le correct.