“Too many redirects” in WordPress oplossen

De foutmelding “Too many redirects” in WordPress betekent dat je browser in een lus terechtkomt: pagina A verwijst naar pagina B, en B verwijst weer terug naar A (of naar C en C weer naar A). De browser stopt na ongeveer 20 doorverwijzingen en toont de melding. Hieronder lees je wat de oorzaak meestal is en welke drie checks de redirect-loop verhelpen.

Wat veroorzaakt een redirect-loop?

Een browser volgt redirects automatisch, maar stopt na ongeveer twintig doorverwijzingen met de melding ERR_TOO_MANY_REDIRECTS (Chrome) of “De pagina maakt een doorverwijzing die nooit voltooid wordt” (Firefox). De WordPress-site reageert dus wel, maar stuurt je telkens door zonder ooit een eindpagina te tonen.

In de praktijk komt “Too many redirects” in WordPress vrijwel altijd door een van deze drie oorzaken:

• De waarden siteurl en home in de database staan niet gelijk, of staan nog op http:// terwijl de site op https:// draait.
• Een redirect-plugin (Redirection, Yoast Redirect Manager, Rank Math) bevat een regel die naar zichzelf of naar een andere regel in de lijst wijst.
• Een handmatige RewriteRule of Redirect in .htaccess die doorverwijst naar dezelfde URL als waar hij op reageert.

Werk de checks hieronder in volgorde af. Sla geen stap over, want check 1 lost het in de meeste gevallen al op.

Check 1: siteurl en home in de database

WordPress slaat twee URL’s op in de tabel wp_options: siteurl (waar de WordPress-bestanden staan) en home (waar bezoekers de site benaderen). Voor een standaard-WordPress-site moeten deze waarden gelijk zijn en beide op https://jouw-website.nl staan. Wijkt een van beide af, of staat er nog http://, dan ontstaat een loop tussen WordPress en de server-redirect.

Via phpMyAdmin in Plesk

Log in op het controlepaneel

Je vindt het controlepaneel door :8443 achter jouw domeinnaam te typen. Bijvoorbeeld: www.jouw-website.nl:8443.

Ben je je gebruikersnaam of wachtwoord vergeten, dan vind je op deze pagina instructies om je wachtwoord op te vragen.

Ga in Plesk naar Databases en open phpMyAdmin bij de WordPress-database. Open de tabel wp_options en zoek de rijen siteurl en home. Zet beide waarden op https://jouw-website.nl, exact zonder slash op het einde en zonder www. als de site daarop niet draait.

Via WP-CLI (op het Businesspakket)

Op het Businesspakket van onze WordPress-hosting is WP-CLI standaard beschikbaar via Plesk. Twee commando’s zijn voldoende:

wp option update siteurl https://jouw-website.nl
wp option update home https://jouw-website.nl

Geen Businesspakket? Gebruik dan de phpMyAdmin-route hierboven, die werkt op elk pakket.

Check 2: redirect-plugins

Plugins als Redirection, Yoast SEO Premium Redirect Manager en Rank Math beheren redirects binnen WordPress zelf. Eén regel die per ongeluk verwijst van /over-ons naar /over-ons/ (let op de slash) is genoeg voor een lus, want WordPress vult de slash zelf aan en stuurt het verzoek weer door de plugin.

Open de plugin in het WordPress-dashboard en controleer:

• Regels waarbij source en target alleen verschillen in een slash, een www., of http versus https.
• Regels waarvan de target ergens anders in de lijst opnieuw als source voorkomt.
• Wildcard- of regex-regels die per ongeluk de hele site vangen (bijvoorbeeld /.* als source).

Kom je niet meer in WP-admin omdat ook /wp-admin in de lus zit? Hernoem dan tijdelijk de map van de plugin via FTP of de Plesk file-manager (bijvoorbeeld redirection naar redirection-off). WordPress deactiveert de plugin automatisch zodra het de map niet meer vindt. Voor FTP-toegang, zie verbinding maken via FTP.

Check 3: .htaccess-regels

Het bestand .htaccess in de root van de WordPress-installatie kan handmatige redirects bevatten, bijvoorbeeld toegevoegd door een eerdere ontwikkelaar of door een SEO-plugin. Een regel die per ongeluk naar dezelfde URL wijst, levert direct een loop op.

Open .htaccess via de Plesk file-manager en zoek naar regels boven of onder het standaard WordPress-blok (begrensd door # BEGIN WordPress en # END WordPress). Twee patronen die vaak fout gaan:

• Een RewriteRule die zonder een uitsluitende conditie de hele site naar https:// dwingt, terwijl WordPress dat al doet via siteurl.
• Een Redirect 301 /pad /pad-regel waarvan source en target identiek zijn.

Maak voor je iets wijzigt een kopie van het bestand (bijvoorbeeld .htaccess.bak). Verwijder daarna de verdachte regels, of zet ze uit met een # aan het begin van de regel. Test daarna direct of de site weer reageert.

Komt het probleem terug nadat je .htaccess opschoonde, lees dan ons artikel over 404-errors voorkomen. Daarin staat hoe de rewrite-regels van WordPress werken.