Wat betekent ERR_TOO_MANY_REDIRECTS in WordPress?

De browser krijgt steeds een doorverwijzing naar een volgende URL en bereikt geen eindpagina. Vaak sturen twee lagen elkaar terug, bijvoorbeeld WordPress naar HTTPS en een proxy weer naar HTTP, of www naar zonder www en een plugin terug naar www.

Moet ik cookies verwijderen bij een WordPress-redirectlus?

Verwijder eerst alleen cookies voor het getroffen domein en test in een privésessie. Dat kan een inloglus of een verouderde sessie oplossen, maar een redirectlus die ook andere bezoekers treft zit meestal in WordPress, cache, proxy of serverconfiguratie.

Wat is het verschil tussen WordPress Address en Site Address?

WordPress Address is de URL waar de WordPress-corebestanden staan. Site Address is de publieke URL die bezoekers gebruiken. Bij een installatie in de webroot zijn ze meestal gelijk, maar bij WordPress in een submap kunnen ze bewust verschillen.

Kan een CDN een Too Many Redirects-fout veroorzaken?

Ja. Een CDN of reverse proxy kan HTTPS beëindigen terwijl de origin HTTP ziet. Als WordPress of de server daardoor opnieuw naar HTTPS verwijst, kan een lus ontstaan. Controleer de TLS-modus, doorgestuurde headers en redirectregels als één samenhangende laag.

Kan ik WP_HOME en WP_SITEURL tijdelijk in wp-config.php zetten?

Ja, als je de bedoelde URL zeker weet en eerst een kopie van wp-config.php maakt. De constanten overschrijven tijdens runtime de opgeslagen waarden zonder de database zelf te wijzigen, waardoor verwijderen van de regels een duidelijke rollback is.

Moet ik de home- en siteurl-velden direct in de database aanpassen?

Niet als eerste stap. Controleer eerst de bedoelde URL en eventuele wp-config-constanten. Een tijdelijke, gedocumenteerde override is beter terug te draaien dan een blinde databasewijziging en voorkomt dat je een tweede fout introduceert.

Wanneer schakel ik de hostingprovider in bij een redirectlus?

Doe dat als de lus bij de proxy, TLS-terminatie, serverregels of multisite-domeintoewijzing zit, als je de origin niet veilig kunt testen of als het hostingpaneel en WordPress verschillende HTTPS-statussen zien. Deel de redirectketen, maar geen cookies of geheimen.

Too Many Redirects in WordPress oplossen (2026)

De melding Too Many Redirects betekent dat je browser geen eindpagina bereikt omdat URL's elkaar blijven doorsturen. Bepaal eerst welke twee adressen in de lus terugkomen en controleer daarna één laag tegelijk: cookies, cache, WordPress-URL's, HTTPS-detectie, proxy of CDN, plugins en serverregels.

Hoe een redirectlus ontstaat

Een normale redirect heeft een begin en een eind, bijvoorbeeld van http://voorbeeld.nl naar https://voorbeeld.nl. Bij een lus stuurt de eindbestemming opnieuw terug. Veelvoorkomende patronen zijn:

http://voorbeeld.nl -> https://voorbeeld.nl -> http://voorbeeld.nl

https://www.voorbeeld.nl -> https://voorbeeld.nl -> https://www.voorbeeld.nl

/wp-login.php -> /wp-admin/ -> /wp-login.php

De browsermelding noemt de verantwoordelijke laag niet. WordPress, een redirect- of beveiligingsplugin, .htaccess, Nginx, een reverse proxy en een CDN kunnen allemaal een Location-header toevoegen. Twee afzonderlijk logische regels kunnen samen toch een lus maken.

Komt een route zonder redirect terug met een serverfout, gebruik dan de 500 Internal Server Error-handleiding. Een redirect naar een niet-bestaande eindpagina behandel je via 404 na permalinks.

Leg eerst de veilige uitgangssituatie vast

Maak een database-export en een kopie van de bestanden, in elk geval wp-config.php, .htaccess en wp-content. De officiële WordPress-back-uphandleiding legt uit waarom bestanden en database samen één herstelset vormen. Controleer ook hoe je die set terugzet voordat je productie wijzigt.

Noteer daarna:

de exacte URL die je invoert;
of de lus alleen bij /wp-admin/, alleen bij één pagina of overal optreedt;
of HTTP, HTTPS, www en zonder www hetzelfde reageren;
de laatste wijziging aan domein, TLS-certificaat, CDN, proxy, plugin of serverregels;
de huidige waarden van WordPress Address en Site Address, zonder andere configuratiegegevens te delen.

Bewaar cookies, authenticatieheaders, API-sleutels en volledige configuratiebestanden buiten screenshots en tickets. Een redirectketen met alleen status, bron-URL en doel-URL is meestal voldoende bewijs.

Stap voor stap de WordPress-redirectlus oplossen

1. Sluit één browser of sessie uit

Open de URL in een privésessie en op een tweede netwerk of apparaat. Werkt de site daar wel, verwijder dan alleen de cookies en sitegegevens van dit domein in de getroffen browser. Wis niet meteen alle browsergegevens.

Een lokale oplossing bewijst niet dat de site voor bezoekers gezond is. Test daarom ook zonder ingelogde WordPress-sessie. Als meerdere onafhankelijke clients dezelfde lus zien, ga je verder met de server- en applicatielagen.

2. Leg de redirectketen vast

Open de netwerkinformatie van je browser of het HTTP-overzicht van je hostingprovider. Noteer per stap de status, meestal 301, 302, 307 of 308, en de waarde van de Location-header. Stop na een beperkt aantal redirects.

Let vooral op wat wisselt:

http tegenover https;
www tegenover het hoofddomein;
een pad met en zonder afsluitende slash;
/wp-login.php tegenover /wp-admin/;
twee taal- of landpaden.

De eerste herhaling in de keten is je beste aanwijzing. Wijzig nog niets totdat je weet welk patroon je probeert te doorbreken.

3. Kies één bedoelde canonieke URL

Leg vast welk schema, domein en pad bezoekers moeten gebruiken. Controleer of het TLS-certificaat voor dat domein geldig is en of WordPress in de webroot of een submap staat. De WordPress Address en Site Address zijn niet per definitie hetzelfde.

Volgens de officiële uitleg van de algemene instellingen wijst WordPress Address naar de map met de corebestanden. Site Address is het publieke adres. Bij een standaardinstallatie in de webroot zijn beide vaak https://voorbeeld.nl. Staat WordPress in /wordpress maar opent de site op het hoofddomein, dan kunnen de twee bewust verschillen.

Maak ze dus niet blind gelijk. Controleer de installatieopzet en noteer de correcte eindwaarden.

4. Controleer wp-config.php vóór de database

Download wp-config.php en bewaar een ongewijzigde kopie. Zoek naar WP_HOME, WP_SITEURL, FORCE_SSL_ADMIN en maatwerkcode die HTTPS of hostnamen bepaalt.

De WordPress-documentatie voor WP_HOME en WP_SITEURL legt uit dat deze constanten de opgeslagen URL tijdens runtime overschrijven, maar de databasewaarde niet aanpassen. Staan ze in wp-config.php, dan kunnen de velden in het beheerscherm vaststaan.

Heb je de juiste URL met zekerheid vastgesteld, dan kun je een onjuiste constante corrigeren. Kun je niet inloggen en zijn er geen constanten, dan is een tijdelijke override met de geverifieerde vaste URL beter omkeerbaar dan blind home en siteurl in de database wijzigen:

define( 'WP_HOME', 'https://voorbeeld.nl' );
define( 'WP_SITEURL', 'https://voorbeeld.nl' );

Dit voorbeeld geldt voor WordPress in de webroot. Gebruik jouw gecontroleerde installatiepad. Test één URL en zet bij een negatief resultaat de vorige wp-config.php terug. Laat de override niet ongemerkt als permanente pleister staan: controleer na herstel ook de opgeslagen instellingen en documenteer welke bron leidend moet zijn.

5. Controleer HTTPS bij reverse proxy of CDN

Een proxy of CDN kan de publieke HTTPS-verbinding beëindigen en het verzoek intern via HTTP naar de origin sturen. Als WordPress daardoor denkt dat het verzoek onveilig is, verwijst het opnieuw naar HTTPS. Een andere laag kan dat vervolgens weer als HTTP aanbieden, waardoor de lus blijft draaien.

De officiële WordPress HTTPS-handleiding beschrijft dat WordPress achter een reverse proxy het doorgestuurde protocol correct moet herkennen. De proxy moet de juiste X-Forwarded-Proto-informatie zetten en WordPress mag die alleen vertrouwen wanneer verzoeken daadwerkelijk via jouw gecontroleerde proxy lopen.

Controleer samen met de host:

welke laag het TLS-certificaat afhandelt;
welke TLS- of originmodus het CDN gebruikt;
of de origin zelf HTTPS verwacht;
of host- en protocolheaders betrouwbaar worden doorgestuurd;
of zowel edge als origin dezelfde HTTP-naar-HTTPS-regel uitvoeren.

Plak geen willekeurige proxycode uit een handleiding in wp-config.php. Een onbetrouwbare client mag niet zelf bepalen dat een verbinding veilig is. Pas headervertrouwen alleen aan binnen een bekende proxyarchitectuur en met een rollback.

6. Omzeil of leeg caches gericht

Leeg eerst de WordPress-pagina- en objectcache volgens de documentatie van je huidige oplossing. Leeg daarna, niet tegelijk, de servercache en vervolgens de CDN-cache. Test na iedere laag dezelfde URL en leg de nieuwe keten vast.

Een cache kan een oude 301 of 302 blijven serveren nadat de regel al is gecorrigeerd. Toch is “alle caches leegmaken” geen oplossing voor een actieve lus. Herstel eerst de conflicterende regel en wis daarna de laag die de oude respons bewaart.

Gebruik bij een CDN een officiële ontwikkel- of bypassmodus als die beschikbaar is. Wijzig DNS niet voor een snelle test zonder de huidige waarden, TTL, mailrecords en rollback exact vast te leggen.

7. Isoleer redirect-, SSL-, cache- en beveiligingsplugins

Als de lus begon na een pluginwijziging, schakel eerst die ene plugin uit. Kun je niet inloggen, hernoem dan via SFTP tijdelijk alleen de map van de verdachte plugin. Test, herstel de mapnaam bij een negatief resultaat en ga pas daarna naar een volgende plugin.

Als geen plugin duidelijk verdacht is, kun je de normale plugins gezamenlijk uitschakelen door wp-content/plugins tijdelijk te hernoemen. De officiële WordPress-probleemoplossing beschrijft deze route als het beheergedeelte niet bereikbaar is. Test dit bij een site met transacties bij voorkeur in staging, omdat formulieren, beveiliging en andere functies tijdelijk wegvallen.

Werkt de site zonder normale plugins, zet de map terug en activeer plugins één voor één. Vergeet niet dat must-use plugins en drop-ins buiten de gewone pluginlijst kunnen vallen.

8. Controleer serverregels als aparte laag

Op Apache en vaak LiteSpeed kan .htaccess redirects bevatten. Download het bestand, noteer rechten en hernoem het tijdelijk naar .htaccess.voor-redirecttest. Verwijder het niet. Test dezelfde URL en herstel de originele naam direct als de lus blijft.

Werkt de site zonder het bestand, laat WordPress de standaard permalinkregels opnieuw opslaan en voeg maatwerkredirects daarna één voor één terug. Controleer www, HTTPS en slashregels op dubbel werk met het CDN.

Nginx gebruikt geen .htaccess. Laat daar de actieve serverblokken, include-bestanden en deployhistorie controleren. Pas niet tegelijk Nginx en WordPress aan.

9. Controleer login-, taal- en domeinlogica

Een lus die alleen bij inloggen optreedt kan samenhangen met cookies, HTTPS-detectie, een beveiligingsregel of een verkeerd domein. Een lus tussen taalpaden kan door taalkeuze, geolocatie of cachevariatie ontstaan. Leg de twee terugkerende Location-waarden vast en schakel alleen de verantwoordelijke regel tijdelijk uit.

Bij WordPress Multisite zijn netwerkdomein, sitepad en cookie-instellingen met elkaar verbonden. Wijzig geen tabellen of multisiteconstanten zonder een export en kennis van de domeintoewijzing. Laat een beheerder die de netwerkopzet kent de route beoordelen.

10. Valideer de eindtoestand en herstel bescherming

Test na de oplossing:

HTTP naar de bedoelde HTTPS-versie;
www en zonder www;
startpagina, inhoudspagina en statisch bestand;
/wp-login.php en /wp-admin/;
uitloggen en opnieuw inloggen;
een formulier of andere kritieke route.

De bedoelde varianten mogen één duidelijke kant op verwijzen en moeten daarna een eindrespons bereiken. Heractiveer caches en beveiligingslagen één voor één en controleer de keten opnieuw. Verwijder tijdelijke overrides als ze niet de gekozen permanente configuratie zijn en bewaar de werkende bestanden als nieuwe herstelbasis.

Veelgemaakte fouten

Alle cookies, caches en instellingen tegelijk wissen. Dan weet je niet welke laag de lus veroorzaakte.
WordPress Address en Site Address blind gelijk maken. Bij een submapinstallatie kunnen ze terecht verschillen.
Home en siteurl direct in de database wijzigen. Zonder gecontroleerde eind-URL en export kan dat de toegang verder breken.
HTTPS op CDN én origin los van elkaar afdwingen. Twee regels met verschillende protocoldetectie kunnen elkaar blijven terugsturen.
Doorgestuurde headers van iedere bezoeker vertrouwen. Alleen een gecontroleerde proxy mag de oorspronkelijke verbindingsstatus bepalen.
.htaccess verwijderen zonder kopie. Hernoemen geeft een snelle rollback en heeft op Nginx helemaal geen effect.
Alle plugins uit laten na één positieve test. Zet de map terug en isoleer daarna de afzonderlijke veroorzaker.
Een cache als enige oorzaak aanwijzen. Een cache bewaart de respons, maar een actieve redirectregel moet nog steeds worden gecorrigeerd.
De site gezond verklaren zodra de startpagina opent. Login, beheer, HTTP, HTTPS en belangrijke formulieren kunnen nog een aparte lus hebben.

Wanneer je beter stopt

Stop als je de canonieke URL of installatieplaats niet zeker weet, geen herstelbare back-up hebt, een proxyheader moet vertrouwen zonder de netwerktopologie te kennen of de site WordPress Multisite gebruikt. Laat hosting of een ontwikkelaar dan de redirectketen, TLS-terminatie en actieve regels samen beoordelen.

Deel alleen statuscodes, opgeschoonde bron- en doel-URL's en tijdstippen. Deel geen cookies, authenticatieheaders of configuratiegeheimen. Ga voor andere foutmeldingen terug naar de WordPress-hub of controleer een toegangsblokkade via WordPress 403 Forbidden.

Wil je dat iemand de redirectketen en veilige eindconfiguratie gecontroleerd onderzoekt, vraag een offerte aan via WhatsApp, mail naar w.bouwmeester@bouwmeesterconsultancy.nl of bel 0628963636.