301 vs 302: permanente en tijdelijke redirects

2026-09-04 Bijgewerkt: 2026-09-14

Een 301 zegt dat de resource permanent is verhuisd en dat de nieuwe URL de oude overal zou moeten vervangen; een 302 zegt dat de verhuizing tijdelijk is en dat de oorspronkelijke URL nog steeds de echte is. Zoekmachines handelen naar dat verschil, en dat is waarom de verkeerde code u rankings kost.

Wat de twee codes een client vertellen

Beide codes sturen de client naar het adres in de header Location, en voor een bezoeker zien ze er identiek uit. Het verschil zit in wat al het andere met de informatie doet. Een 301 nodigt clients en crawlers uit om hun gegevens bij te werken: de bookmark vervangen, de link herschrijven, het doel indexeren in plaats van de bron. Een 302 vraagt hen de oorspronkelijke URL te blijven gebruiken en deze keer alleen een omweg te nemen. Browsers kunnen een 301 cachen en helemaal stoppen met de server te vragen; een 302 is standaard niet cachebaar tenzij het antwoord anders zegt.

Wanneer u welke gebruikt

Gebruik 301 voor een domeinwijziging, een migratie van HTTP naar HTTPS, een canonicalisering van non-www naar www, een permanente URL-herstructurering, een samengevoegde of hernoemde pagina, of een uitgefaseerde productpagina die naar de dichtstbijzijnde vervanger wijst.
Gebruik 302 voor een onderhoudspagina, een A/B-test, een geografische of taalkeuze voor een landingspagina die u kunt wijzigen, een kortstondige campagne-URL, of een tijdelijke "kom later terug"-bestemming.

Gebruik nooit een 301 voor iets dat u van plan bent terug te draaien. Omdat clients hem cachen, kunnen terugkerende bezoekers lang nadat u de regel verwijdert nog steeds op de tijdelijke bestemming terechtkomen, en er is geen manier om in hun caches te reiken. De omgekeerde fout: laat een 302 staan op een permanente verhuizing en de oude URL blijft geïndexeerd, de nieuwe concurreert ermee, en de signalen blijven gesplitst.

SEO-gevolgen

De documentatie van Google stelt dat een permanente redirect een signaal is dat het redirectdoel als de canonical URL zou moeten worden behandeld, terwijl een tijdelijke redirect dat niet is, zodat de oorspronkelijke URL haar plek in de index behoudt. In de praktijk:

Een 301 consolideert linkwaarde op het doel en vervangt na verloop van tijd de oude URL in de index door de nieuwe.
Een 302 laat de bron-URL doorgaans geïndexeerd. Zoekmachines proberen wel intentie te interpreteren, dus een langlopende 302 kan uiteindelijk als permanent worden behandeld, maar u zou er niet op moeten rekenen dat dit correct wordt geraden.
Redirectketens verwateren het voordeel en vertragen crawlen. Wijs oude URL's rechtstreeks naar de uiteindelijke bestemming.
Veel uitgefaseerde pagina's naar de homepage redirecten wordt eerder behandeld als een zachte 404 dan als een verhuizing. Redirect naar de dichtstbijzijnde equivalente pagina, of geef een 410 terug als niets equivalent is.
Wat u ook kiest, houd het consistent met uw canonical-tags en uw sitemap. Tegenstrijdige signalen zijn erger dan een licht suboptimale.

307 en 308: de methode-behoudende versies

De oorspronkelijke definities van 301 en 302 waren dubbelzinnig over de HTTP-methode, en clients hebben zich gevestigd op een gedrag dat de standaard nu als historisch omschrijft: wanneer ze een 301 of 302 volgen na een POST, veranderen veel clients de methode in GET en laten de body vallen. Voor een pagina is dat onschadelijk. Voor een formulier-endpoint of een API vernietigt het het verzoek en meldt het niets.

307 Temporary Redirect heeft dezelfde betekenis als 302, en 308 Permanent Redirect heeft dezelfde betekenis als 301, met aan beide een eis toegevoegd: de methode en body moeten behouden blijven. Voor URL's die alleen ooit GET-verzoeken ontvangen, zijn 301 en 302 dus prima en is dat wat de meeste tools verwachten. Voor alles dat POST, PUT, PATCH of DELETE accepteert, gebruikt u 308 voor een permanente verhuizing en 307 voor een tijdelijke. Wilt u specifiek dat een POST wordt gevolgd door een GET op een andere URL, dan is 303 See Other daarvoor.

Hoe u controleert welke code een URL teruggeeft

Lees de statusregel en het doel zonder de redirect te volgen:
```
curl -sI https://example.com/old-page | grep -Ei "^(HTTP|location|cache-control)"
```
De statusregel toont 301, 302, 307 of 308, en Location toont waar hij naartoe wijst.

Volg de hele keten en tel de sprongen, zodat u kunt zien of één redirect er drie is geworden:

curl -sIL -o /dev/null -w "%{num_redirects} hops, final %{http_code}, %{url_effective}\n" https://example.com/old-page

Test met een POST als het endpoint er een accepteert. Komt het verzoek bij het doel aan als een GET zonder body, zet de regel dan om naar 307 of 308.
Wijzig de code waar hij gegenereerd wordt. Dat kan de applicatie, de webserverconfig, een .htaccess-regel, of de CDN zijn. Redirecten twee lagen allebei, dan wint de buitenste en is de binnenste regel onzichtbaar.
Verifieer met een koude cache. Een browser die al een 301 heeft gecachet, blijft die gehoorzamen, dus bevestig met curl of een privévenster voordat u concludeert dat de wijziging niet werkte.
Houd de redirect na een permanente verhuizing op zijn plek. Hem later verwijderen strandt elke link en bookmark die nog naar de oude URL wijst.

Een redirect in de gaten houden nadat u hem heeft ingesteld

Een redirect die van code verandert, begint te lussen of zijn TLS-certificaat verliest, laat de bron-URL nog steeds antwoorden, dus niets ziet er kapot uit totdat het verkeer daalt. Externe checks die de exacte statuscode registreren en de keten volgen, betrappen dat bij de volgende run, en het vanaf veel netwerken controleren scheidt een wereldwijde regelwijziging van een regionaal CDN-probleem. HostTracker monitort websites sinds 2004 en draait checks vanaf 300+ meetpunten in 158 steden. Zie wat een URL nu teruggeeft met de HTTP-checktool, en lees de volledige handleiding 3xx-omleidingsfamilie voor de codes aan weerszijden van deze twee.