Een 301-redirect is een permanente server-side doorverwijzing die aan Google vertelt: deze pagina is definitief verhuisd, behandel de nieuwe URL als de echte. Gebruik hem altijd bij permanente wijzigingen, nooit bij tijdelijke. Voordat je ook maar één URL wijzigt, maak je een redirectmap. En zorg dat elke redirect in één sprong naar de eindbestemming gaat, niet via drie omwegen.
Kort samengevat:
- Gebruik een 301-redirect alleen bij blijvende verhuizingen, om de linkwaarde correct over te dragen en te voorkomen dat rankings verloren gaan.
- Vermijd redirectketens door elke redirect rechtstreeks naar de definitieve URL te laten leiden, om laadtijd en crawl-efficiëntie te verbeteren.
- Test na het implementeren van redirects altijd via curl en monitor in Search Console, omdat het herindexeren en herstellen van rankings soms weken kan duren.
- Bij een domein- of page-migratie moet je een volledige redirectmap maken en elke regel apart controleren voor een succesvolle overgang.
- Gebruik server-side redirects waar mogelijk, omdat client-side JavaScript-omleidingen de SEO en gebruikerservaring negatief kunnen beïnvloeden.
Inhoudsopgave
- Wat is een 301-redirect en hoe werkt hij technisch?
- 301 versus 302: wanneer kies je welke?
- Hoe 301-redirects je SEO beïnvloeden
- Veelvoorkomende toepassingen: van HTTPS-omzetting tot contentfusie
- Technische implementatie: van Apache tot Azure
- Best practices en veelgemaakte fouten
- Controle en monitoring: wat je moet testen en volgen
- Ramons checklist en 90-dagen aanpak
- Wat 301-redirects doen met laadtijd en gebruikerservaring
- Server-side redirects versus client-side omleidingen
- Mobiele redirects en hreflang: waar het misgaat
- Mijn advies: focus op de eindbestemming, niet op de redirect zelf
- Hulp nodig bij je migratie of redirectstrategie?
- Bronnen
- Veelgestelde vragen
Wat is een 301-redirect en hoe werkt hij technisch?
De statuscode 301 betekent “permanent verplaatst”. Je server stuurt die code naar elke browser of crawler die om de oude URL vraagt, samen met het adres van de nieuwe pagina. De browser volgt automatisch, de gebruiker ziet er niets van. Voor Google is die code een instructie: dit is niet zomaar een omweg, dit is de nieuwe permanente locatie. Google Search Central bevestigt dat de zoekmachine de nieuwe URL daardoor als canoniek behandelt en de bijbehorende rankingsignalen daar naartoe verplaatst.
Wat gebeurt er onder de motorkap:
- De server ontvangt het verzoek voor de oude URL en checkt zijn redirectregels.
- Hij stuurt statuscode 301 plus de nieuwe locatie terug in de response header.
- De browser haalt automatisch de nieuwe URL op, zonder dat de gebruiker iets merkt.
- Crawlers zoals Googlebot registreren de verhuizing en werken hun index geleidelijk bij.
Browsers cachen 301’s vaak agressief. Dat is efficiënt, maar ook riskant: als je een redirect later weer intrekt, kan de browser van een terugkerende bezoeker nog dagenlang de oude route blijven volgen. Test dus in een incognito-venster of met een schone cache voordat je concludeert dat een wijziging niet werkt.
301 versus 302: wanneer kies je welke?
Een 301 is permanent, een 302 is tijdelijk. Dat verschil is geen technisch detail, het is het hele punt. Verwissel ze en je betaalt daarvoor met rankings.
- Ga je een pagina blijvend verplaatsen? Gebruik altijd 301. Google draagt de autoriteit dan over naar de nieuwe URL.
- Test je een A/B-variant of doe je onderhoud? Gebruik 302. De oude URL blijft dan de canonieke versie in de index, precies zoals je wilt tijdens een kort experiment.
- Twijfel je? Kies 301 zodra de kans reëel is dat de wijziging blijvend wordt. Een 302 die je vergeet terug te zetten, is een lekkende leiding die je maanden niet opmerkt.
Search Engine Journal legt het scherp uit: een 302 draagt doorgaans geen autoriteit over en laat de oude URL als canoniek staan. Gebruik je die verkeerd bij een permanente migratie, dan blijft de oude pagina in de index staan terwijl je nieuwe pagina leeg blijft van linkwaarde. Dat is geen SEO-strategie, dat is een lek in je eigen fundering.
Hoe 301-redirects je SEO beïnvloeden
Een 301 draagt linkwaarde over, maar niet zoals een emmer water die je in één keer overgiet. Er lekt altijd iets weg, en Google is daar zelf nooit heel precies over geweest. Wat vaststaat: Google behandelt de nieuwe URL als canoniek en verplaatst rankingsignalen daar naartoe. Verwacht geen naadloze, ogenblikkelijke overdracht. Reken op een herindexeringsperiode waarin rankings tijdelijk kunnen schommelen, soms wekenlang.
Pro-tip: Zie een tijdelijke rankingdip na een migratie niet als een mislukking. Zie het als het moment dat Google je nieuwe route aan het inmeten is. Herstel kan soms weken tot maanden duren; als het na langere tijd niet verbetert, is er mogelijk een probleem.
Redirect chains zijn de sluipmoordenaar in dit verhaal. Elke extra hop voegt een netwerk-roundtrip toe voordat de browser of crawler eindelijk aankomt. MDN Web Docs noemt die opeenstapeling van hops een directe belasting voor laadtijd en crawl-efficiëntie. Drie schakels in een ketting waar één volstaat, is dweilen met de kraan open: je blijft resources verspillen aan iets dat je in één keer had kunnen dichten.
Waar chains concreet schade aanrichten:
- Ze vertragen de Largest Contentful Paint (LCP), een van de kernmetrieken van Core Web Vitals.
- Ze verbruiken crawlbudget dat Googlebot dan niet aan nieuwe of belangrijke pagina’s besteedt.
- Ze vergroten de kans dat een crawler halverwege afhaakt en de eindbestemming nooit bereikt.
- Ze maken foutopsporing lastiger, omdat je bij elke schakel opnieuw moet controleren waar het misgaat.
De regel is simpel: elke redirect wijst rechtstreeks naar de definitieve URL. Geen tussenstations, geen historische restjes van vorige migraties die nog steeds in de keten hangen.
Veelvoorkomende toepassingen: van HTTPS-omzetting tot contentfusie
Niet elke situatie vraagt om dezelfde aanpak. Vier gevallen komen het vaakst voor, en elk heeft zijn eigen valkuil.
- HTTP naar HTTPS: één 301 per URL, met behoud van het volledige pad en de querystring. Vergeet niet de HTTPS-versie van je domein als apart property in Search Console te verifiëren, anders blijft Google rapporteren over een domein dat niet meer bestaat. Meer over die omzetting lees je in onze uitleg over HTTPS voor SEO.
- Domeinmigratie: maak een volledige redirectmap, pad voor pad, en test elke regel afzonderlijk. Een migratie zonder mapping is als een leger dat een rivier oversteekt zonder te weten waar de bruggen liggen: sommige eenheden komen nooit aan de overkant.
- Content samenvoegen: redirect naar de pagina die inhoudelijk het dichtst bij de oude ligt. Een redirect naar de homepage omdat je te lui was om de juiste bestemming te zoeken, is verspilde linkwaarde.
- Pagina’s verwijderen zonder equivalent: overweeg dan een 404 of 410 in plaats van een geforceerde redirect. Sitebulb is daar duidelijk over: een 301 naar een pagina die inhoudelijk niets met het origineel te maken heeft, is geen SEO-truc, het is misleiding die Google op termijn negeert.
De vuistregel die alles samenvat: redirect alleen naar een echt equivalent. Anders vecht je een oorlog die je met slimme trucs niet gaat winnen.
Technische implementatie: van Apache tot Azure
Hoe je een 301 instelt, verschilt per platform. De logica blijft overal hetzelfde: minimaliseer hops, werk zoveel mogelijk op serverniveau.
Op een Apache-server regel je dit meestal via .htaccess met een RewriteRule of een simpele Redirect 301-directive. Werkt prima voor kleine sites, maar bij honderden regels wordt een .htaccess-bestand traag om te verwerken, omdat Apache het bij elk verzoek opnieuw inleest.
Nginx werkt met return 301 https://voorbeeld.nl$request_uri; in het serverblok. Dat is aanzienlijk sneller dan een regex-rewrite, omdat de server geen patroon hoeft te matchen voordat hij de redirect uitvoert. Zoals de HTTPS Redirect Guide van Site Watcher laat zien: gebruik return waar mogelijk, bewaar rewrites voor complexere patronen.
Bij WordPress kun je een plugin gebruiken voor eenvoudige redirects, maar bij grote volumes is een serverregel betrouwbaarder. Een plugin voegt een extra verwerkingslaag toe: WordPress moet eerst volledig laden voordat de redirect wordt uitgevoerd. Bij duizenden URL’s merk je dat in de laadtijd.
Bij Cloudflare is de klassieke valkuil de SSL-instelling “Flexible”. Die praat met je server via HTTP terwijl de bezoeker HTTPS ziet, wat samen met een eigen HTTP naar HTTPS redirect op je server een oneindige lus kan veroorzaken. Zet SSL op “Full” of “Full (strict)” voordat je redirects op serverniveau inschakelt.
Bij Azure Front Door stel je een redirectregel in via het klassieke portaal, waarbij je een HttpToHttpsRedirect-regel aanmaakt. Microsoft’s eigen documentatie beschrijft de stappen, maar waarschuwt ook: een verkeerd ingestelde CDN-regel kan onbedoeld kosten opdrijven of, erger, een lus veroorzaken met een regel die al op de origin-server staat.
| Platform | Methode | Aandachtspunt |
|---|---|---|
| Apache | .htaccess met Redirect 301 of RewriteRule |
Traag bij grote regelsets |
| Nginx | return 301 in serverblok |
Sneller dan regex-rewrite |
| WordPress | Plugin of serverregel | Plugin voegt laadtijd toe |
| Cloudflare | SSL-modus plus paginaregels | “Flexible” SSL kan lussen veroorzaken |
| Azure Front Door | HttpToHttpsRedirect-regel | Verkeerde configuratie kan kosten of lussen geven |
Pro-tip: Combineer www-naar-non-www én HTTP-naar-HTTPS altijd in dezelfde hop. Twee losse redirects na elkaar creëren onnodige ketens. Redirect Trace benoemt dit als de beste praktijk om ketens te vermijden.
Heb je geen eigen ontwikkelaar in huis om deze regels te implementeren, dan kan een partij als Durfmakers de serverconfiguratie voor je verzorgen zonder dat je zelf in de code hoeft te duiken.
Best practices en veelgemaakte fouten
De meeste SEO-schade na een migratie komt niet van de redirect zelf, maar van alles ernaast dat niemand heeft bijgewerkt.
- Vermijd ketens: link intern altijd direct naar de eindbestemming, nooit naar een tussenliggende oude URL.
- Werk je sitemap bij zodra de nieuwe URL’s live staan, anders blijft Google oude paden aanbieden aan crawlers.
- Controleer canonicals en JSON-LD structured data: die verwijzen soms nog naar de oude URL, ook al staat de redirect goed.
- Prioriteer op basis van inkomend verkeer en externe links: begin met je belangrijkste pagina’s in plaats van een alfabetische lijst.
- Overweeg een 404 of 410 boven een geforceerde redirect wanneer er simpelweg geen equivalente pagina meer bestaat.
Pro-tip: Zoek in je CMS naar interne links die nog naar oude URL’s wijzen en pas ze handmatig aan. Een redirect vangt het bezoek wel op, maar elke interne link die via een omweg loopt, is een kleine linkwaarde-lek die zich optelt.
Sitebulb’s redirect-gids benadrukt hetzelfde principe vanuit een andere hoek: 301’s behouden linkwaarde alleen wanneer de bestemming inhoudelijk een echt equivalent is. Een redirect is geen pleister voor slechte contentkeuzes, het is een verkeersregel die alleen werkt als de bestemming klopt.
Controle en monitoring: wat je moet testen en volgen
Na de livegang begint het echte werk. Test eerst met curl -I https://voorbeeld.nl/oude-pagina/ of de server de juiste 301-header teruggeeft, samen met de correcte nieuwe locatie. Dat commando geeft je binnen een paar seconden zekerheid, zonder dat je een browser hoeft te openen.
- Controleer in Search Console het rapport “Pagina’s” en let op de categorie omleidingspagina’s, zo zie je of Google je redirects correct heeft opgepikt.
- Meet organisch verkeer en rankings per verplaatste pagina, niet alleen op siteniveau, om lokale problemen niet te missen.
- Volg Core Web Vitals nauwgezet, vooral de LCP: ketens veroorzaken hier de meeste schade.
- Herhaal de curl-check steekproefsgewijs op je belangrijkste URL’s, ook weken na de livegang.
Een goede meetperiode duurt meerdere maanden met regelmatige controle in de eerste weken. Grijp in zodra rankings na geruime tijd nog niet beginnen te herstellen. Onze uitgebreide migratiegids werkt dat schema verder uit, net als de aanpak voor het snel oplossen van indexeringsfouten in Search Console.
Ramons checklist en 90-dagen aanpak
Dit is de volgorde die ik zelf altijd aanhoud bij een migratie:
- Maak eerst de volledige redirectmap, pad voor pad, en valideer elke regel met curl voordat er ook maar iets live gaat.
- Werk direct daarna interne links en de sitemap bij, zodat Google niet naar oude paden blijft verwezen worden door je eigen site.
- Verifieer het nieuwe domein of protocol als apart property in Search Console, anders mis je rapportagedata voor je nieuwe URL’s.
- Zet monitoring-checkpoints op dag 7, dag 30 en dag 90, met vooraf afgesproken drempels voor wanneer je ingrijpt.
- Schakel op dat punt een expert in wanneer rankings na 60 dagen nog niet herstellen: dan zit het probleem meestal dieper dan de redirect zelf, bijvoorbeeld in canonicals of contentkwaliteit.
Verwacht geen wonderen binnen een week. Wel een duidelijk herstelpatroon binnen twee tot drie maanden, mits de basis klopt.
Wat 301-redirects doen met laadtijd en gebruikerservaring
Een 301 kost tijd. Niet veel, maar wel meetbaar: de browser moet eerst het originele verzoek versturen, de 301-header ontvangen, en dan pas het nieuwe verzoek doen. Bij één enkele redirect is dat verwaarloosbaar, een fractie van een seconde op een normale verbinding.
Het probleem ontstaat bij opeenstapeling. Elke extra hop in een keten voegt een volledige netwerk-roundtrip toe, en op mobiele verbindingen met hogere latency tikt dat harder aan dan op glasvezel. MDN noemt dit een directe factor in paginaprestaties, met name voor metrics die de eerste weergave meten.
Voor gebruikers is een enkele redirect onzichtbaar: ze zien de oude URL intikken en komen automatisch op de juiste pagina uit. Bij een keten van drie of vier hops merken ze wel iets, zeker op trage verbindingen: de pagina lijkt te haperen voordat er iets verschijnt. Dat is geen esthetisch probleem, het raakt direct de Largest Contentful Paint en daarmee je Core Web Vitals-score.
De praktische les: reken een redirect nooit als “gratis” alternatief voor het direct aanpassen van links. Elke interne link die nog naar een oude URL wijst en via een redirect naar de juiste pagina moet, is een kleine, vermijdbare vertraging die zich per pagina optelt. Pas ze aan naar de eindbestemming en de winst is meteen voelbaar, ook zonder dat een gebruiker het bewust merkt.
Server-side redirects versus client-side omleidingen
Een server-side 301 gebeurt voordat er ook maar één regel HTML is verstuurd. De server beslist, stuurt de header, klaar. Een client-side redirect via JavaScript werkt fundamenteel anders: de browser moet eerst de volledige pagina laden, het script uitvoeren, en dan alsnog naar de nieuwe locatie springen.
Dat verschil is niet triviaal voor SEO. Crawlers verwerken server-side redirects onmiddellijk en zonder twijfel: de statuscode is glashelder. Bij een JavaScript-redirect moet een crawler eerst de pagina renderen om het script te herkennen en uit te voeren, en dat gaat niet altijd goed of snel genoeg. Sommige crawlers missen de redirect volledig, waardoor de oude pagina in de index blijft staan als een geest die je niet meer kunt uitleggen.
Voor gebruikers is het verschil ook voelbaar. Een server-side 301 is vrijwel onmiddellijk. Een JavaScript-redirect vereist eerst het laden van de pagina, het parsen van scripts en pas dan de sprong: dat kost merkbaar meer tijd, zeker op trage verbindingen of oudere apparaten.
Gebruik JavaScript-redirects daarom alleen als noodoplossing, bijvoorbeeld wanneer je geen toegang hebt tot serverconfiguratie in een specifieke omgeving. Als vaste strategie is het de verkeerde keuze: je vervangt een betrouwbare, snelle serverregel door een fragiele constructie die afhankelijk is van of de browser het script wel uitvoert. Kies altijd voor server-side waar dat kan.
Mobiele redirects en hreflang: waar het misgaat
Mobiele redirects hebben hun eigen risico’s, vooral bij sites die ooit een apart mobiel subdomein hadden zoals m.voorbeeld.nl. Redirect je die pagina’s terug naar de reguliere URL, controleer dan of de redirect per specifiek pad gaat en niet standaard naar de homepage. Een generieke redirect van alle mobiele URL’s naar de hoofdpagina verspilt linkwaarde die je juist per pagina had willen behouden.
Bij hreflang wordt het complexer. Hreflang-tags verwijzen naar specifieke taalversies van een pagina. Verplaats je een van die versies met een 301, dan moet je de hreflang-tags op alle bijbehorende taalversies bijwerken naar de nieuwe URL. Vergeet je dat, dan wijst Google’s index nog naar een pagina die niet meer bestaat, terwijl de andere taalversies wel gewoon naar de oude locatie blijven verwijzen. Dat is geen kleine inconsistentie, dat verwart Google over welke versie voor welk land of taal de juiste is.
De praktische regel: bij elke 301 op een pagina die deel is van een hreflang-cluster, werk je de volledige cluster in één beweging bij. Niet de ene taalversie vandaag en de andere volgende week. Onze gids over hreflang-fouten en monitoring gaat dieper in op hoe je dit soort clusters foutloos bijhoudt na een migratie.
Test mobiele en internationale redirects daarnaast apart van je desktop-checks. Een redirect die op desktop perfect werkt, kan op mobiel alsnog vastlopen door een verschil in caching-regels tussen CDN en origin-server.
Mijn advies: focus op de eindbestemming, niet op de redirect zelf
De technische kant van een 301 is het makkelijke deel. Waar het misgaat, is bij mensen die de redirect zien als eindpunt in plaats van als eerste stap. Focus op waar je bezoeker en Google werkelijk moeten uitkomen, en bouw daaromheen: sitemap, interne links, canonicals, allemaal in dezelfde beweging.
Wees ook realistisch over herstel. Twee tot drie maanden is normaal, geen falen. Schakel een expert in zodra je na zes weken nog geen enkel herstelsignaal ziet: dan zit het probleem waarschijnlijk dieper dan de redirect zelf.
— Ramon
Hulp nodig bij je migratie of redirectstrategie?
Voor redirectklussen en domeinmigraties is er een alternatief voor dure bureau-inhuur: geen vast maandcontract, gewoon een concrete opdracht met een duidelijk begin en eind. Je kunt een migratie-audit krijgen die laat zien welke URL’s risico lopen, gevolgd door de technische implementatie of begeleiding van je developer daarbij.
Daarna stopt het niet. Zo weet je binnen een paar weken of er herstel plaatsvindt zoals verwacht, in plaats van maanden later voor een onaangename verrassing te staan. Het resultaat: minder linkwaarde die wegsijpelt tijdens de overgang, en een sneller herstel van rankings dan wanneer het aan het toeval wordt overgelaten.
Wil je weten waar jouw site risico loopt bij een migratie? Vraag een scan aan via Nebber en je krijgt binnen korte tijd een analyse van je redirectstructuur.
Bronnen
Veelgestelde vragen
Beïnvloeden 301-redirects mijn SEO-rankings?
Ja, maar meestal positief als je ze correct instelt: Google draagt rankingsignalen over naar de nieuwe URL. Een tijdelijke dip tijdens herindexering is normaal en geen teken van een fout.
Wat is een 301-redirect in SEO-termen?
Een 301 is een permanente server-side statuscode die aangeeft dat een pagina definitief is verhuisd, waarna Google de nieuwe URL als canoniek behandelt en de bijbehorende autoriteit daarheen verplaatst.
Wat is een 302-redirect in SEO-termen?
Een 302 is een tijdelijke redirect die de oude URL als canoniek in de index laat staan. Gebruik hem voor A/B-tests of kortdurend onderhoud, nooit voor permanente verplaatsingen.
Hoelang duurt het voordat rankings herstellen na een migratie?
Reken op zes tot twaalf weken voor een merkbaar herstel, met een volledige stabilisatie vaak rond de 90-dagen grens. Blijft herstel na zes weken volledig uit, schakel dan een specialist in.
Wanneer gebruik ik beter een 404 in plaats van een redirect?
Wanneer er simpelweg geen inhoudelijk equivalent bestaat voor de verwijderde pagina. Een 301 naar een irrelevante bestemming schaadt je SEO meer dan een eerlijke 404 of 410.