WordPress 7.2 Adds a /random/ URL: Check It, Turn It Off

WordPress 7.2 adds a new address to every site: /random/. Open it, and WordPress sends you to a random published post. It is switched on by default, and one line of code in a must-use plugin turns it off.

Here is the surprising bit. Nobody has to install anything for this URL to exist. Once a site runs 7.2, example.com/random/ just works, and so do versions for categories, tags, authors and some custom post types.

By the end of this guide you will know whether your site has the feature, what it can expose, and how to switch it off, rename it, or narrow it, with checks that prove it worked.

Heads up: at the time of writing (9 November 2026), WordPress 7.2 is still in beta. The final release is planned for 8 December 2026, and beta features can change before then. Treat everything here as "how it works in the beta" and check again after release.

What the /random/ URL actually is

The feature was announced on 5 November 2026 in the official Make WordPress Core post "Your Content Is Going To Get More Random!". It adds a /random/ endpoint that redirects to a randomly selected published post. A redirect simply means the server says "not here, go there instead", and the browser follows.

Think of it like a "surprise me" button in a music app, except that on your website anyone can press it, including bots, just by typing a URL.

The announcement lists these patterns:

• /random/ sends you to a random post.
• /random/category/{slug}/ sends you to a random post in one category, for example /random/category/news/.
• /random/tag/{slug}/ does the same for a tag. Other taxonomies on eligible post types get similar rules.
• /random/author/{name}/ sends you to a random post by one author.
• /random/{post-type-slug}/ sends you to a random item of a custom post type that is "randomable".

What a rewrite rule is, in plain words

WordPress does not keep a real folder called /random/ on your server. Instead it keeps a list of rewrite rules. A rewrite rule is a pattern that says "when someone asks for a URL that looks like this, run this kind of query". For example, a rule turns /category/news/ into "show posts in the news category".

WordPress 7.2 adds new rules for the /random/ patterns. WordPress stores the list of rules in the database and rebuilds it from time to time. Rebuilding the list is called flushing the rules. You will flush the rules later in this guide, so keep that word in mind.

Which content can show up

The announcement adds a new argument to register_post_type() called randomable. A post type is a kind of content, such as posts, pages, products or events. By default, randomable is true for post types that are publicly_queryable and have has_archive set.

For the built-in types, post is randomable, while page and attachment are not. So your normal blog posts are in, and your pages and media files are out.

Why this matters: custom post types come from your theme or plugins. If a plugin registers a public post type with an archive, it may be randomable without anyone deciding that on purpose. That is the main reason to check your own site instead of assuming.

Before you start

You need a little access and about 20 minutes. The risk is low, because the change is one small file you can delete again, but you should still work on a copy first.

• A staging copy of your site running WordPress 7.2 beta. If you do not have one yet, follow our guide to test the WordPress 7.2 beta on staging.
• A fresh backup of the site files and the database. Use your host's backup tool, or follow the official WordPress backup guidance. Back up both, because a file backup does not include the database.
• File access to the site: SFTP, SSH, or your host's file manager in the control panel.
• Optional but useful: WP-CLI, the command line tool for WordPress, available over SSH.
• An administrator login for wp-admin, so you can open the Permalinks screen.
• A terminal with curl, which is built into macOS, Linux and current Windows.

Quick tip: if you only manage a live site and have no staging copy, do the read-only checks in the next section first. They change nothing, and they tell you whether you need to act at all.

Check whether your site has the /random/ URL

Start by looking, not changing. These steps only read information.

Step 1: Check your WordPress version

The feature arrives in WordPress 7.2. If your site still runs 7.1, there is nothing to turn off yet.

This command prints the WordPress version of the site in the current folder:

wp core version

You should see a version number. If it starts with 7.2, the feature is on your site. Without WP-CLI, look at the bottom right of any wp-admin screen, or open Dashboard > Updates.

Step 2: Look for random rewrite rules

Next, ask WordPress which rewrite rules match a random URL. The --match option of wp rewrite list shows only rules that match a given URL, and the default columns are match, query and source.

This command lists any rules that match the /random/ path:

wp rewrite list --match=/random/

If the feature is active, look for one or more rows whose pattern starts with random. Heads up: I have not run this on a 7.2 beta site myself, so I cannot promise the exact text of those rows. Confirm what they look like on your own test site, and note it down so you can compare after you disable the feature.

You can also count the matching rules, which is handy for a before and after comparison:

wp rewrite list --match=/random/ --format=count

Step 3: Try the URL from outside

Now test it the way a visitor or bot would. The -I flag asks only for the response headers, so you see where the server sends you without downloading the page.

This command requests the random URL and prints the headers:

curl -I https://example.com/random/

When the feature is on, you should see a redirect status code (a number in the 300s) and a Location header that points to one of your posts. Run it two or three times. The Location should change between posts. The announcement does not say which exact redirect code is used, so check the number on your own site.

Then try the variants that matter for your site, such as /random/category/news/ or /random/{your-post-type}/. Use the real slugs from your site in place of the examples.

Decide what you actually want

You have more choices than "on" or "off". Pick the one that fits your site.

• Turn it off completely, if you do not want the feature at all.
• Rename the base, if you like the feature but want a different word in the URL.
• Keep it, but leave out certain content, such as one category or one post type.

Made-up example: Priya runs a small recipe blog plus a custom post type called client_menu that a plugin created for private catering menus. Those menus are public on the site but not linked anywhere. With /random/client_menu/ live, anyone who guesses the slug can now jump through them one by one. Priya keeps /random/ for recipes and removes the menus from it, or she turns the whole feature off.

Option A: Turn off /random/ with a must-use plugin

This is the cleanest fix, and it is the method the announcement itself suggests.

What a must-use plugin is

A must-use plugin, or mu-plugin, is a PHP file in the folder wp-content/mu-plugins. WordPress loads every PHP file placed directly in that folder, in alphabetical order, before normal plugins. It is always active.

You will see mu-plugins in a separate Must-Use section on the Plugins screen. You cannot disable them in wp-admin. You remove one by deleting its file. Files inside subfolders are not loaded on their own, so the file must sit at the top level of the folder.

Why this matters: a normal plugin can be switched off by accident, or by another admin. A mu-plugin stays on until someone removes the file, which is what you want for a site policy.

Step 1: Back up the mu-plugins folder

If wp-content/mu-plugins already exists, download a copy of it before you change anything. Your host may have placed its own files there. Do not edit or delete those.

If the folder does not exist, create it inside wp-content. The name must be exactly mu-plugins.

Step 2: Create the plugin file

Create a new file named disable-random-redirect.php directly inside wp-content/mu-plugins. In most host file managers you do this with File Manager > New File, then open the file with the built-in editor.

This file adds the filter from the official announcement, which switches the feature off:

<?php
/**
 * Plugin Name: Disable random content redirect
 * Description: Turns off the /random/ URL added in WordPress 7.2.
 */

add_filter( 'wp_enable_random_content_redirect', '__return_false' );

Save the file. The first line must be <?php with nothing before it, not even a blank line.

According to the announcement, with this filter in place no random rewrite rules are generated, the random base field is hidden on the Permalinks screen, and the random query variable is ignored. A query variable is a named value in a URL that WordPress reads, like ?s= for search.

Step 3: Flush the rewrite rules

The old random rules may still sit in the stored list until WordPress rebuilds it. Flushing removes any doubt.

This command rebuilds the rewrite rules in the database:

wp rewrite flush

You should see Success: Rewrite rules flushed.. The --hard option also updates the .htaccess file, and it only applies to single-site installs. You do not need --hard for this change.

No WP-CLI? Open Settings > Permalinks in wp-admin (the screen at wp-admin/options-permalink.php). The official documentation says that simply visiting this screen flushes the rewrite rules. You do not need to click Save Changes for the flush.

Step 4: Confirm it is listed

Go to Plugins > Installed Plugins and click the Must-Use link at the top. You should see "Disable random content redirect" in the list. If the Must-Use link is missing, WordPress did not find your file. Jump to the troubleshooting section.

Option B: Rename the random base

Maybe you like the feature but not the word. The announcement says the base is translatable and can be changed with a new option on wp-admin/options-permalink.php.

Open Settings > Permalinks, find the random base field, enter your new word, and click Save Changes. Then test the new URL with curl -I as in the checks above.

Heads up: renaming is not a privacy control. It only moves the door. Anyone who finds the new word can use it the same way. If you are worried about what content is reachable, use Option C or Option A instead.

Option C: Keep it, but leave some content out

This option needs a developer, or at least someone comfortable with PHP. The announcement explains that random requests use the main WordPress query. That means existing pre_get_posts callbacks also apply to random redirects. A pre_get_posts callback is a small function that changes which posts a query looks for before it runs.

Leave out a category

The announcement adds the helper wp_is_random_content_query(), which lets your code target only random requests and leave every other page alone.

This mu-plugin keeps posts in one category out of random redirects. Replace 123 with the ID of your category, which you can see in the URL when you edit the category in Posts > Categories:

<?php
/**
 * Plugin Name: Random redirect exclusions
 * Description: Keeps one category out of /random/ results.
 */

add_action(
	'pre_get_posts',
	static function ( WP_Query $query ) {
		if ( wp_is_random_content_query( $query ) ) {
			$query->set( 'category__not_in', array( 123 ) );
		}
	}
);

Save it as a separate file, for example wp-content/mu-plugins/random-exclusions.php. It is not needed if you use Option A.

Leave out a custom post type

If you or your developer register the post type in your own code, add 'randomable' => false to the arguments passed to register_post_type(). The announcement uses exactly this pattern for an example post type.

This snippet shows the idea for a made-up post type called musicals:

<?php
register_post_type(
	'musicals',
	array(
		'public'      => true,
		'has_archive' => true,
		'randomable'  => false, // Keep musicals out of /random/.
	)
);

If the post type comes from someone else's plugin, do not edit that plugin's files, because an update will overwrite your change. Ask the plugin author or a developer for the right way to adjust it, or use Option A.

How to check it worked

Run the same checks as before and compare the results.

1. Run wp rewrite list --match=/random/ --format=count. After Option A, the count should drop compared with your earlier result. Confirm the exact number on your test site.
2. Run curl -I https://example.com/random/ a few times. After Option A, you should no longer get a redirect to a random post. Most sites will show the same response they give for any unknown URL, usually a 404 status. Check what your theme returns.
3. Open https://example.com/random/ in a private browser window. You should see your normal "page not found" page, not a post.
4. Open Settings > Permalinks. After Option A, the random base field should be gone, as the announcement describes.
5. For Option C, run curl -I against /random/ ten or so times and check that no Location header points to the excluded category or post type.
6. Visit a normal post, a category page and the home page. They should load exactly as before.

When everything passes on staging, repeat the steps on the live site after a fresh backup.

Troubleshooting

/random/ still redirects after adding the mu-plugin

Symptom: curl -I still shows a redirect and a changing Location header. Likely causes: the file sits in a subfolder such as mu-plugins/random/, the name does not end in .php, or the old rules are still stored. Fix: move the file to the top level of wp-content/mu-plugins, check the name, then run wp rewrite flush or visit Settings > Permalinks.

It works in the browser but not with curl, or the other way round

Symptom: one test shows a redirect and the other does not. Likely cause: a page cache, a server cache or a CDN is serving an old response. Fix: purge the cache in your caching plugin, your host panel and your CDN, then test again in a private window.

White screen or "There has been a critical error on this website."

Symptom: the site breaks right after you save the file. Likely cause: a typo in the PHP, a missing <?php line, or curly "smart" quotes pasted from a word processor. Fix: delete or rename the file over SFTP or the file manager, and the site comes back. Then copy the code again from this page into a plain text editor.

"wp: command not found"

Symptom: the terminal does not know the wp command. Likely cause: WP-CLI is not installed or not on the path for your account. Fix: use the browser steps instead, visiting Settings > Permalinks to flush, or ask your host whether WP-CLI is available under another name.

"You should update your .htaccess now."

Symptom: this message appears at the top of the Permalinks screen after you save. Likely cause: WordPress cannot write to the .htaccess file. Fix: copy the rules from the text box at the bottom of the screen into .htaccess by hand, as the official documentation describes. This is about your permalink settings in general, not the mu-plugin.

wp rewrite flush --hard does nothing on multisite

Symptom: you ran the command with --hard on a network and .htaccess did not change. Likely cause: the --hard option only applies to single-site installs. Fix: a normal wp rewrite flush is enough for this change. Leave .htaccess on multisite to your host or developer.

Your version shows 7.1 and there are no random rules

Symptom: wp rewrite list --match=/random/ returns nothing. Likely cause: the site does not run 7.2 yet. Fix: nothing to do today. You can still add the mu-plugin now, so it is ready when the site updates. A filter for a feature that does not exist yet simply does nothing.

Pro tips and when to ask for help

Quick tip: add a short comment at the top of your mu-plugin saying who added it and why. Mu-plugins get no update notices and stay hidden from the main plugin list, so the next person may not know it exists.

Watch the release. Because this is a beta feature, the filter name or behaviour may change before 8 December 2026. After 7.2 is final, run the checks in "How to check it worked" once more. If your site updates itself, it is worth knowing whether your WordPress auto-updates really run, so the update does not surprise you.

You may see comments under the announcement about database load, search engine indexing and content exposure. Those are unofficial, unconfirmed views from commenters, not statements from the WordPress core team. If speed or indexing matters a lot for your site, test on staging and decide for yourself.

While you are in the habit of small hardening files, look at locking file edits in wp-config.php too. It pairs well with a mu-plugin you want to keep exactly as written.

Ask a developer when your site has many custom post types, when you want rules that differ per post type, or when a plugin's content shows up in random results and you are not sure why.

The one message worth forwarding

Copy this and send it to your developer or host:

"Hi, WordPress 7.2 (final planned for 8 December 2026) adds a /random/ URL that is on by default and redirects visitors to a random published post, with versions for categories, tags, authors and randomable custom post types. We would like to [turn it off / keep it but exclude some content]. The official fix is a mu-plugin with add_filter( 'wp_enable_random_content_redirect', '__return_false' ); followed by a rewrite flush. Could you add this on staging first, confirm with wp rewrite list --match=/random/ and curl -I that /random/ no longer redirects, then apply it to the live site after a backup? Source: the Make WordPress Core post from 5 November 2026, Trac ticket #64498."

The short version: check /random/ on a staging copy today, decide whether you want it, and if not, one small mu-plugin file and a rewrite flush turn it off.