Contact
← Terug naar kennisbank HOSTING

ERR_TOO_MANY_REDIRECTS — redirect-loop oplossen na SSL of htaccess-wijziging

Je opent je site en je browser stopt met laden: "This page isn't working — [domain] redirected you too many times. ERR_TOO_MANY_REDIRECTS." De server stuurt je in een oneindige cirkel: A wijst naar B, B wijst terug naar A, en geen pagina komt ooit door. In 80% van de gevallen is dit een SSL- of htaccess-conflict dat met de juiste diagnose binnen 10 minuten op te lossen is. Deze gids loopt alle scenario's door.

13 min lezen · Laatst gecheckt:

De fout ziet er per browser net iets anders uit, maar het is altijd hetzelfde onderliggende probleem:

  • Chrome / Edge / Brave: "This page isn't working. [domain] redirected you too many times. Try clearing your cookies. ERR_TOO_MANY_REDIRECTS."
  • Firefox: "The page isn't redirecting properly. Firefox has detected that the server is redirecting the request for this address in a way that will never complete."
  • Safari: "Safari Can't Open the Page. Too many redirects occurred trying to open '...'. This might occur if you open a page that is redirected to open another page which then is redirected to open the original page."

De HTTP-status van elke stap in de keten is meestal 301 (permanent redirect) of 302 (tijdelijk). Browsers stoppen typisch na 20 redirects om bezoekers te beschermen tegen oneindige cirkels.

Stap 1: bekijk de redirect-keten met curl

Voor je iets aanpast: kijk wát er precies gebeurt. Open een terminal (Terminal op Mac, PowerShell op Windows, of SSH naar je hosting) en run:

curl -IL https://jouwsite.nl 2>&1 | grep -i "^location\|^HTTP"

Of, als je geen terminal-toegang hebt, gebruik httpstatus.io in je browser.

Een normale site geeft één redirect (HTTP → HTTPS, of www → non-www) en eindigt op 200 OK. Een redirect-loop ziet er bijvoorbeeld zo uit:

HTTP/1.1 301 Moved Permanently
Location: https://jouwsite.nl/

HTTP/1.1 301 Moved Permanently
Location: https://jouwsite.nl/

HTTP/1.1 301 Moved Permanently
Location: https://jouwsite.nl/
... (eindeloos)

Of, vaker:

HTTP/1.1 301 Moved Permanently
Location: https://www.jouwsite.nl/

HTTP/1.1 301 Moved Permanently
Location: https://jouwsite.nl/   (terug zonder www)

HTTP/1.1 301 Moved Permanently
Location: https://www.jouwsite.nl/  (weer mét www)

De keten zelf vertelt je vaak meteen welke twee redirects met elkaar in conflict zijn. Schrijf de URLs op die heen-en-weer wijzen.

De vijf meest voorkomende oorzaken

1. WordPress siteurl/home mismatch

Veruit de meest voorkomende oorzaak na een SSL-installatie. WordPress slaat de site-URL op twee plaatsen op: siteurl en home in de tabel wp_options. Als deze niet overeenkomen met de URL waarop je site werkelijk draait, krijg je een loop.

Symptoom: SSL geïnstalleerd, je opent https://jouwsite.nl, browser krijgt redirect terug naar http://jouwsite.nl, hosting redirect 't weer naar https://, oneindig.

Fix via wp-config.php (forceer de juiste URL's, bypassed de database-instelling):

// Boven "/* That's all, stop editing! */"
define('WP_HOME', 'https://jouwsite.nl');
define('WP_SITEURL', 'https://jouwsite.nl');

Of fix in de database via phpMyAdmin → tabel wp_options → wijzig de waarden van siteurl en home naar de juiste HTTPS-URL.

Of via WP-CLI (snelst):

wp option update home 'https://jouwsite.nl'
wp option update siteurl 'https://jouwsite.nl'

2. Cloudflare "Flexible SSL" mode mismatch

Klassieke valkuil. Cloudflare heeft vier SSL-modes:

  • Off: geen SSL via Cloudflare
  • Flexible: bezoeker → Cloudflare = HTTPS, Cloudflare → origin = HTTP
  • Full: HTTPS overal, certificaat op origin niet gevalideerd
  • Full (strict): HTTPS overal, geldig certificaat verplicht

Wat fout gaat: je staat op "Flexible". Bezoeker komt op https://jouwsite.nl, Cloudflare praat HTTP met je server, je server (of WordPress) zegt: "HTTP? Doe HTTPS!" en stuurt redirect naar https://. Cloudflare stuurt 'm door, server zegt opnieuw: "HTTP? Doe HTTPS!" — loop.

Fix: zet Cloudflare op Full of Full (strict) als je een geldig SSL-certificaat op je origin hebt. Cloudflare → SSL/TLS → Overview. Heb je nog geen origin-certificaat, gebruik Cloudflare's gratis Origin Certificate.

Zie ook SSL/TLS certificaten — Let's Encrypt vs betaald.

3. .htaccess force-HTTPS terwijl SSL niet werkt

Vooral op shared hosting: iemand voegt aan .htaccess toe:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

Dit werkt alleen als je server HTTPS daadwerkelijk goed afhandelt. Achter een reverse proxy (Cloudflare, Plesk-with-nginx-proxy) ziet de PHP-process soms HTTPS niet als "on" terwijl de bezoeker wél via HTTPS binnenkwam. Dan: redirect naar HTTPS → request komt op server alsnog als HTTP binnen → opnieuw redirect → loop.

Fix 1: gebruik X-Forwarded-Proto in plaats van HTTPS:

RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

Fix 2: laat Cloudflare/Plesk de HTTPS-redirect doen in plaats van .htaccess. Dubbel afdwingen op meerdere lagen veroorzaakt deze loops.

Zie ook .htaccess uitgelegd.

4. www vs non-www tegenstrijdigheid

Eén regel zegt "naar www", een andere zegt "weg met www". Vaak het gevolg van: hosting paneel staat op redirect naar non-www, en in .htaccess staat een handmatige regel naar www (of andersom).

Diagnose: in de curl-output zie je Location: https://www.jouwsite.nl/ afwisselen met Location: https://jouwsite.nl/.

Fix: kies één variant en haal alle tegenstrijdige regels weg:

  • WordPress wp_options siteurl/home — moet exact één variant gebruiken
  • .htaccess regels — alleen redirect in één richting
  • Hosting paneel — geen tegenstrijdige instelling
  • Cloudflare Page Rules — geen "altijd www" of "altijd non-www" naast je htaccess-regel

5. Plugin-conflict (Really Simple SSL, WP Force SSL, anderen)

SSL-plugins schrijven hun eigen redirects. Twee plugins die hetzelfde doen, of een plugin die conflicteert met je .htaccess of hosting force-HTTPS, geeft loops.

Fix: deactiveer alle SSL-gerelateerde plugins, beheer HTTPS op één plek (htaccess óf plugin óf hosting paneel — niet twee). Als je geen toegang tot wp-admin meer hebt: deactivate via FTP door wp-content/plugins/really-simple-ssl te hernoemen.

Specifiek scenario: net na SSL-installatie

Volgorde van checken:

  1. Browser cookies en cache wissen voor jouw domein. Cookies kunnen oude HTTPS-state vasthouden die confict geeft
  2. Test in incognito — schoon profiel, geen cookies/cache
  3. WordPress siteurl/home check — staan ze op https://? (zie scenario 1 hierboven)
  4. Cloudflare SSL-mode check — staat 'ie niet op Flexible? (scenario 2)
  5. htaccess-regels check — geen dubbele HTTPS-forces? (scenario 3)
  6. Hosting paneel — staat daar geen extra "force HTTPS" aan terwijl htaccess 't ook al doet?

Specifiek scenario: na een WordPress-migratie

Je hebt de site naar nieuwe hosting verhuisd, DNS staat goed, maar de site loopt in een loop. De boosdoeners op volgorde van waarschijnlijkheid:

  1. siteurl/home in database wijzen nog naar oud domein of oud protocol. Update via WP-CLI of phpMyAdmin (zie scenario 1)
  2. .htaccess uit oude hosting heeft hosting-specifieke directives die niet werken op nieuwe omgeving. Vervang door schone WordPress-default .htaccess
  3. Hardcoded URLs in andere tabellen (postmeta, options, custom tables). Run een search-and-replace tool zoals WP-CLI's wp search-replace of de gratis "Better Search Replace" plugin

Zie ook website migreren zonder downtime voor de volledige migratie-aanpak die deze valkuilen voorkomt.

Specifiek scenario: redirect-loop alleen op /wp-admin/

Site werkt voor bezoekers, maar inloggen op wp-admin geeft een loop. Bekende oorzaken:

  • Cookie-domein klopt niet. In wp-config.php staat een verkeerde COOKIE_DOMAIN. Verwijder die regel — WordPress detecteert 'm zelf goed
  • Force-SSL voor admin-only conflicteert. Check of er staat: define('FORCE_SSL_ADMIN', true); en je site SSL niet helemaal goed afhandelt op admin-niveau
  • Caching plugin cached login-pagina. Wissel cache, sluit /wp-admin/ uit van caching

Schone fallback: minimale .htaccess voor WordPress

Als je twijfelt of jouw .htaccess het probleem is, vervang 'm tijdelijk door de WordPress-default. Eerst: kopieer de oude weg (hernoem naar .htaccess.backup). Dan plaats deze:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Werkt de site weer normaal? Dan zat het probleem in jouw oude .htaccess. Voeg regels één voor één terug en test telkens.

Niet-WordPress sites — Joomla, Drupal, OpenCart, custom PHP

Hetzelfde principe, andere plek voor de site-URL:

  • Joomla: configuration.php → $live_site + $force_ssl
  • Drupal: sites/default/settings.php → $base_url en eventuele HTTPS-redirect-instellingen
  • OpenCart: config.php + admin/config.php → de URL-constanten (HTTP_SERVER, HTTPS_SERVER)
  • Custom PHP: zoek in code op header('Location: en check redirect-logica

Plus altijd: .htaccess, Cloudflare-mode, hosting-redirect-instelling. De keten is bij elke CMS dezelfde.

Diagnose-checklist op één plek

  1. Curl-output van curl -IL https://jouwsite.nl — bekijk de keten van redirects
  2. Browser devtools → Network tab → herlaad pagina → bekijk de "Status" kolom voor patronen
  3. Cookies en cache wissen voor jouw domein — soms is dat al genoeg
  4. Incognito test — sluit cookies/cache uit als oorzaak
  5. Cloudflare aan? Check SSL-mode (moet Full of Full strict zijn met geldig origin-cert)
  6. WordPress: WP_HOME / WP_SITEURL in wp-config.php tijdelijk hardcoden om DB-instellingen te overrulen
  7. .htaccess hernoemen naar .htaccess.bak en testen met schone default
  8. SSL-plugins (Really Simple SSL, etc.) tijdelijk deactiveren
  9. Hosting paneel: zit er een force-HTTPS-instelling die conflicteert met je htaccess?
Tip: kies één plek waar HTTPS afgedwongen wordt. Of in .htaccess. Of in een WordPress-plugin. Of via Cloudflare. Of in je hosting paneel. Op meerdere plekken tegelijk is de hoofdoorzaak van 90% van de loops in mijn praktijk.

Wanneer is het géén lokale loop maar iets anders?

Niet elke "too many redirects"-melding is een server-loop. Soms is 't een browser- of cookie-issue:

  • Werkt 't in incognito wel? Dan is 't een cookie of cache-probleem op één browser. Cache + cookies wissen lost 't op
  • Werkt 't op andere apparaten wel? Lokaal probleem: VPN, antivirus die HTTPS injecteert (Kaspersky, Avast), of een browser-extensie
  • Werkt 't bij jou wel maar bij anderen niet? Dan is 't echt een server-loop voor het publiek — handelen geboden

Wanneer schakel je hulp in?

  • Site is al uren in een redirect-loop en je weet niet waar de keten vandaan komt
  • WordPress wp_options aangepast, .htaccess vervangen, plugins uit — en de loop blijft
  • Cloudflare actief, SSL mode al op Full gezet, en het werkt nog steeds niet
  • Site loopt prima maar /wp-admin/ blijft loopen — login niet mogelijk
  • Net SSL geïnstalleerd via Let's Encrypt of betaald cert en de hele site is nu down
  • Migratie net afgerond, alle URLs lijken goed, maar bezoekers krijgen ERR_TOO_MANY_REDIRECTS
  • Je hebt geen toegang tot phpMyAdmin, FTP of SSH om te diagnosticeren

Een redirect-loop is in 90% van de gevallen één tegenstrijdige regel of instelling. Met de curl-aanpak en de checklist hierboven vind je 'm meestal binnen 15 minuten. Voor de overige 10% — Cloudflare-met-reverse-proxy-met-WordPress-plugin-met-htaccess — is 't een diagnose-puzzel waar ervaring helpt.