301 vs 302-redirects: wanneer gebruik je welke?

TL;DR: Een echt permanente verhuizing krijgt een 301, een oprechte tijdelijke verhuizing een 302. Als je het verkeerde kiest, indexeert Google het verkeerde URL. Gebruik de beslijstabel hieronder en lees daarna het onderdeel canonicalisatie als je wilt begrijpen hoe het mechanisme werkt.

Het antwoord in 30 seconden (beslistabel)

Nog vóór alles: dit is de scenario-naar-code-kaart. Als je haast hebt, is dit het artikel.

Als je twijfelt of iets “genoeg permanent” is voor een 301, dan is dat waarschijnlijk zo. De vraag is of je van plan bent de bestemmings-URL langdurig te behouden. Als je zeker weet dat je dat doet, gebruik dan 301.

Wat een redirect in de praktijk is

Wanneer een browser of crawler een URL opvraagt, kan de server in plaats van paginainhoud een 3xx-statuscode teruggeven. Die code zegt: “De resource die je wilt, bevindt zich ergens anders.” De Location-header in de response vertelt de client waar hij vervolgens naartoe moet.

De 3xx-familie is een reeks varianten: 301 (Moved Permanently), 302 (Found / Moved Temporarily), 303 (See Other), 307 (Temporary Redirect), 308 (Permanent Redirect) en nog een paar andere. Voor SEO doen 301, 302, 307 en 308 ertoe. De rest zijn vooral randgevallen.

301: wat “permanent” voor Google betekent

Een 301 is een signaal aan zowel de browser als de indexing pipeline dat de oude URL voorgoed verdwenen is. Google’s eigen documentatie verwoordt het helder: “Als je de URL van een pagina die in zoekresultaten wordt getoond moet wijzigen, raden we aan om waar mogelijk een permanente server-side redirect te gebruiken.”

De indexing pipeline behandelt de 301 als een canoniek signaal. Google volgt de redirect en markeert daarna de bestemmings-URL als de URL die je moet bewaren in de index. Na verloop van tijd stopt de oude URL met verschijnen in de zoekresultaten en neemt de nieuwe die plek over. Rankings, gecachte pagina’s en geconsolideerde signalen schuiven allemaal door naar de bestemming.

Wat ik uit ervaring benadruk: permanent betekent permanent. Google adviseert om permanente redirects te gebruiken “wanneer je er zeker van bent dat de redirect niet wordt teruggedraaid.” Als je een 301 neerzet en ’m zes maanden later weer afbreekt, draai je het signaal niet netjes terug. Googlebot moet de oude URL opnieuw crawlen en alles opnieuw verwerken. Ik heb klanten dit zien doen tijdens een revert, waarna ze wekenlang puzzelden waarom de rankings alle kanten op gingen. Zet de 301 minimaal een jaar door, idealiter langer.

302: de tijdelijke verhuizing en de valkuil van consolidatie

Een 302 vertelt Google: houd de oorspronkelijke URL in je index; deze verhuizing is tijdelijk. Google’s richtlijnen zijn direct: “Als je gebruikers tijdelijk naar een andere pagina wilt sturen, gebruik dan een tijdelijke redirect.”

Googlebot volgt een 302 op dezelfde manier als een 301. Het verschil zit in wat de indexing pipeline daarna doet. Bij een tijdelijke redirect behandelt Google de bestemming niet als canoniek. De oorspronkelijke URL blijft de geïndexeerde URL. Voor een onderhoudspagina of een A/B-test is dat precies het gewenste gedrag.

De valkuil is een 302 gebruiken voor een permanente verhuizing, omdat iemand niet zeker was, of omdat het “later makkelijker aan te passen” is. Google kan een langlevende 302 soms opnieuw interpreteren als een 301, maar ik zou daar niet op rekenen. Ik heb sites gezien die maandenlang een 302 draaiden op een gemigreerd domein en ontdekten dat Google de nieuwe URL’s nooit volledig had gereïndexeerd. Leun niet op Google’s heuristiek hier. Wees expliciet.

De link-equity mythe (en wat er echt verschilt)

Dit is het punt dat bijna elk artikel over dit onderwerp verkeerd heeft: 302 redirects lekken geen link equity.

In 2016 postte Gary Illyes, Google Webmaster Trends Analyst, dit rechtstreeks: “30x redirects don't lose PageRank anymore.” Dat geldt voor 301’s, 302’s en elke andere 3xx. Allemaal geven ze PageRank door.

John Mueller legde het mechanisme uit in een Webmaster Hangout: “We can forward PageRank through 301 and 302 redirects. Essentially what happens there is we use these redirects to pick a canonical. By picking a canonical we're concentrating all the signals that go to those URLs to the canonical URL.”

Lees dat zorgvuldig. Het mechanisme is canonieke consolidatie, geen “leiding” die juice van de ene URL naar de andere doorstuurt. Signalen stapelen zich op bij welke URL Google als canoniek behandelt. Het type redirect bepaalt wélke URL dat is.

De echte vraag is dus: welke URL wil je dat Google als canoniek ziet? Met een 301 wordt de bestemming canoniek. Met een 302 blijft de bron canoniek. Dáár draait de keuze om.

(Ter verduidelijking: equity-werkelijkheid is niet meteen zichtbaar, ook niet bij een 301. Google moet eerst de oude URL opnieuw crawlen, en de consolidatie vindt plaats over meerdere crawlcycli. Ook relevantie van de bestemming blijft tellen: een 301 vanaf een kookblog naar een software-landingpage consolideert niet netjes.)

301 vs 302 in één oogopslag

307 en 308: de codes waar bijna niemand over praat

307 en 308 bestaan omdat 301 en 302 een probleem hebben met method-wijziging. Wanneer een browser een 301 of 302 volgt vanuit een POST-request, staat de Fetch-specificatie toe dat de methode wordt omgezet naar GET voor de redirect-request. Dat kan login-flows, checkout-submissies en API-endpoints stilletjes breken.

307 lost dit op bij tijdelijke redirects. MDN zegt het zo: “307 garandeert dat de client de request-methode en body niet wijzigt wanneer de redirect-request wordt gedaan. Met 302 wijzigen oudere clients de methode onjuist naar GET.” Als je tijdelijk een POST-gebaseerd formulier routeert en wilt dat de POST intact blijft, is 307 de juiste code.

308 doet hetzelfde voor permanente redirects. Het verbiedt method-change volledig, anders dan 301, waarbij clients historisch de request dwongen naar GET. Als je permanent een API-endpoint redirect waar POST-data binnenkomt, is 308 strenger en veiliger.

Voor puur op GET gebaseerde pagina’s (het grootste deel van webcontent) gedragen 307 en 302 zich identiek, en gedragen 308 en 301 zich identiek. Het onderscheid in methode is alleen relevant wanneer POST- of PUT-bodies meespelen.

Nog één ding dat je moet weten: meta-refresh redirects en JavaScript-redirects (window.location) bestaan ook. Google behandelt een meta-refresh met 0-seconden vertraging als permanent (vergelijkbaar met 301) en een meta-refresh met elke andere vertraging als tijdelijk. JavaScript location-redirects zijn een ander verhaal: Google kan ze volgen wanneer het de pagina rendert, maar ze zijn trager om te verwerken, kunnen worden gemist bij crawls zonder volledige rendering, en ze dragen geen expliciet permanent/tijdelijk signaal. Server-side redirects zijn altijd de betere keuze.

De valkuil van redirect-chains

Chains ontstaan wanneer je A naar B redirect, en later B naar C, zonder A te updaten. De gebruiker en Googlebot volgen dan A naar B naar C in plaats van direct naar C te gaan.

Elke hop voegt latency toe. Latency voor echte gebruikers, meetbaar in milliseconden, die Core Web Vitals op mobiel beïnvloedt. Elke hop is ook een extra faalpunt: als een van de URL’s in de chain een 404 teruggeeft, breekt alles wat erna komt.

Google’s site-move documentatie zegt dat Googlebot tot 10 hops in een chain kan volgen, maar adviseert ook om direct naar de uiteindelijke bestemming te redirecten. John Mueller was specifieker: “Het enige waar je op moet letten is dat je minder dan 5 hops hebt voor URL’s die vaak gecrawld worden.” Googlebot kan tot 10 tolereren voordat het een fout markeert; Muellers praktische grens is 5; het echte doel is 1.

Chains stapelen zich jaren lang stil op tijdens migraties. Een site die van .com naar .io en weer terug naar .com ging, twee keer de URL-structuur veranderde, en A/B-tests draaide op categoriepagine’s kan chains opbouwen zonder dat iemand het merkt. (Als je audits draait met SEOJuice is de meest voorkomende bevinding een saaie vier-hop chain op een URL met veel verkeer die is achtergebleven van een migratie die niemand heeft geüpdatet. Chains van campagnes en A/B-tests zijn de tweede meest voorkomende boosdoener: meestal omdat de tijdelijke 302 nooit is opgeruimd.) Daarna draait iemand een crawl en ontdekt dat de homepage drie hops diep zit.

De oplossing is altijd hetzelfde: identificeer de uiteindelijke bestemming en update de eerste redirect zodat die daar direct naartoe wijst. Maak het kapot en vouw het samen. Wacht niet tot Google erdoorheen navigeert.

Loops zijn het pathologische geval. A redirect naar B, B redirect naar A, en de browser gooit ERR_TOO_MANY_REDIRECTS. Dit is meestal een verkeerd geconfigureerde HTTPS-regel of een CMS-redirect die een cyclus creëert. Audit-tools vangen dit meteen.

Hoe je redirects op je site auditeert

Waar je op moet letten:

• Verkeerde code voor het scenario: een permanente migratie die als 302 wordt geserveerd, of een tijdelijke test die permanent is geworden zonder te worden geüpdatet naar 301
• Chains: elke A naar B naar C volgorde waarbij je direct A naar C had kunnen doen
• Loops: elke cyclus die ERR_TOO_MANY_REDIRECTS oplevert
• Redirects naar 404’s: de bestemmings-URL bestaat niet meer; je stuurt gebruikers en bots een doodlopende weg op
• Verouderde 302’s: content die maanden of jaren geleden is verhuisd en nooit naar permanent is gepromoveerd

Voor een snelle handmatige check laat curl -I https://yourdomain.com/old-url je de statuscode en Location-header zien zonder de volledige pagina te laden. Browser DevTools (tabblad Network, “Preserve log” aangevinkt) toont je de volledige redirect-sequentie voor elke URL. Dit is prima voor spotchecks. Voor structurele dekking heb je een crawler nodig.

De SEOJuice SEO audit crawlt je site en markeert redirect-chains, loops, redirects met verkeerde codes en hops naar 4xx-bestemmingen. Dit is de snelste manier om een volledig beeld te krijgen zonder honderden URL’s handmatig te curl’en. Check ook: URL’s met veel verkeer uit je SEO-hygiëne audit. Dat zijn meestal precies de gevallen waar een begraven chain je verkeer echt kost.

Single-page applications vragen hier extra aandacht. JS-gebaseerde routering kan redirect-achtig gedrag creëren dat server-side crawlers volledig missen. Als je een React- of Next.js-site draait, bekijk dan de notities over SPA redirect handling. De randgevallen rond window.location en client-side routing beïnvloeden Google's JavaScript-executie op niet-zo-voor-de-hand-liggende manieren.

Veelgestelde vragen

Geeft een 302 redirect link equity (SEO-waarde) door?

Ja. Google heeft bevestigd dat PageRank doorloopt via 301, 302 en alle 3xx redirects. Gary Illyes stelde in 2016 dat “30x redirects don't lose PageRank anymore”, en John Mueller legde uit dat zowel 301 als 302 signals doorgeven via canonieke consolidatie. Het type redirect bepaalt welke URL Google bewaart in de index, niet of equity doorstroomt.

Is 301 of 302 beter voor SEO?

Geen van beide is inherent beter. De juiste code hangt af van of de verhuizing permanent is. Gebruik 301 wanneer de bestemmings-URL de URL is die je vanaf nu geïndexeerd wilt hebben. Gebruik 302 wanneer de oorspronkelijke URL geïndexeerd moet blijven en je het ook echt van plan bent om die terug te zetten. Als je dit verkeerd doet, verlies je niet direct link equity; je stopt alleen de verkeerde URL in Google’s index.

Hoe lang duurt het voordat Google een 301 erkent?

Er is geen vaste timing. Google moet de oude URL opnieuw crawlen voordat het het signaal kan verwerken; dat kan variëren van een paar dagen tot meerdere weken, afhankelijk van hoe vaak er gecrawld wordt. Houd de 301 minimaal een jaar live. Als je ’m te vroeg verwijdert, draait het canonieke signaal terug en moet Googlebot alles opnieuw crawlen en opnieuw verwerken vanaf nul.

Kunnen te veel redirects de rankings schaden?

Ja, maar indirect. Redirect-chains verhogen latency, verspillen crawlbudget en introduceren faalpunten. Google raadt aan om direct naar de uiteindelijke bestemming te redirecten; Muellers praktische richtlijn is minder dan 5 hops voor URL’s die vaak gecrawld worden. Het effect is het opgetelde resultaat van een trager paginalaadproces, lagere crawl-efficiëntie en het risico dat een kapotte hop halverwege de hele sequence omver trekt — geen directe ranking penalty.

Verder lezen:

• SEO Hygiene Audit Checklist om geen verkeer te verliezen
• Core Web Vitals 2026: Auditwijzigingen die er echt toe doen
• SEO Best Practices voor Single-Page Applications

Voer een gratis SEO-audit uit en vind redirect-chains, loops, redirects met verkeerde codes en hops naar dead pages op je site.