WordPress 7.2 is set to introduce a new /random/ endpoint that will redirect visitors to a randomly selected published post. Enabled by default, the feature will also support random discovery within categories, tags, author archives, and eligible custom post types. Admins will be able to customize the random URL base, control which post types are included, or disable the feature entirely.
The addition has received largely negative feedback from the community, with several contributors questioning the decision to include the feature in WordPress core and enable it by default. Some have argued that it would be better suited to a plugin, while others have raised concerns about its suitability for different types of WordPress sites. Aaron Jorbin, who announced the feature, has defended its inclusion, arguing that it would help people discover content.
How the /random/ endpoint feature was developed and how it works
The development of the feature can be traced to a Trac ticket opened by Anne McCarthy 10 months ago, which proposed adding support for random content redirects to WordPress core. The ticket noted that similar functionality was already available through plugins and custom code and suggested discussing a minimal implementation using existing query and rewrite APIs. McCarthy also highlighted an earlier request from Matt Mullenweg to consider the feature for WordPress 7.0, based on his Random Redirect plugin.
The discussion also raised questions about whether the feature met WordPress’ 80% rule, which states that core should provide features that at least 80% of users will appreciate and use. Core Committer John Billion questioned the decision to include the functionality in core rather than develop it as a featured canonical plugin, “ If this feature is disabled by default and requires a plugin be active to enable it, it doesn’t seem to fit the 80% rule. What’s the benefit of this feature being in core as opposed to resurrecting the Random Redirect plugin and making it a featured canonical pluign? “
Responding to the question, Anne McCarthy clarified that Matt had specifically requested its inclusion in core, “Hey folks. As noted in the issue description, Matt requested this in Core. That’s the root of why this is being added and why it’s not being pursued as a canonical plugin. It was explicitly asked by him (multiple times).”
Jorbin explained how the endpoint would work and outlined the options available to site owners. He described the feature as being built on WordPress’ existing rewrite, WP, and WP_Query APIs, and noted that the random URL base could be customized through a new option on the permalink settings page.
A new randomable argument in register_post_type() determines which post types are eligible. By default, post types that are publicly queryable and have has_archive enabled qualify, while built-in post types such as pages and attachments are excluded.
Jorbin also explained that random selections run through the main query, meaning existing pre_get_posts callbacks that modify archive queries will also apply to random redirects. Site owners can use wp_is_random_content_query() to target these requests specifically.
Addressing the option to disable the feature, he wrote, “If you have a legitimate reason to not support this on a site, or you simply hate fun, there is a filter to disable this entire feature.” The wp_enable_random_content_redirect filter prevents random rewrite rules from being generated, hides the random base option from the permalink settings screen, and causes the random query variable to be ignored.
Admins who prefer not to use the feature can disable it by adding add_filter( ‘wp_enable_random_content_redirect’, ‘__return_false’ ); to a must-use plugin. This prevents WordPress from generating random rewrite rules, hides the random base field from the permalink settings page, and causes the random query variable to be ignored.
Community raises concerns over the feature
Mike N Garrett said it could create additional work for those managing non-blog websites. Aaron Jorbin defended the approach by referring to the WordPress Philosophies, which do not support adding opt-out settings for every feature. David E. Smith challenged this reasoning, arguing that core features should benefit the vast majority of users and that this one belonged in a plugin.
Olli Kousa, who manages more than 100 WordPress websites, mostly ecommerce and business sites, warned that the endpoint could expose custom post type content that was never intended for public discovery. Joost de Valk raised similar concerns, pointing to the possibility of exposing invoices, offers and client-specific pages, particularly without noindex support.
Performance concerns also emerged. Ryan McCue questioned the use of ORDER BY RAND(), while Rene Hermenau tested the endpoint with up to two million posts and reported response times of 1.87 seconds. He also found that 20 simultaneous requests took 14 seconds to complete.
Arūnas Liuiza strongly opposed adding the feature to WordPress Core, writing: “If this gets released in Core, we can count this as the beginning of the end.”
Ross Morsali questioned whether misconfigured sites could unintentionally expose pages that administrators did not expect to make accessible. “ And how many websites that are misconfigured are going expose pages they didn’t think they were showing? (sure thats kind of a “them” problem, but still)”
Mark Jansen questioned why the feature was being added to WordPress Core, arguing that it would make more sense as a plugin , “ Why on earth would we want this in #WordPress core? I mean, some one creating a plugin for this, sure. If you have the website for it, fun. Great. But in core? Why?”
Matt ‘TK’ Taylor (Senior Product Manager at Cloudflare) compared WordPress’s approach with EmDash, saying, it would not add a /random endpoint that users had to opt out of, and described EmDash as “a serious CMS.”
Alex Standiford said the feature would require him to add another filter to every site he maintains, “ Cool, I guess I now get to add another filter to every site I maintain because this feature, which most definitely should just be a canonical plugin at best, is going to be added to WordPress core.”