Exemples de sites Web WordPress multilingues : 4 sites à étudier

Résumez ce post avec : 8 minutes de lecture

Les bons sites Web WordPress multilingues partagent trois habitudes. Chaque langue vit sur sa propre URL. Chaque page utilise des balises hreflang pour informer les moteurs de recherche de ses autres versions linguistiques. Et les visiteurs peuvent changer de langue depuis n’importe quelle page sans perdre leur place. Les quatre exemples en direct ci-dessous y parviennent de différentes manières, l'un avec un sous-domaine par langue et d'autres avec des sous-dossiers simples, et l'un d'eux montre quelque chose que vous ne devez pas copier.

Nous avons vérifié le HTML en direct de chaque exemple en septembre 2026. Tous les quatre fonctionnent sur WordPress (leurs pages chargent des ressources à partir de wp-content), et nous avons enregistré la structure de l'URL et la configuration hreflang de chacune. Les sites changent, alors traitez les détails comme un instantané.

Principaux points à retenir

Sous-dossiers (example.com/de/) sont la structure la plus courante et la plus simple pour les sites WordPress multilingues. Les sous-domaines conviennent aux grandes communautés linguistiques gérées séparément.
Les bons sites incluent une balise hreflang auto-référencée, l'ensemble complet des alternatives et un x-default repli.
Les commutateurs de langue fonctionnent mieux lorsqu'ils affichent les noms de langue dans la langue elle-même (allemand, espagnol) et apparaissent sur chaque page.
Un site régional avec un contenu différent dans chaque pays est différent d’un site traduit. N'ajoutez pas de hreflang entre les pages qui ne sont pas équivalentes.
Un plugin multilingue et un service de traduction hébergé peuvent produire le même résultat. Jugez le résultat plutôt que l’outil.

Pourquoi regarder des exemples réels

Un guide vous dit quoi faire. Un site en direct vous montre à quoi ressemble la chose finie. Lorsque vous étudiez un exemple, vérifiez quatre choses :

Structure de l'URL. Où se trouve la version allemande ?
Hreflang. Afficher la source de la page et rechercher hreflang. Toutes les versions linguistiques sont-elles répertoriées, y compris la page elle-même et une x-default?
Commutateur de langue. Où est-il, comment sont étiquetées les langues et est-ce que cela vous permet de rester sur la même longueur d’onde ?
Profondeur de traduction. La navigation, le pied de page, les boutons, les dates et les métadonnées sont-ils traduits, ou uniquement le corps du texte ?

Exemple 1 : sites locaux WordPress.org (un sous-domaine par langue)

WordPress.org gère un site local distinct pour chaque communauté linguistique : l'allemand à de.wordpress.org, Espagnol à es.wordpress.org, et ainsi de suite.

Ce que nous avons trouvé:

Chaque langue a son propre sous-domaine avec son propre lang attribut (<html lang="de"> sur le site allemand).
La page d'accueil allemande répertorie 156 valeurs hreflang distinctes, une pour chaque site WordPress.org local, afin que les moteurs de recherche puissent faire correspondre chaque chercheur avec la bonne communauté.
Chaque site local est géré comme son propre espace, avec des actualités et du contenu locaux, plutôt que comme un miroir du site anglais.

La partie qui mérite d'être copiée : si chaque langue a sa propre équipe, son propre contenu et ses propres priorités, les sous-domaines les séparent tandis que hreflang relie les pages équivalentes entre elles.

La partie à ne pas copier aveuglément est l'échelle. Plus de 150 versions linguistiques est un projet communautaire avec des bénévoles dans toutes les langues. La plupart des entreprises devraient commencer par deux ou trois langues et les faire bien.

Exemple 2 : le blog Mozilla (sous-dossiers avec un x-default)

Le blog de Mozilla à blog.mozilla.org conserve chaque édition linguistique dans un sous-dossier, y compris l'anglais (/en/) et allemand (/de/).

Ce que nous avons trouvé:

La page d'accueil allemande déclare trois alternatives hreflang : en → /en/, de → /de/, et x-default → /en/.
Le lang l'attribut sur les pages allemandes est de-DE.

Pour la plupart des sites, il s’agit du modèle le plus propre à copier. Chaque langue est un sous-dossier sur un domaine, de sorte que l'autorité du site reste au même endroit, et x-default indique aux moteurs de recherche quelle version afficher aux personnes dont la langue n'est pas couverte. Notre guide de hreflang explique pourquoi le x-default la ligne compte.

Exemple 3 : TranslatePress.com (sous-dossiers avec codes de langue et de région)

TranslatePress crée un plugin de traduction WordPress et son propre site Web est un site WordPress multilingue en anglais, espagnol, allemand, français et italien.

Ce que nous avons trouvé:

L'anglais est à la racine (translatepress.com/) et les autres langues dans les sous-dossiers (/es/, /de/, /fr/, /it/).
Il répertorie chaque langue deux fois dans hreflang, une fois avec un code uniquement linguistique (es) et une fois avec un code langue-région (es-ES), plus x-default pointant vers la racine anglaise.
Le sélecteur de langue est présent sur la page et étiquette les langues par leur nom.

La partie qui vaut la peine d'être copiée : conserver la langue originale à la racine et ajouter des traductions dans des sous-dossiers est facile sur un site existant, car aucune de vos URL actuelles ne change.

Une chose à laquelle il faut penser avant de copier le reste. Liste des deux es et es-ES car la même URL est valide, mais cela n'aide que si vous pouvez créer ultérieurement des versions distinctes pour d'autres régions (par exemple es-MX). Si vous avez une version par langue, les codes uniquement linguistiques suffisent. Notre liste de codes de langue hreflang vous aide à choisir les bons.

Exemple 4 : Salles de rédaction régionales Microsoft Source (un site régional, pas un site traduit)

Le site d'actualités de Microsoft fonctionne sur WordPress et propose des éditions régionales. Vous arrivez à l'édition allemande à partir de news.microsoft.com/de-de/, et il atterrit sur une page régionale avec un ?lang=de paramètre.

Ce que nous avons trouvé:

L'édition allemande utilise <html lang="de-DE"> et raconte des histoires en langue allemande.
Nous n'avons pas trouvé de balises hreflang dans l'en-tête de la page allemande que nous avons vérifiée.

Cela est correct pour une salle de rédaction régionale, qui est une publication distincte et non une traduction du site anglais. De nombreuses histoires allemandes n’ont pas d’équivalent anglais, donc un décalage entre les pages régionales serait erroné. Suivez la même règle sur votre site : liez des pages équivalentes avec hreflang et laissez de côté les pages qui n'existent que sur un seul marché. Ne copiez cependant pas le format URL. Google répertorie les paramètres d'URL tels que ?lang= comme “non recommandé” pour les sites multilingues et préfère les sous-dossiers, sous-domaines ou domaines de pays (Recherche Google Central).

Ce que les meilleurs sites WordPress multilingues ont en commun

Pratique	Pourquoi c'est important	Comment vérifier sur votre site
Une URL par langue	Les moteurs de recherche indexent les URL ; une langue qui n'apparaît que via un cookie ou un script ne peut jamais être indexée	Ouvrez la page traduite dans une fenêtre privée ; l'URL doit être différente
Hreflang complet et réciproque	Empêche les versions linguistiques de rivaliser et envoie les chercheurs vers la bonne	Voir la source, rechercher `hreflang`, confirme que chaque version répertorie toutes les autres et elle-même
`x-default`	Donne une solution de secours pour les langages non pris en charge	Chercher `hreflang="x-default"`
Correct `lang` attribut	Aide les navigateurs, les lecteurs d'écran et les outils de traduction	Vérifiez le `<html lang="…">` valeur sur chaque version
Commutateur de langue visible	Les visiteurs peuvent corriger une mauvaise supposition ; Google recommande de lier les versions linguistiques	Changez de langue à partir d'une page profonde et confirmez que vous restez sur la page équivalente
Métadonnées traduites	Les titres et les descriptions sont ce que les chercheurs voient en premier	Vérifiez le `<title>` et méta description sur une page traduite

Pour une liste de contrôle plus longue, consultez notre guide sur meilleures pratiques pour les sites Web multilingues WordPress.

Comment créer un site comme ceux-ci sur WordPress

Il existe deux grandes façons de le faire.

Le premier est un plugin multilingue qui stocke les traductions dans WordPress, telles que WPML, Polylang ou TranslatePress. Vous créez ou traduisez chaque page dans WordPress, et le plugin gère les URL et hreflang. Vous obtenez un contrôle total, au prix d'une configuration plus poussée, en particulier avec les créateurs de pages, les champs personnalisés et WooCommerce. Voir notre comparaison de Weglot, WPML et ConveyThis pour la façon dont ces approches diffèrent.

Le second est un service de traduction hébergé avec un plugin WordPress, tel que ConveyThis. Vous installez le plugin et choisissez les langues, et le service traduit vos pages et les diffuse sur des URL linguistiques. Vous révisez et modifiez ensuite les traductions.

Avec ConveyThis pour WordPress, le résultat correspond aux modèles ci-dessus :

Chaque langue est servie sur sa propre URL : sous-dossiers par défaut sur WordPress, ou sous-domaines si vous préférez.
Les balises Hreflang sont ajoutées automatiquement et les titres des pages, les méta descriptions et JSON-LD sont traduits.
Un sélecteur de langue est ajouté à chaque page. Vous choisissez des drapeaux ou pas de drapeaux, et si les langues sont étiquetées en anglais, dans leur propre langue ou par code.
Un éditeur visuel, un glossaire et une mémoire de traduction vous permettent d'affiner les traductions dans leur contexte et de maintenir la cohérence des termes.

Le plugin compte 1 000+ installations actives sur WordPress.org et est noté 4,4/5 sur 145 notes. Pour les sites en direct qui utilisent ConveyThis, sur WordPress et ailleurs, consultez notre exemples clients.

Questions fréquemment posées

Quelle est la meilleure structure d’URL pour un site WordPress multilingue ? Pour la plupart des sites, sous-dossiers (example.com/de/). Ils conservent chaque langue sur un seul domaine et sont les plus simples à maintenir. Les sous-domaines ont du sens lorsque chaque langue est gérée comme un site distinct.

Comment puis-je savoir si un site multilingue est construit sur WordPress ? Afficher la source de la page et rechercher les chemins contenant wp-content ou wp-includes. Certains sites les cachent, leur absence ne prouve donc pas qu'un site n'est pas WordPress.

Ai-je besoin d’une installation WordPress distincte pour chaque langue ? Non. Un plugin multilingue ou un service de traduction peut servir toutes les langues à partir d'une seule installation WordPress. WordPress Multisite est une option lorsque chaque langue est un site distinct avec son propre contenu.

Qu’est-ce qui fait qu’un changement de langue est bon ? Il est visible sur chaque page, étiquette les langues dans leur propre langue (allemand, pas allemand), maintient le visiteur sur la page équivalente et ne force jamais une redirection basée uniquement sur les paramètres du navigateur.

Pour configurer votre site WordPress de la même manière, essayez ConveyThis gratuitement avec une langue et 5 000 mots.

Exemples de sites Web WordPress multilingues (et ce qu'il faut copier)

Pourquoi regarder des exemples réels

Exemple 1 : sites locaux WordPress.org (un sous-domaine par langue)

Exemple 2 : le blog Mozilla (sous-dossiers avec un x-default)

Exemple 3 : TranslatePress.com (sous-dossiers avec codes de langue et de région)

Exemple 4 : Salles de rédaction régionales Microsoft Source (un site régional, pas un site traduit)

Ce que les meilleurs sites WordPress multilingues ont en commun

Comment créer un site comme ceux-ci sur WordPress

Questions fréquemment posées