WordPress 7.2 adds a built-in /random/ URL. Visit example.com/random/ and WordPress sends the reader to a randomly chosen published post. The feature is on by default, and a developer note posted on November 5, 2026 explains how it works and how to switch it off.
This guide covers the URL patterns, which post types qualify, how to limit what gets picked, and how to disable it. Every detail comes from the official Your Content Is Going To Get More Random developer note, and the feature is in the 7.2 beta, not a final release.
What The Random URL Does
A request to /random/ redirects the visitor to one randomly selected published post. The note says it is built on the existing rewrite, WP and WP_Query APIs, so it behaves like other archive requests. The base word is translatable and can be changed with a new option on the Permalinks screen in wp-admin.
The URL Patterns
The random base is added in front of existing archive paths. With the default base and pretty permalinks, WordPress generates these rules:
| URL | Where it sends the visitor |
|---|---|
/random/ |
A random post |
/random/category/release/ |
A random post in that category |
/random/tag/dev-notes/ |
A random post with that tag. Any publicly queryable taxonomy on an eligible post type gets a similar rule |
/random/author/jorbin/ |
A random post by that author |
/random/{post-type-slug}/ |
A random post of a custom post type that is randomable |
Which Post Types Are Included
A new randomable argument on register_post_type() controls eligibility. If it is not set, it defaults to true for post types that are publicly_queryable and have has_archive set. Among the built-in types, posts are randomable, while pages and attachments are not.
To keep a custom post type out, set the argument to false when you register it:
register_post_type(
'musicals',
array(
'public' => true,
'has_archive' => true,
'randomable' => false, // Keep musicals out of /random/.
)
);Controlling What Gets Picked
The random post comes from the main query. During the request, WP::handle_random() adds three callbacks: wp_random_content_pre_get_posts() to restrict the query to eligible posts, wp_random_content_posts_orderby() to order by RAND(), and wp_random_content_post_limits() to return one row.
Because selection runs through the main query, any pre_get_posts callback that already customises an archive also affects its random redirect. To change only random requests, check the query with wp_is_random_content_query():
add_action(
'pre_get_posts',
static function ( WP_Query $query ) {
if ( wp_is_random_content_query( $query ) ) {
$query->set( 'category__not_in', array( 525600 ) );
}
}
);How To Turn It Off
Use the wp_enable_random_content_redirect filter. A one-line mu-plugin does it:
add_filter( 'wp_enable_random_content_redirect', '__return_false' );With the filter set to false, no random rewrite rules are generated, the random base field is hidden on the Permalinks screen, and the random query variable is ignored.
Also Read: WordPress 7.2 Guide for the rest of what is coming in this release.
What Site Owners Should Check
- Decide if you want it. It is on by default, so every site with posts gains a
/random/URL after upgrading. - Review excluded content. Posts you would not want surfaced at random, such as outdated announcements, need a category or query rule to exclude them.
- Check custom post types. Types with public archives become eligible unless you set
randomableto false. - Watch for conflicts. A site that already uses
/random/as a page or a custom rewrite should test the beta before 7.2 ships.
What This Doesn’t Cover
This guide does not test the feature on a live site, and it does not cover caching or SEO behaviour of the redirect, which the note does not discuss. The 7.2 beta can still change before release. For crawling and indexing basics, read the guides below.
