Drupal 11.4 bloque les URL de recherche dans robots.txt : le détail
Drupal 11.4 est sorti le 1er juillet 2026, et les gros titres sont allés à la performance. Normal — les chiffres sont spectaculaires. Mais entre eux se cache un changement de deux lignes dans un fichier que la plupart des équipes ne regardent jamais, et c’est LE point que chaque propriétaire de site Drupal devrait vérifier ce mois-ci. Joli hasard : les deux histoires parlent de requêtes — celles que les robots envoient, et celles auxquelles votre base de données répond.
Le changement : les pages de résultats de recherche à paramètres sont bloquées
Le robots.txt par défaut de Drupal core embarque désormais ces règles supplémentaires :
Disallow: /search?
Disallow: /index.php/search?Toute URL de recherche core portant une chaîne de requête — /search?keys=expert+drupal, plus chaque combinaison
de pagination, de tri et de filtre qui s’y accroche — n’est plus explorable par les robots bien élevés.
Pourquoi core l’a fait
Les pages de résultats de recherche sont un piège à crawlers : chaque mot-clé, chaque page, chaque paramètre frappe une nouvelle URL, et les robots s’engouffrent dans un espace d’URL infini de pages minces et quasi identiques. C’est du budget de crawl brûlé au détriment de vos vrais contenus, de la charge serveur pour zéro valeur SEO — et le problème a pris de l’ampleur à l’ère des crawlers IA, qui martèlent précisément ce type d’URL paramétrées. Bloquer la recherche interne est une bonne pratique SEO depuis des années (c’est l’une des premières choses que je corrige en audit technique) ; avec 11.4, core en fait enfin le comportement par défaut.
Ce que ça ne fait pas
Trois nuances qui comptent avant de s’y fier :
- Bloquer le crawl n’est pas désindexer. Les URL déjà dans l’index de Google peuvent y traîner en « indexée
malgré le blocage par robots.txt ». Si des URL de recherche polluent votre index aujourd’hui, il faut d’abord un
meta
noindexsur ces pages (laissez Google recrawler et les retirer), puis le blocage robots.txt en régime de croisière. - Seul
/searchest couvert. Une recherche custom en Views sur/find, un chemin traduit comme/recherche, ou une page Search API sur/search/siteavec ses propres paramètres ne sont pas couverts — répliquez le motif pour vos propres routes. - La recherche à facettes mérite une décision, pas un défaut. Si vos URL de facettes font partie de votre stratégie SEO (des pages catégorie + filtre qui rapportent du trafic), ne les bloquez pas en bloc — choisissez délibérément quelles combinaisons de paramètres ont le droit de vivre. C’est exactement le genre d’arbitrage réglé sur la recherche Solr de DOGA.
Qui doit agir manuellement
C’est le piège de cette version : les nouvelles règles n’arrivent pas automatiquement partout.
| Votre configuration | Ce qui se passe à la mise à jour |
|---|---|
robots.txt d’origine, scaffold Composer actif |
Le fichier est re-généré — vous recevez les règles gratuitement |
robots.txt personnalisé (exclu du scaffold) |
Rien ne change — ajoutez les deux règles vous-même |
| Module RobotsTxt (fichier servi depuis la base) | Rien ne change — ajoutez les règles dans sa configuration |
| Fichier personnalisé, scaffold non exclu | Danger inverse : la mise à jour peut écraser vos personnalisations — diffez après la montée |
La vérification en deux minutes, tout de suite :
curl -s https://votre-site.example/robots.txt | grep 'search?'Aucun résultat sur un site en 11.4 = vous êtes dans un des cas manuels. Pendant que vous y êtes, regardez dans
Search Console la part du budget de crawl qui part aujourd’hui vers /search? — ce chiffre sera votre preuve
avant/après.
Les autres requêtes : le régime performance de 11.4
La même version taille dans les requêtes côté interne :
- Moitié moins de requêtes SQL qu’en 11.3 sur un large éventail de pages, grâce aux optimisations du chargement des champs d’entités — et à peine un tiers des accès comparé à Drupal 11.0/10.6 sur cache froid.
- Moins de jointures dans les listes d’entités, au bénéfice notamment de JSON:API — pertinent si vous faites tourner un front découplé.
- Compression Brotli des agrégats CSS/JS (15 à 25 % plus compacts que gzip ; nécessite l’extension PHP Brotli) — un gain direct pour les Core Web Vitals.
- Réponses 404 cachables — le cousin discret du changement robots.txt : les rafales de robots sur des URL mortes ne traversent plus jusqu’à PHP à chaque coup.
- La vérification des traductions est 87 % plus rapide, et la branche 11.4.x est supportée en sécurité jusqu’en juin 2027.
À retenir
Montez en 11.4 pour la performance, puis accordez dix minutes à la vérification robots.txt ci-dessus — c’est la rare amélioration SEO livrée dans core qui demande quand même vos yeux si votre fichier est personnalisé. Et si vous lisez ceci depuis un site Drupal 10 : 11.4 est ce qui vous manque, et le compte à rebours se termine le 9 décembre 2026.
Pas certain que vos URL de recherche, vos facettes et votre budget de crawl soient configurés par choix plutôt que par accident ? C’est un audit d’une journée.