WordPress 7.2 suma el endpoint /random/ por defecto

En pocas palabras: WordPress 7.2 incorpora el endpoint /random/, activado por defecto, que redirige a un post publicado elegido al azar. Funciona con las APIs de rewrite, WP y WP_Query, cubre categorías, tags, autores y post types habilitados, y puede desactivarse con el filtro wp_enable_random_content_redirect.

WordPress 7.2 suma el endpoint /random/, una funcionalidad nativa del core que redirige a los usuarios a un post publicado elegido al azar cada vez que visitan esa URL, sin necesidad de instalar ningún plugin. La nota oficial del core confirma que viene activada por defecto: se apoya en las APIs de rewrite, WP y WP_Query que ya existían, genera reglas de reescritura para categorías, tags, autores y post types, y queda desactivable con el filtro wp_enable_random_content_redirect. No hace falta tocar el .htaccess ni nada parecido.

¿Qué es el nuevo endpoint /random/ de WordPress 7.2?

Es una ruta fija (example.com/random/) que ejecuta una query y te manda a un post publicado cualquiera. Nada de plugin de terceros, nada de shortcode: lo resuelve WP con las mismas piezas que ya usaba para archivos y feeds.

Ejemplo hipotético: imaginá un blog con 800 posts viejos que nadie encuentra porque el buscador interno es mediocre (pasa más de lo que gustaría admitir). Con /random/ activo, cualquier visitante podría caer en una nota de hace tres años sin que el equipo editorial mueva un dedo. No es una garantía de tráfico, pero sí una puerta de entrada que antes no existía.

¿Cómo funcionan las URLs aleatorias en WordPress?

La base random se antepone a las rutas de archivo que ya existen, y es traducible y editable desde wp-admin/options-permalink.php. Con permalinks amigables activados, el core genera un set de reglas bastante prolijo.

Estos son los patrones que arma por defecto, según el dev note de WordPress 7.2:

• /random/: redirige a un post al azar entre todos los publicados.
• /random/category/release/: random dentro de la categoría «release».
• /random/tag/dev-note/: random dentro de esa taxonomía, y aplica a cualquier taxonomía públicamente consultable.
• /random/author/jorbin/: random entre los posts de ese autor.
• /random/{post-type-slug}/: random dentro de un custom post type, siempre que sea randomable.

¿Y si cambiás el idioma del sitio? La base se traduce sola, así que en un sitio en otro idioma vas a ver una versión traducida de esa base, según cómo lo resuelva el paquete de idioma correspondiente.

¿Qué post types son «randomables» por defecto en WordPress 7.2?

El post type post es randomable de fábrica. Las páginas y los adjuntos (page y attachment) no lo son, aunque tu sitio tenga miles de ellos.

El criterio lo define un argumento nuevo, randomable, en register_post_type(). Si no lo declarás explícitamente, WordPress lo calcula solo: queda en true cuando el post type es publicly_queryable y tiene has_archive activado. Si registraste un CPT con esas dos condiciones y nunca pensaste en esto, ya está sumado al sorteo sin que lo hayas pedido (spoiler: a veces no es lo que querés).

Un ejemplo directo del propio dev note:

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

Post type	¿Randomable por defecto?	Motivo
post	Sí	Nativo, incluido desde el core
page	No	Excluido aunque tenga archivo
attachment	No	Excluido por diseño
CPT con public + has_archive	Sí	A menos que declares randomable => false
CPT sin has_archive	No	No cumple el requisito mínimo

Más allá de lo que calcula el core por defecto, conviene tener criterios propios para decidir si un CPT debería estar en el sorteo:

• ¿El contenido tiene valor editorial para quien lo descubre sin contexto? Un post de blog funciona random; una landing page de producto o un formulario de contacto, no.
• ¿Es contenido transaccional o de una sola visita? Testimonios, páginas de checkout o fichas técnicas puntuales suelen perder sentido fuera de su flujo original.
• ¿El CPT tiene archivo público (has_archive) solo por una necesidad técnica? Si lo activaste para otro fin (por ejemplo, un sitemap personalizado) y no para que la gente navegue el archivo, es candidato a randomable => false.
• ¿El volumen de contenido justifica el costo de la query? Con pocos registros el impacto es despreciable; con miles, cada CPT randomable suma carga adicional (ver más abajo).

¿Cómo personalizar o desactivar el contenido aleatorio?

La selección aleatoria corre a través de la query principal mediante WP::handle_random(), que agrega tres callbacks durante el request: wp_random_content_pre_get_posts() sobre pre_get_posts, wp_random_content_posts_orderby() sobre posts_orderby y wp_random_content_post_limits() sobre post_limits. Entre los tres restringen la query a posts elegibles, ordenan por RAND() y cortan el resultado a una sola fila.

Ahora bien: como todo pasa por la query principal, cualquier callback de pre_get_posts que ya modifique un archivo también se aplica a su redirect random. Si querés tocar solo las consultas random sin afectar el archivo normal, hay que chequear con 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 ) );
}
}
);

Si directamente no te interesa el feature (o le tenés fiaca, no hay drama), el filtro wp_enable_random_content_redirect lo apaga entero: no se generan reglas de rewrite, el campo de la base random desaparece en la pantalla de permalinks y la query var random se ignora. Antes de aplicar estos cambios en producción, conviene probarlos primero en un entorno de staging para evitar sorpresas con las reglas de rewrite existentes. Un mu-plugin de una línea resuelve todo:

add_filter( 'wp_enable_random_content_redirect', '__return_false' );

¿Qué implica este cambio para sitios y desarrolladores WordPress?

Lo primero que cambia es la descubribilidad de contenido viejo: posts que estaban enterrados en la página 40 del blog ahora tienen una puerta de entrada directa. Para sitios editoriales con archivo grande, esto puede mover métricas de tiempo en sitio sin que toques una línea de template.

El tema es que ORDER BY RAND() no es gratuito en tablas grandes: en un sitio con decenas de miles de posts, cada hit a /random/ dispara una query que escanea más de lo que un archivo paginado normal necesitaría. Si tu base de datos ya viene ajustada, probablemente no lo notes. Si no, conviene medirlo antes de que algún bot indexe /random/ mil veces por hora y te sature la base. Para sitios con tráfico alto y catálogos grandes, tener un hosting WordPress con buen rendimiento de base de datos (el de Donweb, por ejemplo) ayuda a que este tipo de queries no se conviertan en un cuello de botella.

Ejemplo hipotético: un equipo sube un plugin con un CPT de «testimonios» en local, todo funciona bien, lo pasa a producción, y meses después alguien nota que /random/testimonios/ está sirviendo tráfico porque nadie puso randomable => false al registrarlo. No es un bug del core: es una decisión que quedó sin tomar. Revisar los CPT existentes contra los criterios de la sección anterior evita este tipo de sorpresas.

Errores comunes al implementar /random/ en WordPress

• Asumir que los CPT quedan afuera por defecto: si tu post type es publicly_queryable y tiene has_archive, ya está adentro del sorteo aunque nunca lo hayas pedido explícitamente.
• Olvidarse de wp_is_random_content_query(): modificar pre_get_posts sin ese chequeo termina afectando también los archivos normales, no solo el redirect random.
• Pensar que hay que tocar rewrite rules a mano: alcanza con el filtro wp_enable_random_content_redirect en un mu-plugin, no hace falta editar .htaccess.
• No medir el impacto en bases grandes: ORDER BY RAND() sobre miles de filas puede pesar más de lo esperado si tu sitio tiene un archivo histórico extenso.

Preguntas Frecuentes

¿Qué es la función random de WordPress 7.2?

Es el endpoint /random/, una funcionalidad del core que redirige a un post publicado elegido al azar usando las APIs de rewrite, WP y WP_Query. Viene activada por defecto en WordPress 7.2 y no requiere plugins.

¿Cómo desactivar el endpoint /random/ en WordPress?

Agregando add_filter( 'wp_enable_random_content_redirect', '__return_false' ); en un mu-plugin o en functions.php. Esto elimina las reglas de rewrite, oculta el campo de la base random en permalinks y desactiva la query var.

¿Qué post types son randomables por defecto en WordPress?

El post type post es randomable por defecto. page y attachment no lo son. Cualquier custom post type con publicly_queryable y has_archive en true queda randomable salvo que se declare randomable => false explícitamente.

¿Cómo personalizar qué entradas aparecen en /random/?

Con un callback en pre_get_posts que use wp_is_random_content_query( $query ) para detectar si la consulta actual es una petición random y ajustarla, por ejemplo excluyendo categorías puntuales con category__not_in.

¿Las páginas aparecen en el contenido aleatorio de WordPress?

No. El post type page no es randomable por defecto en WordPress 7.2, así que las páginas quedan fuera del endpoint /random/ aunque tu sitio tenga cientos de ellas.

Conclusión

WordPress 7.2 suma descubribilidad nativa sin que tengas que instalar nada, y lo hace con un diseño razonable: on por defecto para posts, off para páginas y adjuntos, y un filtro único para apagar todo si no te sirve. Lo que sí queda en tu cancha es revisar los custom post types de tu sitio y decidir, uno por uno, si tiene sentido que aparezcan en el sorteo. Si tenés un archivo grande, vale la pena medir el impacto de ORDER BY RAND() antes de que algún bot te lo haga notar por las malas.

Fuentes

• Make WordPress Core – Dev note oficial sobre el endpoint /random/ en WordPress 7.2