URL-redirects controleren en redirectketens lezen

De link waarop je klikt, is vaak niet de pagina die je krijgt. Daartussen kunnen een upgrade naar HTTPS, een andere host, een trackingdienst, een URL-verkorter en een CMS-regel zitten die een trailing slash (de afsluitende slash aan het eind van een URL) toevoegt. Elk daarvan is een apart verzoek dat je browser doet zonder het je te vertellen.

In deze gids lees je hoe je die stappen zichtbaar maakt met TrueURL, curl en de DevTools van je browser, wat elk onderdeel van een redirectketen betekent en hoe je de meest voorkomende problemen oplost.

Wat een redirectketen is

Een redirect (doorverwijzing) ontstaat wanneer een server antwoordt met een 3xx-statuscode en een Location-header die een andere URL noemt. De client, een browser of een crawler, vraagt vervolgens die URL op en herhaalt dat tot er een response komt die geen redirect is.

Elk verzoek vormt samen met de bijbehorende response één hop (één stap in de keten). De hele reeks van de eerste URL tot de laatste response is de redirectketen:

#  URL                              Status  Location
1  http://example.com/Shoes         301     https://example.com/Shoes
2  https://example.com/Shoes        301     https://www.example.com/Shoes
3  https://www.example.com/Shoes    302     /shoes/
4  https://www.example.com/shoes/   200

Dat zijn drie redirects en vier verzoeken om één pagina te bereiken. De Location bij hop 3 is relatief: clients lossen die op ten opzichte van de URL die ze net hebben opgevraagd, zoals RFC 9110 voorschrijft, dus de hop verwijst in feite naar https://www.example.com/shoes/. Idealiter zou elk van deze adressen de eind-URL in één hop bereiken.

Een pagina kan ook doorsturen nadat ze met 200 OK heeft geantwoord, via een <meta http-equiv="refresh">-tag of JavaScript. Ook zulke client-side redirects horen bij de keten, maar tools die alleen HTTP-headers lezen, zoals curl, stoppen bij die pagina.

Waarom je redirects moet controleren

SEO: canonieke signalen en crawlbudget

Zoekmachines lezen een redirect als een uitspraak over welke URL ze moeten indexeren. Google behandelt permanente redirects (301 en 308) als een sterk signaal dat het doel de canonieke URL moet zijn, en tijdelijke redirects (302, 303 en 307) als een zwak signaal. Een pagina die definitief is verhuisd, maar achter een 302 zit, kan daardoor met haar oude URL in de zoekresultaten blijven staan.

Ook de lengte telt. Googlebot volgt maximaal 10 redirecthops; heeft hij dan nog geen content, dan meldt Search Console een redirectfout. De gids van Google over crawlbudget raadt bovendien lange redirectketens af, omdat die volgens Google een negatief effect op het crawlen hebben.

Paginasnelheid

De eindpagina kan pas beginnen met laden als de laatste redirect is beantwoord. Elke hop kost een roundtrip over het netwerk, en een hop naar een nieuwe host vraagt bovendien een DNS-lookup, een nieuwe verbinding en, bij HTTPS, een TLS-handshake. Op mobiele verbindingen kunnen drie of vier redirects enkele honderden milliseconden toevoegen voordat de eerste byte van de echte pagina binnenkomt. De Redirectlatentie-checker laat zien wat elke hop kost.

Veiligheid van verkorte en onbekende links

Verkorte links en veel trackinglinks in e-mails verbergen hun bestemming. Phishingcampagnes misbruiken bovendien open redirects op bekende domeinen, zodat een link die op een betrouwbare site begint, ergens heel anders kan eindigen. De Korte-URL-expander toont elk domein onderweg, en of een hop terugvalt van HTTPS naar gewoon HTTP, nog voordat je klikt.

Affiliate- en trackinglinks

Marketinglinks lopen vaak via meerdere diensten voordat ze op de landingspagina uitkomen. Elke dienst moet de querystring doorgeven, anders gaan UTM-parameters, klik-ID’s en affiliatetags ongemerkt verloren. Aan de eind-URL zie je of ze de keten hebben overleefd en of de link nog op de bedoelde pagina uitkomt.

Migraties, HTTPS en de canonieke host

Na een redesign, een domeinverhuizing of de overstap naar HTTPS moet elke oude URL zijn nieuwe tegenhanger in één permanente redirect bereiken. De vier basisvarianten van een site (http:// en https://, met en zonder www) moeten allemaal op één canoniek adres uitkomen. Zulke regels gaan geruisloos stuk: een nieuwe CDN-regel, een update van een plug-in of een serververhuizing kan een hop of een loop toevoegen zonder dat iemand het ziet.

Een redirect controleren met TrueURL

TrueURL voert elke controle uit op het edge-netwerk van Cloudflare, dus je kunt links die je niet vertrouwt inspecteren zonder ze in je browser te openen. De Redirectchecker op de homepage controleert één URL; de Redirectketen-checker en de andere gespecialiseerde tools gebruiken dezelfde engine.

Stap 1: voer de URL in

Plak de URL en start de controle. Zonder schema wordt https:// aangenomen; typ http:// om gewoon HTTP te testen.

Stap 2: pas zo nodig de Geavanceerde instellingen aan

Standaard stuurt de checker een GET-verzoek met een actuele user-agent van Chrome voor desktop, zonder cookies en met een limiet van 20 redirects. Met Geavanceerde instellingen verander je dat:

• HTTP-methode: GET, HEAD of POST. HEAD is lichter, maar sommige servers beantwoorden een HEAD-verzoek anders, en zonder body kunnen client-side redirects niet worden gedetecteerd. POST stuurt de body mee die je invult, voor formulierverwerking en API’s. Volgende hops volgen de regels van browsers: na een POST gaat een 301 of 302 verder als GET, een 303 doet dat altijd, en 307 en 308 behouden de methode en de body.
• Max. aantal hops: het aantal redirects dat wordt gevolgd, van 1 tot 50. De standaardwaarde van 20 is de limiet in de Fetch Standard en in Chrome en Firefox. Zet de waarde op 10 om te zien of een keten binnen de limiet van Googlebot blijft.
• Aangepaste user-agent: leeg betekent Chrome voor desktop. Voorinstellingen zijn onder meer Safari op iPhone, Chrome op Android, Googlebot (smartphone en desktop), Bingbot, de linkpreviewbots van Facebook en X, en curl.
• Aangepaste requestheaders: extra headers die bij elke hop worden meegestuurd, bijvoorbeeld Accept-Language: fr-FR om een taalredirect uit te lokken.
• Cookies: vul name=value; other=value in om een ingelogde sessie, een cookietoestemming of een regio na te bootsen. Cookies die onderweg in de keten worden gezet, blijven bewaard voor de volgende hops, net als in een browser.
• Client-side redirects: volg meta-refresh-tags en eenvoudige JavaScript-redirects, of meld ze alleen.
• SSL-fouten negeren: de edge van Cloudflare valideert certificaten altijd, dus hiermee kun je een ongeldig certificaat niet overslaan. Een TLS-fout wordt gemeld bij de hop waar die optrad.

Stap 3: lees het resultaat

Het resultaat begint met de eind-URL en de bijbehorende statuscode. In de keten eronder staat één rij per hop, met:

• de opgevraagde URL en de gebruikte HTTP-methode;
• de statuscode met de statustekst (reason phrase); het overzicht van HTTP-statuscodes legt elke code uit;
• de responstijd, vanaf het versturen van het verzoek tot de headers binnen waren, inclusief een eventuele DNS-lookup en het opzetten van de verbinding;
• de Location waarnaar de hop verwijst;
• de responseheaders en de namen van eventuele cookies die de hop heeft gezet.

Bij elke redirect staat hoe die tot stand kwam: via een HTTP-statuscode, een meta refresh (met de vertraging in seconden) of JavaScript. Ook client-side redirects die wel zijn gevonden maar niet gevolgd, worden gemeld. Minstens zo belangrijk is hoe de controle eindigde:

Waarschuwingen markeren een tijdelijke redirect in de keten, een downgrade van HTTPS naar HTTP, meer dan drie redirects, een eind-URL op een ander domein, client-side redirects en HEAD-verzoeken die geen paginabody konden lezen.

Eén waarschuwing vraagt extra aandacht. Sommige sites leggen geautomatiseerd verkeer of verkeer uit datacenters eerst een botcontrole voor, zoals de pagina “Just a moment...” van Cloudflare. TrueURL markeert responses die daarop lijken, omdat de controle dan bij de beveiligingslaag van de site is uitgekomen en niet bij de bestemming. Een echte bezoeker kan ergens anders uitkomen.

Redirects controleren via de commandline

curl is standaard geïnstalleerd op macOS, Windows 10 en 11 en de meeste Linux-distributies, en laat precies zien wat de server stuurt, zonder dat er een browsercache meespeelt. De voorbeelden gaan uit van een Unix-shell. Typ in Windows PowerShell 5.1 curl.exe, omdat curl daar een alias is voor Invoke-WebRequest, en schrijf NUL in plaats van /dev/null.

Eén hop bekijken

curl -I https://example.com/old-page

-I stuurt een HEAD-verzoek en toont de responseheaders, inclusief de statusregel en een eventuele Location. curl volgt redirects alleen als je daarom vraagt. Omdat sommige servers HEAD anders behandelen, herhaal je de controle als GET wanneer het resultaat vreemd lijkt; -o /dev/null gooit de body weg en -D - toont de headers:

curl -sS -o /dev/null -D - https://example.com/old-page

De hele keten volgen

-L volgt redirects, en met -I of -D - toont curl de headers van elke hop. Met een grep-filter houd je een compact overzicht over:

curl -sIL http://example.com/Shoes | grep -iE '^(HTTP/|location:)'

HTTP/1.1 301 Moved Permanently
Location: https://example.com/Shoes
HTTP/2 301
location: https://www.example.com/Shoes
HTTP/2 302
location: /shoes/
HTTP/2 200

curl volgt standaard maximaal 50 redirects; met --max-redirs 10 pas je de limiet van Googlebot toe.

Alleen de eind-URL tonen

Met de optie -w (write-out) toont curl na de overdracht details over het verzoek. Zo wordt curl een compacte URL-expander:

curl -sSL -o /dev/null -w '%{http_code} %{num_redirects} %{url_effective}\n' https://example.com/go

%{url_effective} is de laatst opgehaalde URL, %{num_redirects} het aantal gevolgde redirects en %{http_code} de eindstatus. %{time_redirect} geeft het aantal seconden dat aan redirects is besteed vóór het laatste verzoek. Zonder -L laat %{redirect_url} zien waar de eerste redirect naartoe zou leiden.

POST-verzoeken testen

-d stuurt een body mee en maakt van het verzoek een POST. Bij het volgen van redirects gedraagt curl zich dan als een browser: na een 301, 302 of 303 schakelt het over op GET, en na een 307 of 308 stuurt het de POST met de body opnieuw.

curl -sSL -o /dev/null -D - -d 'email=test%40example.com' https://example.com/subscribe

Combineer -X POST liever niet met -L. -X dwingt de methode af bij elk verzoek, dus curl blijft POST sturen na een 301, 302 of 303, waar een browser zou overschakelen op GET. Je test dan een keten die geen enkele echte client produceert.

User-Agent, headers en cookies wijzigen

# User-Agent van een smartphone
curl -sIL -A 'Mozilla/5.0 (iPhone; CPU iPhone OS 18_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.0 Mobile/15E148 Safari/604.1' https://example.com/

# Extra requestheader
curl -sIL -H 'Accept-Language: de-DE,de;q=0.9' https://example.com/

# Cookie meesturen en de cookies uit de keten bewaren
curl -sSL -o /dev/null -D - -b 'consent=yes' -c cookies.txt https://example.com/

-A stelt de User-Agent in, -H voegt een header toe en -b stuurt cookies mee. -c slaat ontvangen cookies op in een bestand en zet de cookie-engine van curl aan, zodat een cookie die door de ene hop wordt gezet, bij de volgende wordt meegestuurd.

curl voert geen JavaScript uit en reageert niet op meta-refresh-tags. Is de laatste response een HTML-pagina met 200 OK, maar komt je browser ergens anders uit, dan gebeurt de redirect in de browser (client-side).

Redirects controleren in de DevTools van je browser

DevTools toont de keten zoals je eigen browser die ziet, met je cookies, extensies en locatie:

1. Open DevTools (F12, of Cmd+Option+I op een Mac) en kies het tabblad Network.
2. Zet in Chrome en Edge Preserve log aan, of in Firefox Persist Logs in het menu met netwerkinstellingen. Anders wordt de lijst bij elke paginalading gewist en verdwijnen client-side redirects uit beeld.
3. Zet Disable cache aan, zodat een redirect uit de cache niet verbergt wat de server vandaag stuurt.
4. Voer de URL in de adresbalk in.

Elke hop verschijnt als een eigen rij met de 3xx-status. Selecteer de rij en open Headers om de responseheader location te zien. Staat in Chrome “(disk cache)” of “(memory cache)” in de kolom Size, dan kwam de redirect uit de cache en niet van de server.

Chrome toont soms een 307 Internal Redirect van http:// naar https://. Die heeft de server nooit gestuurd: de browser heeft het verzoek zelf geüpgraded, meestal omdat hij een HSTS-beleid voor de site heeft opgeslagen. Wil je zien wat de server met gewoon HTTP doet, gebruik dan curl of TrueURL.

Veelvoorkomende redirectproblemen en hoe je ze oplost

Ketens van meer dan één hop

Ketens groeien laag voor laag: een regel uit een oude migratie verwijst naar een URL die bij een latere migratie opnieuw is doorgestuurd. Laat elke regel rechtstreeks naar de eindbestemming wijzen, en werk interne links, canonical tags, hreflang-annotaties en sitemaps bij, zodat je eigen site nooit zelf een redirect veroorzaakt. De Bulk-redirectchecker laat zien welke oude URL’s nog meer dan één hop nodig hebben.

Redirectloops

Chrome meldt een loop als “te vaak omgeleid” (ERR_TOO_MANY_REDIRECTS); Firefox meldt dat de pagina niet goed doorverwijst. Veelvoorkomende oorzaken:

• HTTPS achter een proxy of CDN. De originserver stuurt HTTP door naar HTTPS, maar de proxy maakt via gewoon HTTP verbinding met de origin. Die ziet dus nooit HTTPS en blijft eindeloos doorsturen. Bij Cloudflare is dit het klassieke gevolg van de SSL/TLS-modus Flexible; gebruik Full (strict), of laat de origin X-Forwarded-Proto controleren.
• Twee lagen die het oneens zijn, zoals een CDN-regel die www verwijdert terwijl de server het juist toevoegt, of een framework dat een trailing slash toevoegt die het CDN weer weghaalt.
• Redirects die van cookies afhangen. Een login- of toestemmingspagina stuurt bezoekers terug naar de oorspronkelijke URL, die hen opnieuw naar de loginpagina stuurt omdat de cookie niet is opgeslagen.

De Redirectloop-checker laat zien welke hop de loop sluit. Maak daarna per regel één laag verantwoordelijk.

301 en 302 gemengd in één keten

Een keten van 301, dan 302, dan 200 is een permanente verhuizing met een tijdelijke stap in het midden. Vaak zit er een standaardwaarde achter: res.redirect() in Express en header('Location: ...') in PHP sturen allebei een 302, tenzij je iets anders opgeeft. Gebruik bij elke hop een permanente code en controleer dat met de 301-redirectchecker. Onze gids over HTTP-statuscodes voor redirects legt uit wanneer welke code past.

Dubbele hops van HTTP naar HTTPS naar www

Een heel gebruikelijke keten is http://example.com → https://example.com → https://www.example.com: twee hops waar één zou volstaan. Stuur elke niet-canonieke variant rechtstreeks door naar de uiteindelijke HTTPS-URL en test daarna alle vier met de HTTPS-redirectchecker.

Eén uitzondering is bewust. Is www je canonieke host en voeg je het domein toe aan de HSTS-preloadlijst, dan eist hstspreload.org dat http://example.com eerst doorstuurt naar https://example.com, zodat browsers het HSTS-beleid voor het kale domein vastleggen.

Inconsistente trailing slashes

/pricing en /pricing/ zijn verschillende URL’s. Geven ze allebei 200 OK, dan heb je duplicate content (dubbele content); sturen twee lagen ze naar elkaar door, dan heb je een loop. Kies één vorm, stuur de andere daar met één 301 naartoe en link consequent. De Trailing-slash-checker test beide vormen tegelijk.

Redirects die alleen op mobiel optreden

Aparte mobiele sites, prompts om een app te installeren en apparaatdetectie sturen telefoons soms ergens anders heen, vaak naar de mobiele homepage in plaats van naar de overeenkomstige pagina. Bij mobile-first indexering crawlt Google vooral met zijn smartphonecrawler, dus voor de indexering telt de mobiele keten het zwaarst. Vergelijk beide met Redirects mobiel vs. desktop.

Redirects in sitemaps

Een sitemap hoort de canonieke URL’s te bevatten die je in de zoekresultaten wilt zien, en die geven 200 OK. Items die doorsturen, verspillen crawlverzoeken en geven tegenstrijdige canonieke signalen. Draai na elke migratie de Sitemap-redirectchecker en vervang elk item dat doorstuurt door de eind-URL.

JavaScript- en meta-refresh-redirects

Google behandelt een directe meta refresh als een permanente redirect en een vertraagde als een tijdelijke. JavaScript-redirects ziet Google pas na het renderen van de pagina, een stap die na het crawlen komt en kan mislukken. Veel andere crawlers, linkpreviewbots en commandlinetools voeren helemaal geen JavaScript uit, en sommige negeren ook meta refresh. Gebruik server-side redirects overal waar je de server zelf beheert, en spoor client-side redirects op met de Meta-refresh-checker.

Checklist voor redirects

Loop deze lijst door na een migratie of een CDN-wijziging, en vóór de lancering van een campagne:

1. Elke oude URL bereikt zijn eindbestemming in één hop.
2. Permanente verhuizingen gebruiken bij elke hop 301 of 308.
3. Alle vier varianten van protocol en host eindigen op de canonieke HTTPS-URL.
4. Geen enkele hop gaat van HTTPS naar HTTP.
5. Querystrings, inclusief UTM-parameters en affiliate-ID’s, overleven de keten.
6. Elke URL bestaat in één vorm, met of zonder trailing slash, en de andere vorm stuurt daarnaar door.
7. Verzoeken van desktop, smartphone en Googlebot eindigen op gelijkwaardige pagina’s.
8. Server-side redirects vervangen meta refresh en JavaScript waar dat kan.
9. Interne links, canonical tags, hreflang en sitemaps verwijzen naar eind-URL’s.
10. Verwijderde pagina’s zonder vervanger geven 404 of 410 terug in plaats van door te sturen naar de homepage.
11. Redirects van een siteverhuizing blijven staan; Google raadt minstens een jaar aan.