SEO Drupal : les réglages et modules qui comptent

Une installation Drupal standard n'est pas optimisée pour le référencement dès l'activation : le cœur du CMS génère par défaut une URL du type /node/123, ne propose aucune balise meta éditable, et laisse le sitemap, les redirections et le multilingue entièrement à la charge de l'équipe technique. C'est pour sa robustesse et son système de permissions fines que Drupal reste très employé sur les sites institutionnels, les portails ministériels et les intranets du secteur public en France — mais c'est aussi pourquoi tant de ces sites traînent des URL illisibles, des balises title dupliquées entre types de contenu, ou des pages de recherche interne indexées par erreur depuis des années.

Cet article ne revient pas sur les mécaniques SEO génériques déjà traitées ailleurs (canonical, HTTPS, données structurées) : il détaille les réglages propres à Drupal qui les mettent en œuvre — Pathauto pour les alias d'URL, Metatag pour les balises, le sitemap XML, le module Redirect pour éviter les liens brisés lors des refontes, la configuration multilingue du cœur, et le cache, qui influence directement ce que Googlebot reçoit au moment de l'exploration.

Alias d'URL avec Pathauto : la base avant tout le reste

Sans configuration, un nœud Drupal reste accessible à l'URL /node/123 même après avoir reçu un alias propre : les deux adresses coexistent, ce qui crée une duplication interne si rien ne les relie. Le module Pathauto résout la génération : il crée automatiquement un alias à partir d'un modèle de jetons (tokens) défini par type de contenu, par exemple [node:content-type]/[node:title] pour les actualités ou [node:title] seul pour les pages statiques. Le piège classique consiste à réutiliser le même modèle sur plusieurs types de contenu proches — un site institutionnel qui applique [node:title] aux « actualités » et aux « communiqués » verra Pathauto ajouter un suffixe numérique (-0, -1) dès qu'un titre se répète, ce qui produit des URL peu lisibles.

Le comportement à surveiller ensuite est la mise à jour d'alias (Pathauto > Réglages > « que faire quand l'alias existant est invalide »). Par défaut, un nouvel alias est créé sans toucher à l'ancien, qui devient une page fantôme accessible mais non liée. En activant le module Redirect en complément, Pathauto propose de créer automatiquement une redirection 301 de l'ancien alias vers le nouveau chaque fois qu'un titre change ou qu'un modèle est modifié pour tout un type de contenu — un cas fréquent lors d'une refonte de l'arborescence d'un site institutionnel.

Pour un site déjà en production avant l'activation de Pathauto, l'action en masse « Générer les alias » (Configuration > Recherche et métadonnées > Alias d'URL) applique rétroactivement le modèle à tout le contenu existant, mais sans créer de redirection depuis les anciennes URL /node/ID : si ces adresses ont déjà été indexées ou partagées, il faut les rediriger manuellement via le module Redirect.

• [node:title] — le titre du nœud seul, pour les pages statiques
• [node:content-type]/[node:title] — préfixé par rubrique, utile pour distinguer actualités et pages
• [term:name] — le nom d'un terme de taxonomie associé, pour un chemin organisé par catégorie
• [current-date:custom:Y/m] — utile pour dater les URL d'un blog d'actualités

Le module Metatag : balises title, description et Open Graph

Le module Metatag ajoute, par type de contenu, un jeu de balises meta configurables avec les mêmes jetons que Pathauto : balise title, meta description, canonical, Open Graph et Twitter Card. Le point de vigilance est le modèle par défaut hérité de la configuration globale : si un type de contenu ne reçoit pas son propre modèle, il retombe sur le modèle générique du site, souvent identique pour toutes les pages de listing (taxonomie, vues), ce qui produit des dizaines de balises title strictement identiques.

La balise robots méta mérite un réglage explicite par bundle plutôt que le comportement par défaut (index, follow partout). Les candidats naturels au noindex sont les pages de taxonomie sans texte de présentation propre, les pages de profil utilisateur, et les vues de recherche interne — utiles au visiteur mais sans valeur ajoutée pour un moteur de recherche, et qui diluent l'autorité du domaine si elles sont indexées en masse.

Le canonical géré par Metatag doit pointer vers l'alias Pathauto, jamais vers /node/ID : c'est le réglage par défaut, mais à revérifier après toute personnalisation, car un modèle de canonical laissé vide retombe sur l'URL courante telle que la requête l'a construite — y compris avec les paramètres ajoutés par une vue à filtres exposés, ce qui annule l'intérêt de la balise.

Sitemap XML : configuration et multilingue

Le module Simple XML Sitemap génère un ou plusieurs sitemaps à partir des entités activées (nœuds, taxonomies, utilisateurs), avec exclusion automatique du contenu non publié ou soumis à des permissions restreintes — un nœud visible seulement par un rôle authentifié ne se retrouve jamais dans le sitemap public. Le travail réel consiste à choisir, bundle par bundle, ce qui mérite d'y figurer : un formulaire interne ou un brouillon éditorial n'a rien à faire dans un sitemap, même techniquement publié.

Sur un site multilingue, le module génère un sitemap par langue et un fichier index qui les relie, ce qui correspond à la structure attendue pour le hreflang. Les champs priorité et fréquence de changement, hérités des premières versions du protocole, ont perdu leur poids dans l'exploration réelle de Google depuis longtemps ; les régler finement rapporte peu comparé au temps passé à vérifier que les bonnes entités sont incluses.

Le sitemap ne remplace pas un contrôle du budget d'exploration : il indique ce qui existe, pas ce qui mérite d'être exploré en priorité. Sur un portail de plusieurs milliers de pages, la soumission dans Search Console reste utile pour repérer l'écart entre URL soumises et URL réellement indexées — un écart qui pointe presque toujours vers un problème de qualité plutôt que vers le sitemap lui-même.

Le module Redirect : gérer les changements d'URL sans perdre de liens

Le module Redirect stocke les correspondances source → destination et applique par défaut un code 301, ce qui transmet la majorité de la valeur de liens vers la nouvelle adresse. Il s'utilise seul pour des corrections ponctuelles, mais devient indispensable sous forme automatisée lors d'une refonte : son import CSV accepte une liste de correspondances en masse, le scénario typique d'une migration Drupal 7 vers une version récente, où toute l'arborescence d'URL change en une seule opération.

L'erreur la plus fréquente est la redirection en chaîne : l'ancienne URL A redirige vers B, elle-même redirigée plus tard vers C, sans que personne ne corrige le premier maillon. Chaque redirection supplémentaire ajoute une latence et un risque que l'exploration s'arrête avant la destination finale ; la bonne pratique est de faire pointer A directement vers C dès qu'on détecte la chaîne.

Le module ne gère pas les combinaisons de paramètres de requête générées par une vue à filtres exposés — il travaille sur des chemins, pas sur des chaînes de requête arbitraires. Pour ce cas, le canonical côté Metatag ou un blocage ciblé sont les bons outils. Le rapport des pages non trouvées (dblog, ou un outil de crawl externe) reste la meilleure source pour repérer les 404 qui méritent une redirection avant qu'une baisse de trafic ne les révèle.

• Faute de frappe dans un alias existant : correction ponctuelle, un seul enregistrement
• Refonte complète de l'arborescence : import CSV en masse, tout en une opération
• Migration depuis Drupal 7 : mappage systématique ancien chemin vers nouvel alias
• Suppression définitive d'une page : redirection vers la rubrique parente plutôt qu'une 404 sèche

Multilingue : langue, traduction de contenu et hreflang

L'activation des modules cœur Language et Content Translation permet de traduire chaque nœud indépendamment et de choisir un préfixe de chemin par langue (/fr/, /en/) ou un domaine dédié. Une fois une traduction publiée, Drupal génère automatiquement les balises link rel="alternate" hreflang pour chaque version existante — un mécanisme intégré au cœur, à condition que les traductions soient réellement publiées et pas seulement créées à l'état de brouillon.

Le risque propre à Drupal est la ligne de traduction fantôme : le flux de traduction crée une entrée pour chaque langue activée dès qu'un traducteur ouvre l'onglet correspondant, même si le contenu n'a jamais été traduit. Si cette entrée reste accessible publiquement, elle expose une page vide ou partielle, indexable en langue « fr » sans texte propre à cette langue — un contenu fin proche du duplicata. Le rapport d'état des traductions (Contenu > Traductions) permet de les repérer avant qu'un moteur ne les explore.

Les modèles Pathauto doivent eux aussi être définis par langue : un alias traduit doit refléter la langue de destination (/fr/actualites/titre, /en/news/title), pas recevoir un préfixe de langue devant un slug resté en français. Les modèles Metatag doivent de même être traduits dans Configuration Translation, sinon la meta description reste dans la langue source pour toutes les traductions — un détail qui affecte directement ce que l'internaute lit dans les résultats avant de cliquer.

Cache et Core Web Vitals sous Drupal

Le cache interne de Drupal (Internal Page Cache pour les anonymes, Dynamic Page Cache pour les blocs dynamiques, BigPipe pour différer le rendu personnalisé) réduit le temps de réponse serveur, un facteur qui influence les métriques Core Web Vitals, en particulier le délai avant premier octet et donc le LCP. Ces caches sont actifs par défaut mais restent souvent mal réglés en durée de vie sur les sites qui publient plusieurs fois par jour.

Sur un site à fort trafic, un proxy comme Varnish placé devant Drupal repose sur le système de cache tags du cœur : chaque page mise en cache est associée aux entités qui la composent, et modifier un nœud invalide précisément les pages qui l'affichent, sans vider tout le cache. Le piège propre à Drupal survient quand le proxy en amont ignore ces cache tags et se contente d'un TTL fixe : un changement de titre ou de meta description peut alors continuer à être servi tel quel à Googlebot pendant plusieurs heures, sans erreur visible côté éditeur puisque son propre navigateur, authentifié, ne passe pas par le même cache.

L'agrégation CSS/JS et les styles d'image responsive, avec conversion WebP, réduisent le poids des pages, ce qui profite au LCP et au CLS. Sur les pages à fort trafic, il vaut mieux préchauffer ces dérivés d'image en amont plutôt que de laisser la première requête — potentiellement celle de Googlebot — déclencher leur génération à la volée.

Pièges spécifiques à Drupal après une mise en production

Le chemin /node/123 reste accessible en parallèle de son alias tant qu'aucune règle explicite ne l'en empêche : par défaut, Drupal ne redirige pas l'un vers l'autre. Le réglage minimal est de s'assurer que le canonical de Metatag pointe bien vers l'alias sur les deux versions, ce qui règle la duplication sans casser les liens externes qui pointeraient encore vers l'ancien format.

La page d'accueil pose un problème voisin : selon la configuration du chemin frontal (Configuration > Système > Informations du site), son contenu peut rester accessible à la fois via / et via son propre alias ou /node/ID — deux URL distinctes pour un contenu identique, à traiter avec la même logique de canonical.

Les vues à filtres exposés (annuaires, listes filtrables très présentes sur les sites institutionnels) génèrent une URL explorable pour chaque combinaison de tri et de filtre, un volume de pages fines souvent supérieur au contenu réel du site. La vue de recherche interne (/search/node) pose le même problème : elle reste indexable par défaut dans de nombreuses installations. Dans les deux cas, un noindex ciblé sur l'affichage de vue concerné, plutôt qu'une règle générale dans le robots.txt, évite de bloquer par erreur une page de contenu qui partagerait le même chemin de base.

• Le canonical de /node/ID pointe vers l'alias, jamais l'inverse
• La page d'accueil n'existe que sous une seule URL réellement indexable
• Les combinaisons non pertinentes des vues à filtres exposés sont en noindex
• La vue de recherche interne (/search/node) est en noindex