Naar de inhoud

Persoonlijke support vanuit Oostende   support@kyzoe.be   +32 59 53 00 00

Kennisbank   Nieuws   Serverstatus   KlantenpaneelNLENFR

WordPress 7.2 zet de /random/-URL standaard aan op 8 december

WordPress 7.2 /random/: willekeurige content, nieuwe aandachtspunten

Het WordPress-coreteam publiceerde op 5 november 2026 een developer note over een nieuwe functie in versie 7.2: de /random/-URL, die de bezoeker doorstuurt naar een willekeurig gekozen gepubliceerd bericht. In de note staat letterlijk dat de functie standaard aanstaat (“the feature is on by default”). Versie 7.2 zit sinds 10 november aan beta 5. De eerste release candidate (RC1) is gepland voor 17 november en de definitieve release voor 8 december.

Hoe /random/ werkt

Als mooie permalinks zijn ingeschakeld, kiest /random/ een willekeurig bericht dat in aanmerking komt. Er zijn ook varianten per archief: ,,/random/author/{naam}/ en /random/{post-type}/. Het segment random is vertaalbaar en je kunt het aanpassen op het permalinkscherm.

Publieke inhoudstypes met een archiefpagina doen mee aan de trekking. Dat wordt geregeld met het nieuwe argument randomable van register_post_type(). Berichten doen mee, pagina’s en bijlagen niet. Een eigen inhoudstype dat door een plugin of thema is geregistreerd, zoals testimonials of portfolio-items, doet automatisch mee als het een publiek archief heeft.

De trekking voert de hoofdquery uit met ORDER BY RAND() een limiet van één rij. Alle callbacks die de site al heeft, zijn er ook op van toepassing.

Om de functie uit te schakelen, biedt Core een filter:

add_filter( 'wp_enable_random_content_redirect', '__return_false' );

Daarmee worden de rewrite rules /random/ niet meer gegenereerd en wordt de queryvariabele genegeerd.

Wie moet dit controleren vóór de update?

De eerste groep zijn sites met veel berichten. Door ORDER BY RAND() moet MySQL bij elke aanvraag de tabel doorlopen en sorteren. In de reacties op de note mat een deelnemer ongeveer 24 ms bij 50.000 berichten en 1,87 s bij 2 miljoen, op een snelle lokale machine. Omdat deze URL niet op de gebruikelijke manier uit de cache kan worden geserveerd, veroorzaakt elke bot die ze bezoekt een nieuwe databasequery. Aaron Jorbin, de auteur van de note, heeft een ticket geopend om prestatieverbeteringen te onderzoeken.

De tweede groep is iedereen die full-page caching of een CDN gebruikt. In een reactie werd een geval gemeld waarbij het antwoord terugkwam als een 200 zonder no-cache- of noindex-headers. In die situatie bewaart de cache de eerste trekking en krijgt iedereen diezelfde pagina te zien. Jorbin antwoordde dat de ontbrekende headers een bug zijn die een ticket waard is.

De derde groep zijn sites met inhoudstypes die nooit bedoeld waren om op zichzelf te worden gelezen. Met de standaardregel krijgen die items een publieke toegangspoort waar de site-eigenaar niet om heeft gevraagd.

Bureaus en teams die veel WordPress-sites onderhouden, krijgen met alle drie te maken: ze moeten ofwel site per site beslissen, ofwel overal dezelfde regel toepassen.

Wat te doen vóór 8 december

Vanaf RC1 op 17 november kun je het echte gedrag testen op een kopie van de site: open /random/, controleer de statuscode en de headers van het antwoord, en kijk wat de cache of het CDN opslaat.

Heb je de functie niet nodig, dan is de eenvoudigste weg ze vóór de update uit te schakelen met het filter in een mu-plugin (een must-use plugin, die geladen wordt zonder dat je ze in het dashboard activeert). Is de functie wel nuttig, geef dan 'randomable' => false mee aan de inhoudstypes die buiten de trekking moeten blijven, en houd in de serverlogs in de gaten hoeveel aanvragen er /random/ binnenkomen.

Wat nog openstaat

De note vermeldt niet welke statuscode de redirect gebruikt, welke cache-headers worden meegestuurd, of het antwoord een noindex bevat en of /random/ het uit de sitemap wordt gehouden. Er staat ook niet in wat er gebeurt met berichten die door SEO-plugins als noindex zijn gemarkeerd.

De reacties op de note zijn overwegend tegen het standaard inschakelen van de functie, en meerdere vragen om ze terug te draaien of naar een plugin te verplaatsen. Op 11 november stond in het bericht geen beslissing om de standaardinstelling vóór 7.2 te wijzigen. Als het gedrag verandert, zou dat zichtbaar moeten worden in RC1 of in de latere RC’s, gepland voor 24 november en 1 december.

Lees ook

Hulp nodig met je website of hosting?

Stel je vraag, we helpen je persoonlijk verder.

Contacteer ons
Bekijk de pakketten
NL