Wat is een redirect? Uitleg van redirects (301 versus 302)

TL;DR: Met redirecten wordt bedoeld dat één URL automatisch bezoekers en zoekmachines doorstuurt naar een andere URL. Gebruik 301 voor een permanente verhuizing en 302 voor een tijdelijke. Redirects verliezen niet per definitie PageRank, maar ketens, loops, kapotte bestemmingen en irrelevante redirects naar de homepage kunnen nog steeds echte SEO- en gebruiksproblemen veroorzaken.

Wat betekent redirecten?

Een redirect is een instructie die zegt: “Die URL is verhuisd. Ga in plaats daarvan naar deze URL.”

Technisch gezien vraagt een browser een adres op en kan de server antwoorden met een 3xx HTTP-statuscode plus een Location-header met een ander adres. Vervolgens vraagt de browser automatisch die bestemming opnieuw aan. Crawlers van zoekmachines kunnen dezelfde instructie volgen.

De praktische betekenis van redirecten is eenvoudiger: de oude URL levert niet langer zijn eigen content; hij stuurt het verzoek door naar een nieuwe URL.

Redirects zijn nodig omdat URL’s veranderen. Pagina’s worden hernoemd, producten worden verwijderd, sites verschuiven van HTTP naar HTTPS, overlappende artikelen worden samengevoegd en domeinen worden vervangen. Zonder redirect komt iemand die het oude adres volgt meestal uit op een 404. Backlinks blijven naar een verlaten URL wijzen en Google ontvangt geen expliciete routing-instructie die de oude pagina verbindt met de vervanger.

We hebben dit direct aangepakt toen Lida en ik SEOJuice migreerden van seojuice.io naar seojuice.com in januari 2026. Een domeinmigratie maakt het doel van redirects ongewoon duidelijk: elk oud pad moet een bewuste bestemming krijgen, niet alleen een regel die het domein ergens “redelijk” naartoe stuurt. Met een team van twee personen was er geen plek om het denkwerk te delegeren; de redirect-map moest worden behandeld als onderdeel van de migratie zelf (niet als de administratieve taak erna).

Dit onderscheid doet ertoe. Een oud artikel redirecten naar het bijbehorende equivalent op het nieuwe domein behoudt de route. Alle oude adressen redirecten naar de nieuwe homepage verbergt alleen dat de routes ontbreken.

301 vs 302: permanent is de echte beslissing

Het verschil tussen een 301 en een 302 is niet dat de ene “SEO-vriendelijk” is en de andere slecht. Elke code communiceert een andere verwachting over wat er vervolgens gebeurt.

Een 301-redirect betekent dat de verhuizing permanent is. Een 302-redirect betekent dat de verhuizing tijdelijk is en dat de originele URL terugkomt. Google volgt beide, maar interpreteert de canonical-signalen niet op dezelfde manier.

“Googlebot volgt de redirect, en de indexing-pipeline gebruikt de redirect als signaal dat de redirectbestemming canoniek moet zijn.”

Voor tijdelijke redirects: “Googlebot volgt de redirect, maar de indexing-pipeline gebruikt de redirect niet als signaal dat de redirectbestemming canoniek moet zijn.”

Dit zijn de eigen beschrijvingen van Google Search Central in de documentatie Redirects and Google Search.

Vertaald naar praktische SEO vraagt een permanente redirect Google om de oude URL in zijn index te vervangen door de bestemming. Een tijdelijke redirect stuurt gebruikers naar de bestemming terwijl de oorspronkelijke URL doorgaans canoniek blijft. Als canonicals het verwarrende stuk zijn, dan behandelt onze handleiding over hoe Google-indexering werkt hoe crawlen, canonical selection en indexering samenkomen.

Gebruik een 301 voor permanente wijzigingen in URL’s

Een 301 is de gangbare keuze voor een normale content-URL die permanent is verplaatst. Typische situaties zijn:

• Een pagina hernoemen of de URL-slug wijzigen
• Van HTTP naar HTTPS verhuizen
• Standaardiseren op óf www óf niet-www
• Verhuizen naar een ander domein
• Dubbele of overlappende pagina’s samenvoegen
• Een oude pagina vervangen door een echt gelijkwaardig opvolger

Google adviseert om zo vaak mogelijk een permanente server-side redirect te gebruiken wanneer een URL moet veranderen in zoekresultaten. Ze noemen dit de beste manier om ervoor te zorgen dat zowel mensen als Google Search de juiste pagina bereiken.

Hier is dezelfde ene permanente redirect in de twee meestgebruikte webservers:

# Nginx — redirect één oude URL naar zijn nieuwe thuis
location = /old-page/ {
    return 301 https://example.com/new-page/;
}

# Apache (.htaccess) — de equivalente regel in één regel
Redirect 301 /old-page/ https://example.com/new-page/

Het woord gelijkwaardig doet hier echt werk. Een verwijderd product wordt niet automatisch gelijkwaardig aan je homepage, alleen omdat beide URL’s bij hetzelfde bedrijf horen.

Gebruik een 302 als de originele URL terugkomt

Een 302 past bij een tijdelijke onderhoudspagina, een experiment, een tijdelijke seizoenspagina-overneme of een routing die je verwacht terug te draaien. Het vertelt Google dat de bestemming niet bedoeld is om de permanente vervanging te worden.

Als een pagina “goed” is verhuisd maar achter een 302 blijft hangen, kan Google blijven indexeren op het oude adres. De redirect kan er in een browser perfect functioneel uitzien, terwijl hij wél het verkeerde indexeringsdoel communiceert (een handige reminder dat “het laadt” geen volledige redirect-test is).

Kies op basis van de vraag of je van plan bent de wijziging terug te draaien. Permanent betekent 301; tijdelijk betekent 302. Onze aparte vergelijking van 301 vs 302 redirects behandelt ook de minder voor de hand liggende migratie- en canonicalizatiecases.

Wat met 303, 307 en 308 redirects?

De meeste redactionele en marketingwebsites kunnen jarenlang met 301- en 302-redirects uit de voeten zonder de andere codes nodig te hebben. Het belang van het onderscheid wordt groter rond formulieren, API’s en andere verzoeken die niet via GET gaan.

Zoals gedocumenteerd in de guide to HTTP redirections van MDN Web Docs, dragen 301 en 302 historisch wat ambiguïteit rondom request-methodes. Sommige clients kunnen een POST-verzoek omzetten naar een GET terwijl ze de redirect volgen.

Dat gedrag is vaak onschadelijk bij een normale paginaweergave. Het is niet onschadelijk als een endpoint verwacht dat er een request body meegaat.

307 behoudt het verzoek tijdelijk

Een 307 Temporary Redirect drukt dezelfde tijdelijke intentie uit als een 302, maar garandeert dat de HTTP-methode en body behouden blijven. Een POST blijft een POST na de redirect.

308 behoudt het verzoek permanent

Een 308 Permanent Redirect is de tegenhanger die de methode behoudt van een 301. MDN legt uit dat “308 is gemaakt om de ambiguïteit weg te nemen van het gedrag bij het gebruik van niet-GET-methodes.”

Bij een gewone contentpagina die met GET wordt opgevraagd, zien gebruikers weinig praktisch verschil tussen 301 en 308. Dat geldt ook voor 302 en 307. Het behouden van de methode wordt vooral relevant bij POST- en PUT-verzoeken, formulieren en API’s (op dat moment zou ik iemand betrekken die de backend beheert in plaats van een status uit een SEO-rapport te kiezen).

303 wijzigt de request bewust naar GET

Een 303 See Other redirect is tijdelijk en laat de volgende request bewust als GET uitvoeren. Een veelvoorkomend gebruik is iemand van een ingestuurd formulier naar een aparte bevestigings- of resultatpagina sturen, zodat een refresh niet opnieuw dezelfde oorspronkelijke POST verstuurt.

Dit is in de eerste plaats HTTP-gedrag en pas in de tweede plaats SEO-gedrag. Maak normale paginaredirects niet exotischer dan nodig.

Server-side redirects winnen het van browser-workarounds

Redirects met HTTP-status gebeuren server-side. Er bestaan ook twee client-side alternatieven: HTML meta refresh en JavaScript-redirects.

Een meta refresh draait nadat een HTML-document begint te laden. MDN zegt om de delay op nul te zetten voor toegankelijkheidscompliance en waarschuwt dat HTTP- en HTML-redirectregels die niet synchroon lopen een oneindige loop of “andere nachtmerries” kunnen veroorzaken. De formulering blijft hangen omdat het probleem echt is: twee apart beheerde lagen voor routing kunnen na een verder routinematige CMS-wijziging met elkaar gaan botsen.

Een JavaScript-redirect hangt af van de client die JavaScript uitvoert. Google Search Central stelt: “Gebruik alleen JavaScript-redirects als je geen server-side of meta refresh-redirects kunt doen. Hoewel Google probeert elke URL die Googlebot crawlt te renderen, kan het renderen om verschillende redenen mislukken.”

Mijn volgorde van voorkeur is:

1. Een server-side HTTP-redirect met de juiste permanente of tijdelijke status
2. Een meta refresh met nul seconden als serverconfiguratie niet beschikbaar is
3. Alleen een JavaScript-redirect als geen van de opties hierboven mogelijk is

Niet elke (statische) hosting of beperkte CMS-omgeving biedt de ideale serverlaag. Die beperking is echt. Maar dat een browser uiteindelijk de bestemming bereikt is niet hetzelfde als een schone redirect die elke client consistent kan interpreteren.

Verliezen redirects PageRank?

Een oude SEO-regel stelde dat elke redirect een vast percentage van “link juice” verliest. Die percentages blijven rondzingen, maar ze zouden geen leidraad mogen zijn voor implementatiekeuzes. Ze worden niet ondersteund door het huidige standpunt van Google.

“30x redirects verliezen niet langer PageRank.”

Gary Illyes van Google deed die uitspraak in 2016, zoals gerapporteerd door Search Engine Land. De logische conclusie is beperkt maar belangrijk: het enkele feit dat je een 301, 302 of een andere 30x-redirect gebruikt, betekent niet automatisch een PageRank-straf.

Het volgt niet dat 301 en 302 uitwisselbaar zijn.

Een 301 vertelt Google om de bestemming te behandelen als de permanente, canonieke vervanging. Een 302 laat meestal de oorspronkelijke URL canoniek, omdat de move tijdelijk is. PageRank-afhandeling en canonical intent hangen samen, maar het is niet dezelfde vraag.

Ook zou ik niet beloven dat een domeinmigratie elke ranking zonder schommelingen behoudt. Redirects geven een belangrijk signaal, maar Google moet nog steeds URL’s opnieuw crawlen, canonicals verwerken en zijn index bijwerken. Schone routing haalt één grote bron van ambiguïteit weg; het “bevriest” zoekresultaten niet.

De redirect-fouten die echte schade veroorzaken

Redirect chains

Een redirect chain stuurt een verzoek via meerdere URL’s:

URL A → URL B → URL C → URL D

De schonere route is URL A direct naar URL D. Als B en C intern nog gelinkt zijn, werk die links ook bij naar D.

Elke stap voegt een extra request toe, kost crawlerbronnen en maakt nog een regel die kan falen. Lange ketens brengen bovendien het risico met zich mee dat de uiteindelijke bestemming niet wordt bereikt tijdens een specifieke crawl. Herhaal dat over duizenden pagina’s en dan wordt het een echt crawl-budgetprobleem, niet alleen een cosmetische auditwaarschuwing.

Er is geen noodzaak om een verzonnen PageRank-verliespercentage aan elke stap te koppelen. Meer requests, tragere routing, verspilde crawling en extra faalpunten zijn al genoeg redenen om de keten in te korten.

Redirect loops

Een loop stuurt het verzoek in een cirkel, zoals A → B → A. Browsers stoppen uiteindelijk en tonen een foutmelding als “te veel redirects”. De content is niet bereikbaar voor zowel gebruikers als crawlers.

Loops ontstaan vaak door conflicterende regels: een HTTPS-regel die vecht met een hostnaam-regel, een trailing-slash-regel die een andere redirect terugdraait, of een meta refresh die niet hetzelfde beweert als de server. De uiteindelijke browserfout verbergt het pad, dus controleer elke response in plaats van de pagina telkens opnieuw te refreshen (of, vaker dan ik zou willen, caches te wissen en te hopen).

Elke verwijderde URL redirecten naar de homepage

Dit is geen opruimstrategie. Je vervangt een duidelijke “pagina bestaat niet”-response door een irrelevante bestemming.

Google’s soft-404 guidance legt uit dat redirects naar irrelevante pagina’s kunnen worden geïnterpreteerd als soft 404’s. Redirect een oude URL alleen als er echt een relevante vervanging bestaat. Als die er niet is, geef dan een echte 404 of 410 terug.

Een stopgezet product kan redelijkerwijs redirecten naar zijn directe opvolger of, in sommige gevallen, naar een strak gerelateerde categorie. Het mag gebruikers niet automatisch naar een generieke homepage sturen die de request niet beantwoordt.

Gemengde protocol- en hostnaamvarianten

Als HTTP, HTTPS, www en niet-www allemaal dezelfde content serveren, dan concurreren meerdere adressen om dezelfde pagina voor te stellen. Kies één canonieke host en één protocol, en redirect alle alternatieven permanent direct daarnaar.

Test elke combinatie. Een HTTP-regel kan op zichzelf correct werken, maar problemen geven wanneer je hem combineert met de hostnaam-regel: een extra stap of zelfs een loop.

Redirects die eindigen op een error

Een redirect is niet “geslaagd” omdat zijn eerste response een 301 is. De uiteindelijke bestemming moet een werkende response teruggeven.

Een 301 die naar een 404 leidt blijft kapot voor de persoon die hem volgde. Een redirect die eindigt op een response uit de 500-serie is evenmin beter. Daarom mist een check alleen van de initiële statuscode een aanzienlijk deel van het routeverhaal.

Hoe je redirectproblemen vindt en oplost

Begin met een crawler zoals Screaming Frog, Ahrefs Site Audit of de audit van SEOJuice. Crawl de bron-URL’s en volg elke route tot de uiteindelijke response. Let op:

• Redirect chains met meerdere hops
• Redirect loops
• Redirects die eindigen op een 4xx- of 5xx-response
• Interne links die nog steeds naar redirected URL’s wijzen
• Permanente verplaatsingen die met tijdelijke redirects zijn geïmplementeerd

Op basis van wat we bij SEOJuice over sites heen zien, krijgen interne links die naar al-redirected URL’s wijzen vaak meer aandacht dan ze nodig hebben—namelijk te weinig. De redirect kan in de praktijk werken, waardoor het probleem onschuldig lijkt. Maar je site stuurt nog steeds elke gebruiker en crawler door een onnodig extra request, en toekomstige redirect-wijzigingen kunnen die oude interne link onderdeel maken van een chain.

Dit werd extra relevant tijdens onze .io-to-.com migratie. Regels op domeinniveau kunnen ervoor zorgen dat een site “gemigreerd” lijkt, terwijl oude absolute links nog verstopt blijven in pagina’s, templates of gestructureerde content. Een werkende globale redirect verbergt die links; een crawl laat ze zien.

Google Search Console geeft het resultaat vanuit Google’s perspectief. In het rapport over pagina-indexering kun je statussen zoals “Pagina met redirect” en “Redirect error” tegenkomen. URL-inspectie toont de canonieke versie die de gebruiker aanlevert en die Google selecteert. Dat helpt wanneer Google de bestemming niet heeft geaccepteerd die jij verwachtte.

Voor één verdacht URL: gebruik het Network-paneel in browser DevTools. Controleer elke status en Location-response totdat de eindpagina laadt of de route faalt. Dat is sneller dan een volledige crawl draaien als je één regel debugt.

Prioriteer fixes in deze volgorde:

1. Verwijder loops, omdat ze pagina’s onbereikbaar maken.
2. Repareer redirects die eindigen op 4xx of 5xx responses.
3. Kort chains in zodat oude URL’s direct naar de eindbestemming verwijzen.
4. Vervang irrelevante redirects door relevante bestemmingen of echte 404/410 responses.
5. Werk interne links bij om redirects te omzeilen.
6. Bevestig dat permanente moves ook echt een permanente status gebruiken.

De SEO audit van SEOJuice brengt redirect chains, kapotte redirects en interne links die naar redirected URL’s wijzen naar boven, zodat je een praktische lijst hebt om door te werken. We herschrijven niet nginx, .htaccess, CDN- of CMS-redirectregels voor je; die wijzigingen horen nog altijd thuis in de infrastructuur die de response beheert.

Een redirect-checklist voor site-migraties

Behandel redirects als routingregels, niet als SEO-magic. Kies een relevante bestemming, geef aan of de move permanent is, en verwijder onnodige hops. De meeste redirect-beslissingen worden vanzelf simpel zodra deze drie punten expliciet zijn.

Veelgestelde vragen

Wat betekent “redirecting”?

Redirecten betekent dat een URL niet langer zijn eigen content levert en bezoekers en zoekmachines in plaats daarvan doorstuurt naar een andere URL. Een server-side redirect geeft normaal een 3xx HTTP-status terug plus het bestemmingsadres, dat de browser automatisch opvraagt.

Wat is het verschil tussen een 301 en een 302 redirect?

Een 301 zegt dat de move permanent is, zodat Google de bestemming als canoniek kan behandelen. Een 302 zegt dat de move tijdelijk is, dus Google houdt doorgaans de oorspronkelijke URL geïndexeerd. Gebruik een 301 als de oude pagina niet terugkomt en een 302 als dat wel zo is.

Bestrijden redirects SEO?

Correct geïmplementeerde redirects schaden SEO niet per definitie. Google raadt permanente server-side redirects aan voor permanente moves, en Gary Illyes stelde dat 30x-redirects geen PageRank verliezen. SEO-problemen ontstaan door chains, loops, kapotte bestemmingen, irrelevante redirects en statuscodes die het verkeerde intentie-signaal afgeven.

Wat is een redirect chain?

Een redirect chain ontstaat wanneer URL A doorverwijst naar URL B, die vervolgens weer doorverwijst naar URL C. Dat voegt onnodige requests en extra crawlerwerk toe. Los het op door URL A direct naar URL C te laten wijzen en interne links te updaten zodat ze het eindadres gebruiken.

Wat veroorzaakt de foutmelding “te veel redirects”?

Een redirect loop veroorzaakt deze fout. Twee of meer regels sturen het verzoek in een cirkel, vaak omdat HTTPS, www, trailing-slash, server-side of meta-refreshregels conflicteren. De browser stopt uiteindelijk met het volgen van de cyclus.

Wanneer moet ik een 307 of 308 redirect gebruiken?

Gebruik 307 voor een tijdelijke move en 308 voor een permanente move wanneer de originele HTTP-methode en request body behouden moeten blijven. Ze zijn vooral belangrijk voor formulieren en API-verzoeken die methodes zoals POST of PUT gebruiken. Bij gewone contentpagina’s die met GET worden opgevraagd blijven 301 en 302 de gangbare keuzes.