Pourquoi les URLs multilingues sont un problème de gouvernance, pas de technique
La partie technique est simple. Drupal gère nativement le multilingue, le module Path Auto génère les slugs automatiquement, le module hreflang injecte les balises dans le <head>. Les modules existent, ils fonctionnent.
Le problème survient quand personne n'a décidé comment ils devaient fonctionner.
Les trois erreurs les plus fréquentes
1. Des slugs traduits sans cohérence structurelle. L'URL française est /fr/conseil/strategie-digitale. L'URL anglaise est /en/services/digital-consulting. Ces deux pages sont des traductions l'une de l'autre, mais leurs structures d'URL n'ont aucun rapport. Le module hreflang peut les relier — mais si cette incohérence se répète sur 400 pages, le crawl budget se disperse.
2. Des balises hreflang incomplètes. Vous avez trois langues : français, anglais, arabe. Vos balises hreflang mentionnent le français et l'anglais. L'arabe est absent — ou présent sur certaines pages et absent sur d'autres. Google ignore les ensembles hreflang partiels.
3. Des redirections qui n'existent pas. Un éditeur renomme un nœud. Drupal génère un nouveau slug via Path Auto. L'ancien slug devient une 404. Si personne n'a activé le module Redirect, chaque mise à jour éditoriale perfore votre maillage interne et invalide des backlinks.
Définir une politique de slugs pour un site multilingue
Avant de toucher à un module, il faut répondre à quatre questions. Les réponses deviennent votre politique documentée.
1. Quelle structure de préfixe de langue ?
Pour la majorité des projets B2B avec une seule marque et plusieurs langues, le préfixe d'URL est la solution la plus simple à gouverner. Recommandation : donnez un préfixe à toutes les langues, y compris la langue par défaut. Cela simplifie la configuration hreflang et évite les ambiguïtés sur les canonicals.
2. Les slugs doivent-ils être traduits ou en langue source ?
Pour un site B2B avec un nombre limité de pages stratégiques, les slugs traduits sont recommandés. Pour un catalogue de plusieurs milliers d'entrées, la maintenance du slug traduit devient un frein — un slug en langue source avec un bon hreflang est alors préférable.
3. Quelle est la structure de path par type de contenu ?
Path Auto génère les slugs à partir de tokens. Exemple de pattern pour un type article : [node:langcode]/articles/[node:title]. N'utilisez jamais [current-user:...] ni des tokens qui varient selon le contexte de déclenchement — les slugs générés seront incohérents.
4. Qui peut modifier un slug manuellement ?
La réponse correcte est : personne, sauf cas exceptionnel documenté. Encodez cette règle dans les permissions Drupal : retirez la permission create url aliases aux rôles éditoriaux.
Configurer Path Auto pour un site multilingue
Path Auto est le pivot de la gouvernance des URLs dans Drupal. Dans les paramètres de nettoyage, configurez : séparateur tiret, suppression des séparateurs répétés, translittération pour les langues non-ASCII. Longueur maximale recommandée : 100 caractères.
Ne régénérez jamais en masse sans avoir activé le module Redirect en amont. La procédure correcte : activer Redirect avec création automatique → tester sur un échantillon → lancer la régénération via Drush : drush pathauto:aliases-generate --all → auditer un échantillon de 20 %.
Mettre en place le hreflang correctement
Le balisage hreflang indique aux moteurs de recherche quelle version d'une page servir à quel utilisateur. Son implémentation incorrecte est l'une des erreurs les plus coûteuses en référencement multilingue.
Les règles d'un hreflang valide
- La réciprocité est obligatoire. Si la page FR pointe vers EN, la page EN doit pointer vers FR. Google vérifie la réciprocité. Un hreflang unilatéral est ignoré.
- Les codes de langue doivent suivre la norme BCP 47.
frpour le français générique,fr-FRpour la France,fr-BEpour la Belgique. Ne mélangez pas les deux formes. - Toutes les variantes doivent être présentes. Si vous avez quatre langues, chaque page doit avoir quatre balises hreflang plus
x-default. - N'utilisez pas hreflang pour des contenus non traduits. Une balise pointant vers une page 404 est activement pénalisante.
La balise x-default est obligatoire. Elle désigne la version à servir quand aucune langue de l'utilisateur ne correspond aux variantes disponibles.
Configuration dans Drupal
Module recommandé : hreflang (module contributeur stable). Il lit les traductions disponibles d'un nœud et injecte les balises correspondantes. Pour les sitemaps multilingues, le module Simple XML Sitemap supporte nativement la génération avec attributs hreflang.
Gérer les redirections lors des mises à jour de contenu
Les redirections sont la mémoire de votre architecture d'URL. Sans elles, chaque modification de contenu érode silencieusement votre référencement.
Configuration essentielle du module Redirect
- Activer "Automatically create redirects when URL aliases are changed".
- Activer "Detect feedback loops" pour éviter les boucles A → B → A.
- Planifier un audit annuel pour supprimer les redirections obsolètes.
Redirections multilingues : attention aux chemins sans préfixe
Les anciennes URLs créées avant l'activation du multilingue n'ont pas de préfixe de langue. Créez des redirections explicites de ces anciens chemins vers les versions avec préfixe. Recommandation : redirigez vers la version dans la langue par défaut, et laissez le hreflang permettre à Google de servir la bonne variante.
Plan de migration sécurisé pour reprendre un historique d'URLs
Reprendre un site existant impose de gérer un historique d'URLs qui a potentiellement des années de backlinks et d'indexation derrière lui.
Phase 1 : audit de l'existant
Crawler l'intégralité du site en production. Extraire les données Google Search Console : pages qui génèrent des clics, pages orphelines. Extraire les backlinks pour identifier les URLs à protéger en priorité.
Phase 2 : construire la table de correspondance
Pour chaque URL existante, identifiez l'URL cible. Cette table est la source de vérité de votre migration. Ne laissez aucune ligne vide dans la colonne url_cible — toute URL sans destination devient une 404 de migration.
Phase 3 : préparer les redirections avant le lancement
Importez l'intégralité de la table de correspondance comme redirections 301 en préproduction. Vérifiez l'absence de boucles et de chaînes de redirections (réduire A → B → C à A → C directement).
Phase 4 : validation avant mise en production
Simulez le crawl en mode "List" avec Screaming Frog en injectant votre liste d'URLs sources : toutes doivent retourner 301 ou 200, aucune 404.
Phase 5 : surveillance post-lancement
Créez une alerte sur le taux d'erreurs 404 dans Google Search Console. Exportez chaque semaine le rapport des erreurs 404 pendant le premier mois, et créez les redirections manquantes au fur et à mesure.
Générer des URLs multilingues en PHP dans Drupal
Quand vous générez des URLs en PHP dans un module ou un template Drupal, la gestion du multilingue demande quelques précautions : forcer la langue dans les options de génération d'URL, itérer sur les traductions disponibles d'un nœud pour construire des blocs de navigation custom, et configurer trusted_host_patterns dans settings.php pour éviter les URLs invalides générées dans les contextes sans requête HTTP (Drush, cron, queues).
Ce qu'il faut retenir
Gouverner les URLs d'un site Drupal multilingue revient à prendre quatre décisions une fois, les documenter, et les confier aux modules :
- Structure des slugs : préfixes de langue sur toutes les variantes, patterns Path Auto par type de contenu, interdiction de modification manuelle sans procédure.
- hreflang complet et réciproque : toutes les variantes présentes sur toutes les pages, codes BCP 47, x-default systématique.
- Redirections automatiques : module Redirect avec création automatique à chaque changement de chemin, audit régulier.
- Migration documentée : table de correspondance exhaustive, redirections importées avant le lancement, surveillance active les premières semaines.
Un site multilingue bien gouverné n'est pas plus complexe à maintenir qu'un site monolingue — il l'est moins, parce que les règles sont explicites et les erreurs visibles avant qu'elles coûtent du trafic.