Una nota técnica publicada por el equipo del núcleo de WordPress el 5 de noviembre de 2026 describe una función nueva de la versión 7.2: la dirección /random/, que redirige al visitante a una entrada publicada elegida al azar. La nota dice que "la función viene activada por defecto". La 7.2 está en beta 5 desde el 10 de noviembre, el primer release candidate (RC1) está previsto para el 17 de noviembre y la versión final para el 8 de diciembre.
Cómo funciona /random/
Con enlaces permanentes amigables activos, /random/ sortea cualquier entrada elegible. Hay variantes por archivo: /random/category/{slug}/, /random/tag/{slug}/, /random/author/{nombre}/ y /random/{tipo-de-contenido}/. El segmento random se puede traducir y cambiar en la pantalla de enlaces permanentes.
Entran en el sorteo los tipos de contenido públicos con página de archivo, controlados por el nuevo argumento randomable de register_post_type(). Las entradas entran; las páginas y los adjuntos quedan fuera. Un tipo personalizado registrado por un plugin o tema, como testimonios o portafolio, entra automáticamente si tiene archivo público.
El sorteo ejecuta la consulta principal con ORDER BY RAND() y límite de una fila. Los callbacks de pre_get_posts que el sitio ya tiene también se aplican a esa consulta.
Para desactivarla, el núcleo ofrece un filtro:
add_filter( 'wp_enable_random_content_redirect', '__return_false' );Con él, las reglas de reescritura de /random/ dejan de generarse y la variable de consulta se ignora.
Quién debe revisarlo antes de actualizar
El primer grupo son los sitios con muchas entradas. ORDER BY RAND() hace que MySQL recorra y ordene la tabla en cada petición. En los comentarios de la nota, un participante midió unos 24 ms con 50 mil entradas y 1,87 s con 2 millones, en una máquina local rápida. Como esta dirección no se puede servir desde la caché de la forma habitual, cada robot que la visita genera una consulta nueva a la base de datos. Aaron Jorbin, autor de la nota, abrió un ticket para estudiar mejoras de rendimiento.
El segundo grupo es quien usa caché de página completa o CDN. Un comentario relató un caso en que la respuesta salió con estado 200, sin cabeceras de no-cache ni noindex. En esa situación, la caché guarda el primer sorteo y lo entrega a todos. Jorbin respondió que la falta de esas cabeceras es un bug que merece ticket.
El tercero son los sitios con tipos de contenido que no se hicieron para leerse por separado. Con el criterio por defecto, esos elementos ganan una puerta de entrada pública que el dueño del sitio no pidió.
Las agencias y los equipos que mantienen muchos sitios WordPress suman los tres casos, porque tienen que decidir sitio por sitio o aplicar una regla para todos.
Qué hacer antes del 8 de diciembre
A partir del RC1, el 17 de noviembre, se puede probar el comportamiento real en una copia del sitio: abrir /random/, revisar el estado y las cabeceras de la respuesta y ver qué guardan la caché o la CDN.
Si la función no le sirve al producto, lo más simple es desactivarla con el filtro en un mu-plugin (plugin de uso obligatorio, que se carga sin activarse en el panel) antes de actualizar. Si la función interesa, conviene pasar 'randomable' => false a los tipos de contenido que no deben entrar en el sorteo y seguir en los logs del servidor cuántas peticiones llegan a /random/.
Quien aplica versiones principales automáticamente, por configuración propia o del hosting, debería revisar esto antes del 8 de diciembre. Para los demás, elegir entre actualizar el mismo día o esperar una versión de corrección sigue el mismo razonamiento de una versión con soporte también exige decidir cuándo migrar: la 7.1 sigue recibiendo correcciones de seguridad, así que esperar algunas semanas cuesta poco.
Lo que sigue abierto
La nota no informa el código de estado de la redirección, las cabeceras de caché, si la respuesta lleva noindex ni si /random/ queda fuera del sitemap. Tampoco dice qué pasa con las entradas marcadas como noindex por plugins de SEO.
Los comentarios de la nota están en gran parte en contra de que la función venga activada, y varios piden revertirla o convertirla en plugin. Hasta el 11 de noviembre, el post no registraba ninguna decisión de cambiar el valor por defecto antes de la 7.2. Si el comportamiento cambia, debería aparecer en el RC1 o en los RC siguientes, previstos para el 24 de noviembre y el 1 de diciembre.
Si tu empresa está evaluando algo parecido, escríbeme por LinkedIn o por WhatsApp.
