Une note aux développeurs publiée par l’équipe core de WordPress le 5 novembre 2026 décrit une nouvelle fonctionnalité de la version 7.2 : l’URL /random/, qui redirige le visiteur vers un article publié choisi au hasard. La note précise que la fonctionnalité est activée par défaut (« the feature is on by default »). La version 7.2 en est à la bêta 5 depuis le 10 novembre, la première release candidate (RC1) est prévue pour le 17 novembre et la version finale pour le 8 décembre.
Comment fonctionne /random/
Lorsque les permaliens lisibles sont activés, /random/ choisit n’importe quel article éligible. Il existe des variantes par archive : /random/category/{slug}/, /random/tag/{slug}/, /random/author/{nom}/ et /random/{post-type}/. Le segment random est traduisible et peut être modifié sur l’écran des permaliens.
Les types de contenu publics dotés d’une page d’archive participent au tirage, ce que contrôle le nouvel argument randomable de register_post_type(). Les articles en font partie ; les pages et les fichiers joints, non. Un type personnalisé enregistré par une extension ou un thème, comme des témoignages ou des éléments de portfolio, est inclus automatiquement s’il possède une archive publique.
Le tirage exécute la requête principale avec ORDER BY RAND() et une limite d’une seule ligne. Les callbacks pre_get_posts déjà présents sur le site s’y appliquent également.
Pour la désactiver, le core fournit un filtre :
add_filter( 'wp_enable_random_content_redirect', '__return_false' );
Avec ce filtre, les règles de réécriture de /random/ ne sont plus générées et la variable de requête est ignorée.
Qui doit vérifier avant la mise à jour
Le premier groupe est celui des sites comptant beaucoup d’articles. ORDER BY RAND() oblige MySQL à parcourir et à trier la table à chaque requête. Dans les commentaires de la note, un participant a mesuré environ 24 ms avec 50 000 articles et 1,87 s avec 2 millions, sur une machine locale rapide. Comme cette URL ne peut pas être servie depuis le cache de la manière habituelle, chaque robot qui la visite déclenche une nouvelle requête en base de données. Aaron Jorbin, l’auteur de la note, a ouvert un ticket pour étudier des améliorations de performance.
Le deuxième groupe comprend tous ceux qui utilisent un cache de page complète ou un CDN. Un commentaire a signalé un cas où la réponse revenait avec un statut 200, sans en-têtes no-cache ni noindex. Dans cette situation, le cache enregistre le premier tirage et le sert à tout le monde. Jorbin a répondu que l’absence de ces en-têtes est un bug qui mérite un ticket.
Le troisième groupe est celui des sites dont certains types de contenu n’ont jamais été conçus pour être lus isolément. Avec la règle par défaut, ces éléments reçoivent un point d’entrée public que le propriétaire du site n’a pas demandé.
Les agences et les équipes qui gèrent de nombreux sites WordPress sont concernées par les trois cas, car elles doivent soit décider site par site, soit appliquer une même règle partout.
Que faire avant le 8 décembre
À partir de la RC1, le 17 novembre, vous pouvez tester le comportement réel sur une copie du site : ouvrez /random/, vérifiez le code de statut et les en-têtes de la réponse, et regardez ce que le cache ou le CDN enregistre.
Si vous n’avez pas besoin de la fonctionnalité, le plus simple est de la désactiver avant la mise à jour, avec le filtre placé dans un mu-plugin (une extension « must-use », chargée sans devoir être activée dans le tableau de bord). Si elle vous est utile, passez 'randomable' => false aux types de contenu qui doivent rester hors du tirage et surveillez dans les journaux du serveur le nombre de requêtes qui atteignent /random/.
Ce qui reste ouvert
La note n’indique ni le code de statut de la redirection, ni les en-têtes de cache, ni si la réponse porte un noindex, ni si /random/ est exclue du sitemap. Elle ne dit pas non plus ce qu’il advient des articles marqués noindex par les extensions SEO.
Les commentaires de la note sont en grande majorité opposés à l’activation par défaut, et plusieurs demandent que la fonctionnalité soit retirée ou déplacée dans une extension. Au 11 novembre, la note ne faisait état d’aucune décision de modifier le réglage par défaut avant la 7.2. Si le comportement change, cela devrait apparaître dans la RC1 ou dans les RC suivantes, prévues pour le 24 novembre et le 1er décembre.
À lire aussi
Black Friday : comment préparer votre site à l’affluence
Le jour du Black Friday, votre site reçoit beaucoup plus de visiteurs en peu de temps. Avec le cache, des pages allégées…
Lire la suiteNovamira : un agent IA directement dans votre site WordPress
Avec Novamira, un agent IA comme Claude ou Cursor travaille directement dans WordPress. Ce qu’il sait faire, ce qu’apporte Pro, comment l’utiliser…
Lire la suiteExtension WordPress gratuite : vérification de l’âge pour votre site d’alcool (conforme au RGPD)
Vous vendez du vin, de la bière, du whisky ou d’autres boissons alcoolisées sur votre site web ? En Belgique (et dans…
Lire la suite

