Skip to content

Personal support from Ostend   support@kyzoe.be   +32 59 53 00 00

Knowledge base   Blog   Server status   Client areaNLENFR

WordPress 7.2 turns on the /random/ URL by default on December 8

WordPress 7.2 /random/: random content, new considerations

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 is on December 8.

How /random/ works

With pretty permalinks enabled, /random/ pick any eligible post. There are archive variants,/random/author/{name}/ and /random/{post-type}/ therandom 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() a one-row limit. Any pre_get_posts callbacks the site already has also apply to it.

To turn it off, the 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 are 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 you do not need the feature, 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/.

What is still open

The note does not state the redirect status code, the cache headers, whether the response carries noindex, or whether it /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.

Read also

Need help with your website or hosting?

Ask your question, we will help you personally.

Contact us
View the plans
EN