Un site WordPress traduit en trois langues ne génère pas automatiquement trois fois plus de trafic organique. La plupart des pertes de visibilité à l’international proviennent d’erreurs techniques silencieuses : des balises hreflang mal déclarées, des URL canoniques contradictoires ou un sitemap XML qui ignore certaines versions linguistiques. Mesurer l’écart entre ce qu’un site déclare à Google et ce que Google indexe réellement permet de cibler les corrections qui débloquent le référencement multilingue.
Écarts fréquents entre déclaration hreflang et indexation réelle sur WordPress
La majorité des audits multilingues révèlent un décalage entre les balises hreflang insérées dans le code et les pages effectivement indexées par Google. Ce décalage prend des formes prévisibles selon le plugin de traduction utilisé et la configuration du thème.
| Type d’écart | Symptôme dans Google Search Console | Cause fréquente sur WordPress |
|---|---|---|
| Hreflang non réciproque | La page FR pointe vers EN, mais EN ne pointe pas vers FR | Traduction partielle : la version EN n’existe pas encore ou reste en brouillon |
| URL alternate en redirection | Google ignore le signal hreflang | Changement de slug après publication, sans mise à jour du sitemap multilingue |
| Canonical conflictuel | Page exclue avec mention « Canonical alternative » | Le plugin SEO déclare la version FR comme canonical sur la page EN |
| Auto-référence manquante | Aucune version linguistique affichée dans les résultats locaux | Le site omet de s’inclure lui-même dans la liste des alternates |
Google exige que chaque version linguistique se liste elle-même parmi les alternates. C’est un point que la documentation officielle (Google Search Central, « Localized Versions of your Pages ») rappelle explicitement. Sur WordPress, les plugins WPML et Polylang gèrent normalement cette auto-référence, mais elle disparaît dès qu’une page passe en brouillon ou qu’un slug est modifié manuellement.
Balises canoniques et hreflang sur WordPress : pourquoi les conflits passent inaperçus
Les conflits entre canonical et hreflang sont la source d’erreurs la plus sous-estimée sur un WordPress multilingue. Le problème vient de la cohabitation de deux logiques distinctes gérées par des extensions différentes.
Un plugin SEO (Yoast, Rank Math) génère la balise canonical. Le plugin de traduction (WPML, Polylang, TranslatePress) génère les balises hreflang. Aucun des deux ne vérifie la cohérence avec l’autre.
Le scénario type qui bloque l’indexation
Une fiche produit existe en français et en anglais. Le plugin SEO détecte un contenu similaire et attribue automatiquement la canonical de la page anglaise vers la page française. Le plugin de traduction, lui, déclare les deux pages comme alternates via hreflang. Google reçoit un signal contradictoire : la page EN est supposée être une variante légitime (hreflang) mais aussi un doublon à ignorer (canonical).
Les URL d’alternatives doivent renvoyer une page canonique en 200 pour que le signal hreflang soit pris en compte. Une URL qui redirige, retourne une erreur 404 ou pointe vers une autre canonical perd sa valeur de signal multilingue.
Pour détecter ces conflits, la méthode la plus fiable reste de crawler le site avec un outil comme Screaming Frog en activant l’extraction des balises hreflang et canonical simultanément, puis de croiser les deux jeux de données.
Sitemap XML multilingue WordPress : trois méthodes, des résultats très différents
Google accepte trois méthodes pour déclarer les variantes multilingues : les balises HTML dans le head, les en-têtes HTTP et le sitemap XML. Sur WordPress, le sitemap XML reste la méthode la plus fiable pour les sites volumineux, car elle ne dépend pas du rendu HTML de chaque page.
Ce que le sitemap doit contenir
- Chaque URL doit apparaître avec ses attributs xhtml:link listant toutes les versions linguistiques, y compris elle-même
- Les URL doivent être pleinement qualifiées (avec https:// et le domaine complet), pas en relatif
- Chaque URL listée doit retourner un code 200 et ne pas être marquée noindex
- La valeur x-default doit pointer vers la version par défaut du site (souvent la langue principale ou une page de sélection de langue)
WPML génère nativement un sitemap multilingue compatible si l’option est activée. Polylang, en revanche, nécessite une configuration manuelle ou l’association avec un plugin SEO qui prend en charge les attributs hreflang dans le sitemap. Vérifier cette génération dans Google Search Console (section Sitemaps) permet de repérer les URL soumises mais non indexées.
Erreur courante : plusieurs sitemaps concurrents
Quand Yoast et WPML génèrent chacun un sitemap, Google peut recevoir des déclarations hreflang contradictoires. Un seul sitemap doit porter les déclarations multilingues. Désactiver la génération de sitemap du plugin SEO ou celle du plugin de traduction, selon celui qui produit le fichier le plus complet, évite ce doublon.
Audit WordPress multilingue : vérifications que Google Search Console ne montre pas
Google Search Console signale certaines erreurs hreflang dans le rapport « Ciblage international », mais plusieurs problèmes critiques échappent à cet outil.
- Les pages en brouillon ou en attente de relecture ne sont pas crawlées, donc leur absence du maillage hreflang n’apparaît nulle part dans la console
- Le sélecteur de langue (language switcher) qui utilise JavaScript sans fallback HTML empêche Google de suivre les liens entre versions linguistiques
- Les redirections automatiques par géolocalisation IP, parfois activées par des plugins WordPress, empêchent Googlebot d’accéder à certaines versions linguistiques depuis son IP américaine
Google rappelle que hreflang ne sert pas à détecter la langue d’une page. C’est un signal de relation entre versions localisées. La détection de langue se fait par algorithme, indépendamment du balisage. Un contenu mal traduit ou partiellement en anglais sur une page déclarée française peut donc être classé dans la mauvaise langue, même avec un hreflang correct.
Accessibilité et conformité européenne
Depuis le 28 juin 2025, l’European Accessibility Act s’applique aux services numériques destinés aux consommateurs dans l’UE. Les sites WordPress multilingues qui vendent en Europe doivent vérifier que chaque version linguistique respecte les critères d’accessibilité, pas uniquement la version principale. Un audit multilingue qui ignore cet aspect expose le site à un risque juridique en plus du risque SEO.
Le point de départ d’un audit WordPress multilingue reste toujours le même : comparer ce que le site déclare (hreflang, canonical, sitemap) avec ce que Google indexe réellement (Search Console, cache, requête site:). L’écart entre les deux mesures la dette technique multilingue accumulée, et chaque correction rapproche le site d’une indexation propre sur ses marchés cibles.
