A developer note published by the WordPress core team on November 5, 2026 describes a new feature in version 7.2: the /random/ URL, which redirects the visitor to a published post chosen at random. The note says "the feature is on by default." 7.2 has been at beta 5 since November 10, the first release candidate (RC1) is scheduled for November 17, and the final release for December 8.
How /random/ works
With pretty permalinks enabled, /random/ picks any eligible post. There are archive variants: /random/category/{slug}/, /random/tag/{slug}/, /random/author/{name}/ and /random/{post-type}/. The random segment is translatable and can be changed on the permalinks screen.
Public content types with an archive page are included in the draw, controlled by the new randomable argument of register_post_type(). Posts are in; pages and attachments are out. A custom type registered by a plugin or theme, such as testimonials or portfolio items, is included automatically if it has a public archive.
The draw runs the main query with ORDER BY RAND() and a one-row limit. Any pre_get_posts callbacks the site already has also apply to it.
To turn it off, core provides a filter:
add_filter( 'wp_enable_random_content_redirect', '__return_false' );With it, the /random/ rewrite rules are no longer generated and the query variable is ignored.
Who should check before updating
The first group is sites with many posts. ORDER BY RAND() makes MySQL scan and sort the table on every request. In the comments on the note, one participant measured about 24 ms with 50,000 posts and 1.87 s with 2 million, on a fast local machine. Because this URL cannot be served from cache in the usual way, every bot that visits it triggers a new database query. Aaron Jorbin, who wrote the note, opened a ticket to look into performance improvements.
The second group is anyone using full-page caching or a CDN. One comment reported a case where the response came back as a 200 with no no-cache or noindex headers. In that situation, the cache stores the first draw and serves it to everyone. Jorbin replied that the missing headers are a bug worth a ticket.
The third is sites with content types that were never meant to be read on their own. Under the default rule, those items get a public entry point the site owner did not ask for.
Agencies and teams that maintain many WordPress sites face all three, because they have to decide site by site or apply one rule everywhere.
What to do before December 8
From RC1 on November 17, you can test the real behavior on a copy of the site: open /random/, check the response status and headers, and see what the cache or CDN stores.
If the feature does not serve the product, the simplest path is to turn it off with the filter in a mu-plugin (a must-use plugin, which loads without being activated in the dashboard) before updating. If the feature is useful, pass 'randomable' => false to the content types that should stay out of the draw and watch the server logs for how many requests reach /random/.
Anyone who applies major versions automatically, through their own configuration or their host's, should review this before December 8. For everyone else, choosing between updating on release day and waiting for a fix release follows the same reasoning as a supported version still calls for a migration decision: 7.1 keeps receiving security fixes, so waiting a few weeks costs little.
What is still open
The note does not state the redirect status code, the cache headers, whether the response carries noindex, or whether /random/ is kept out of the sitemap. It also does not say what happens to posts marked noindex by SEO plugins.
The comments on the note are largely against having the feature on by default, and several ask for it to be reverted or moved to a plugin. As of November 11, the post recorded no decision to change the default before 7.2. If the behavior changes, it should show up in RC1 or in the later RCs, scheduled for November 24 and December 1.
If your company is weighing something similar, reach me on LinkedIn or WhatsApp.
