WordPress 7.2 Adds a /random/ URL: What It Exposes and How to Turn It Off

WordPress 7.2 adds a new URL to every site: /random/. Visit it and WordPress sends you to a random published post. It is on by default, so your site gets it the moment you update, whether you want it or not.

For a blog, that can be a nice way to surface old posts. For a business site, a store, or any site with content you never meant to list, it is a new door you should check.

I installed the 7.2 beta on a test site and tested it with Polylang, WooCommerce, a page cache, and up to 250,000 posts. This guide covers what the URL does, what I found, and how to turn it off or limit it.

Skip to how to turn it off

What the /random/ URL does

A request to /random/ runs a normal WordPress query, picks one post at random, and answers with a 302 redirect to that post. Core calls it “random content redirects,” introduced in the WordPress 7.2 dev note.

It is not just one URL. The random base can sit in front of most archive types, and the ?random query string works on any archive or search URL.

Every redirect I captured carried the same headers:

HTTP/1.1 302 Found
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Cache-Control: no-cache, must-revalidate, max-age=0, no-store, private
X-Robots-Tag: noindex, follow
Location: https://example.com/some-post/

A few more rules, each confirmed on the test site:

• Only GET and HEAD requests redirect. A POST to /random/ got the normal home page.
• Feeds and single posts are never random. /feed/?random returned the normal feed.
• An empty archive returns a 404.
• The value is ignored: ?random=0 still redirects.
• The base word is translatable, and you can change it under Settings > Permalinks in the new “Random base” field.

What the /random/ URL can expose

The key question is which posts are eligible. A post type joins through a new randomable argument on register_post_type(). If a post type does not set it, WordPress turns it on when the post type is publicly queryable and has an archive.

In core, post is randomable, while page and attachment are not. Any custom post type registered with has_archive joins automatically, including the ones your plugins register.

On this blog, the snippets and case studies post types both have archives. Once the site is on 7.2, each will get its own random URL without me changing a line of code.

Inside an eligible post type, the rule is short:

Only randomable post types and published posts without a password are eligible. – WordPress 7.2 core, wp-includes/query.php

I tested that rule with 200 requests. A password-protected post and a private post were never picked. Everything else that is published is fair game, and that includes content you may have assumed was hidden:

• Posts set to noindex in your SEO plugin. The redirect does not read SEO settings.
• Posts you hide from the blog page inside a template, not in the query. The random query never runs your template.
• “Unlisted” items in a custom post type, such as landing pages or thank-you pages that are only reachable by a direct link.

None of this leaks private data. It does let any visitor, or any bot, walk through published content you never linked to. If a page must stay hidden, it should be a draft, private, or password protected, not just unlinked.

What I found testing it

The test site ran WordPress 7.2-beta4-65325 on PHP 8.3 and MySQL 8.0, with Polylang 3.9.1, WooCommerce 11.2.2, and WP Super Cache 3.1.5. Most results below come from 20 to 200 requests to the same URL.

One rule explains most of what I saw. The random pick runs the same main query as the normal archive, so it can only land on posts that archive would list. Plugins that filter archives, such as WooCommerce and Polylang, also filter the random pick.

Multilingual sites: English has no /random/ URL

I set up Polylang the way this blog runs: Hebrew as the default language at the root, English under /en/. Polylang does not add a language prefix to the new rules, and that splits the languages:

The language filter is correct: no request ever crossed languages. The problem is that only the default language gets a pretty /random/ URL. For the other languages, link to /en/?random, or add the prefixed rule yourself:

add_action( 'init', function () {
    if ( ! function_exists( 'pll_languages_list' ) || ! function_exists( 'wp_is_random_content_redirect_enabled' ) || ! wp_is_random_content_redirect_enabled() ) {
        return;
    }
    foreach ( pll_languages_list() as $lang ) {
        if ( $lang === pll_default_language() ) {
            continue; // The default language already uses /random/.
        }
        add_rewrite_rule( "^{$lang}/random/?$", "index.php?lang={$lang}&random=1", 'top' );
    }
} );

After a rewrite flush, /en/random/ sent all 30 test requests to English posts, and /random/ stayed Hebrew. I tested this only with the default language hidden from the URL. I did not test WPML.

WooCommerce: products join, hidden products stay hidden

WooCommerce registers products with an archive (the shop page), so products are randomable by default. After the update, these rules appeared with no setup:

random/shop/?$                   index.php?post_type=product&random=1
random/product-category/(.+?)/?$ index.php?product_cat=$matches[1]&random=1
random/product-tag/([^/]+)/?$    index.php?product_tag=$matches[1]&random=1
random/brand/(.+?)/?$            index.php?product_brand=$matches[1]&random=1

WooCommerce’s own catalog rules held. In 80 requests to /random/shop/, a product with catalog visibility set to “Hidden” was never picked. Neither was an out-of-stock product with “Hide out of stock items” turned on, nor a private or draft product.

A product set to “Search results only” did appear, but only through a search URL with ?random, in 10 of 80 requests. That matches what the search page itself would list.

Performance: the query grows, the request stays uncached

To test scale, I filled the test site with posts of about 18 KB each, the average post size on this blog. The query time is the random SELECT as WordPress logged it. The request times are the median time to first byte, with no page cache.

The query uses ORDER BY RAND(), the same ordering behind the random product sorting snippet for WooCommerce, and its cost grows roughly in line with the post count. WordPress keeps it cheaper than it sounds: it sorts only post IDs, then loads the one winning post.

The full request was never slower than an uncached home page, because it redirects before any template loads. The real cost is caching. Your home page is usually served from a page cache in a few milliseconds, while every /random/ hit runs PHP and the database.

Caching: WP Super Cache left it alone

With WP Super Cache serving cached pages, /random/ and /?random still redirected to a different post on each request. No cache file was written for them, even with the home page already cached.

I could not test a CDN. The no-store header tells a CDN not to cache the redirect. But if your CDN has a rule that overrides origin headers and caches everything, check it with the steps at the end of this guide.

How to turn off or restrict the /random/ URL

You have four options, from removing the feature entirely to keeping it with tighter rules. I ran every snippet below on the test site. Each one is also safe to add before you update: on WordPress 7.1 the filter has no effect, and the function_exists() guard skips the code.

Turn it off completely

One filter removes the feature. With it, WordPress generates no random rewrite rules, ignores the random query variable, and hides the “Random base” field. Put it in a small must-use plugin so a theme switch cannot undo it:

<?php
/**
 * Plugin Name: Disable Random Content Redirects
 */
add_filter( 'wp_enable_random_content_redirect', '__return_false' );

Save it as wp-content/mu-plugins/disable-random-redirects.php, then flush the rewrite rules. On the test site, /random/ and its variants then returned a 404, and /?random showed the normal home page.

Keep it, but leave a post type out

For your own post types, pass 'randomable' => false to register_post_type(). For post types a plugin registers, change the arguments with the register_post_type_args filter:

add_filter( 'register_post_type_args', function ( $args, $post_type ) {
    if ( in_array( $post_type, array( 'landing_page', 'product' ), true ) ) {
        $args['randomable'] = false;
    }
    return $args;
}, 10, 2 );

Replace the names in the array with your own post types. To see which post types are randomable, run this before and after:

wp eval 'print_r( get_post_types( array( "randomable" => true ) ) );'

With WooCommerce active, the list dropped from post and product to post alone. After the flush, /random/shop/ sent a 301 to /shop/.

Keep it, but exclude some posts

The random pick runs through the main query, so pre_get_posts applies to it. Core adds a helper, wp_is_random_content_query(), that targets only random requests. If you have not used this hook before, start with how to modify the WordPress loop with pre_get_posts.

This example skips one category and every post set to noindex in Yoast SEO, where a value of 1 means noindex:

add_action( 'pre_get_posts', function ( $query ) {
    if ( ! function_exists( 'wp_is_random_content_query' ) || ! wp_is_random_content_query( $query ) ) {
        return;
    }

    // Skip a category by ID.
    $query->set( 'category__not_in', array( 12 ) );

    // Skip posts set to noindex in Yoast SEO.
    $query->set( 'meta_query', array(
        'relation' => 'OR',
        array( 'key' => '_yoast_wpseo_meta-robots-noindex', 'compare' => 'NOT EXISTS' ),
        array( 'key' => '_yoast_wpseo_meta-robots-noindex', 'value' => '1', 'compare' => '!=' ),
    ) );
} );

To test it, I marked 10% of 250,000 posts as noindex. Without the snippet, 7 of 60 picks were noindex posts. With it, none were.

The exclusion has a cost. The meta join raised the random query from about 112 ms to about 300 ms at 250,000 posts. On a site with a few thousand posts, the difference is a few milliseconds.

Core sets the post types, status, order, and limit at a later priority, so your conditions stay in place. Keep in mind that a post type set to noindex as a whole in Yoast’s settings stores nothing per post. Leave that post type out with the previous snippet instead.

Move or take over the /random/ URL

If /random/ clashes with a page or campaign you already run, you do not need code. A published page at that slug wins over the redirect, and the “Random base” field under Settings > Permalinks moves the whole feature to another word.

In my test, WordPress updated the rules on its own when I published and deleted that page. The page only took over /random/ itself: /random/author/admin/ kept redirecting while it existed.

Check the result

After you update, list the rules WordPress registered, then test the URL from the outside:

wp rewrite list --match=/random/

curl -sI https://example.com/random/ | grep -iE "^(HTTP|location|cache-control|x-robots-tag|cf-cache-status)"

Run the curl line two or three times. With the feature on, you should see a 302, a different location on most runs, and no-store in cache-control.

If the location never changes or Cloudflare reports HIT, your CDN is caching the redirect. Add a bypass rule for the random URLs. With the feature off, /random/ returns a 404.

Should you turn it off?

I would keep it only on a content site where a “random post” link is a real feature for readers. Everywhere else, I would turn it off or limit it before updating:

• Stores: turn it off, or remove product. Your catalog rules still apply, but the shop gains four new uncached URL patterns nobody asked for.
• Business sites with custom post types: list what is randomable and remove anything that is not meant to be browsed.
• Blogs: keep it if you plan to link to it, and exclude noindex or thin posts.
• Multilingual sites: only the default language gets /random/. Add the prefixed rule above, or link to ?random on each language’s home page.

The feature is tracked in Trac ticket #64498. The dev note drew a long, critical comment thread, with several commenters asking for it to be opt-in. Watch both before the final release.

FAQs

Common questions about the WordPress 7.2 random content redirects:

Summary

WordPress 7.2 adds /random/ to every site by default. It redirects to a random published post from any randomable post type, and custom post types with an archive, including WooCommerce products, join automatically.

In testing, it followed each archive’s own rules, skipped private and hidden content, and stayed out of the page cache. Its gaps are multilingual URLs and noindex posts. Check what is randomable before you update, then turn it off or limit it, and flush the rewrite rules after any change.