WordPress 7.2では/random/がデフォルトで有効になる
WordPress 7.2では、サイトのURLに/random/を付けてアクセスすると、公開済みの投稿の中からランダムに選ばれた1件へリダイレクトされる機能が加わります。Make WordPress Coreの開発者向けノート（2026年11月5日、Aaron Jorbin氏）で解説されました。この機能はデフォルトで有効で、既存のリライト、WP、WP_Queryの各APIの上に作られています。7.2の最終リリースは2026年12月8日の予定です（WordPress.orgのBeta 4告知による）。
サイト運営者にとっては、何もしなくてもexample.com/random/が使えるようになる、というのが大きな変化です。逆に、ランダムなURLを公開したくないサイトでは、対応を入れる必要があります。
どんなURLが生成されるか
開発者ノートによると、randomという接頭辞が既存のアーカイブのパスの前に付きます。デフォルトの接頭辞で、パーマリンクをpretty permalinks（見た目のよいURL）にしている場合は、次のルールが生成されます。
/random/：ランダムな投稿へ/random/category/release/：releaseカテゴリのランダムな投稿へ/random/tag/dev-note/：ランダム対象の投稿タイプに紐づく、公開クエリ可能なタクソノミーにも同様のルールが付く（タグの例）/random/author/jorbin/：その投稿者のランダムな投稿へ/random/{投稿タイプのスラッグ}/：ランダム対象のカスタム投稿タイプのランダムな投稿へ
接頭辞（デフォルトはrandom）は翻訳可能で、wp-admin/options-permalink.phpの新しい項目から変更できます。
対象になる投稿タイプは「randomable」で決まる
register_post_type()に新しい引数randomableが加わります。指定しない場合は、publicly_queryableで、かつhas_archiveが設定されている投稿タイプでtrueになります（ノートの記述）。組み込みの投稿タイプではpostが対象で、pageとattachmentは対象外です。
カスタム投稿タイプを/random/に出したくない場合は、登録時に'randomable' => falseを渡します。ノートの例では、musicalsというカスタム投稿タイプで'public' => true、'has_archive' => trueのまま、'randomable' => falseを指定して除外しています。たとえば会員向けの案内やFAQのように、ランダムに見せる意味の薄いカスタム投稿タイプでも、公開クエリ可能でアーカイブを有効にしていればデフォルトで対象になります（これは筆者の例示です）。
メインクエリを通るので、既存のpre_get_postsが効く
ランダムな投稿は、メインクエリで選ばれます。WP::handle_random()が、リクエストの間だけ3つのコールバックを追加してメインクエリを実行します。pre_get_postsにwp_random_content_pre_get_posts()、posts_orderbyにwp_random_content_posts_orderby()、post_limitsにwp_random_content_post_limits()です。これらによって、対象の投稿に絞り込み、RAND()で並べ替え、結果を1件に制限します。
ここで押さえておきたいのは、アーカイブを調整している既存のpre_get_postsのコールバックが、そのアーカイブのランダムなリダイレクトにも適用されることです。たとえばカテゴリアーカイブから特定の投稿を除外するコードがあれば、/random/category/…でもその除外が効きます。ランダムなリクエストのときだけ選択を変えたい場合は、wp_is_random_content_query()で判定できます。ノートの例では、その場合にだけcategory__not_inへカテゴリID 525600を渡して除外しています。
無効にしたいサイトの対応
機能全体を止めるには、wp_enable_random_content_redirectフィルターでfalseを返します。mu-pluginにadd_filter( 'wp_enable_random_content_redirect', '__return_false' );と書けば、ランダムのリライトルールは生成されず、パーマリンク画面のランダム用の接頭辞の欄は非表示になり、ランダム用のクエリ変数も無視されます。
なお、ノートのコメント欄では、機能への懸念がいくつも出ています。ORDER BY RAND()は件数に比例して遅くなる（O(N)）ため、ボットが/random/に繰り返しアクセスすると負荷になるという指摘や、公開する想定のなかった投稿タイプが露出するという指摘、noindexの仕組みがコアにないという指摘です。ベンチマークを示したコメントでは、200万件規模のサイトで、同時20リクエストが完了するまで14秒かかったとされています。別のホストのパーマリンクの場合はリダイレクトされず、no-cacheとnoindexのヘッダーのない通常の200応答になるため、ページキャッシュに残りうる、という補足もありました。
執筆者は、無効化のオプションについて、WordPressの設計思想として、すべての機能にオプトアウトの設定画面を付けると設定ページが使えなくなる、という趣旨で答えています。ノート本文で示されている無効化の手段はフィルターだけなので、画面ではなくコードで行う前提と読めます。
7.2に上げる前に確認したいこと
筆者の見方では、ブログのように「ランダムに読む」導線が歓迎されるサイトがある一方、大規模サイトや、非公開に近い使い方をしているカスタム投稿タイプを持つサイトでは、7.2に上げる前に確認しておきたい変更です。ベータ版（Beta 4が公開中）の段階で、自分のサイトの投稿タイプにrandomableのデフォルトがどう効くかと、負荷への影響を、ステージング環境で確かめておくとよいでしょう。検索エンジンの扱いについては、ノート本文には書かれていません（コメントには、リダイレクト時にno-cacheとnoindexのヘッダーを送るとの記述があります）。
ステージング環境で試す手順としては、7.2のベータ版を入れたうえで、/random/と、カテゴリ・投稿者・カスタム投稿タイプのURLを順にたどり、意図しない投稿が出ないかを確かめるのが分かりやすい方法です。不要なら上のフィルターを入れるだけで済みます。
出典
- Make WordPress Core「Your Content Is Going To Get More Random!」（2026年11月5日）
- WordPress.org News「WordPress 7.2 Beta 4」（2026年11月3日）
2026年11月7日時点の情報です。
コメント