Een redirect is een HTTP-respons: een 301- of 302-status met een Location header die de browser vertelt waar hij in plaats daarvan naartoe moet. Dat is alles wat het op de lijn is, wat betekent dat de vraag niet echt is hoe je een URL redirect, maar welke laag vóór je site degene moet zijn die antwoordt.
Zes lagen kunnen de klus klaren, en ze zijn niet uitwisselbaar. Ze verschillen in wie de respons serveert, of het pad en de querystring de reis overleven, hoe snel je van gedachten kunt veranderen, en hoeveel van de setup je zelf in handen hebt. Deze gids doorloopt alle zes, de tabel die tussen hen kiest, en de twee controles die een redirect die werkt onderscheiden van een die stilletjes je campagneparameters opeet. Voor de statuscodes zelf is soorten URL-redirects de referentie hieronder.
Waar een redirect eigenlijk zit
Begin met de mythe, want die kost meer middagen dan wat dan ook: DNS kan geen URL redirecten. Een DNS-record koppelt een hostnaam aan een adres. Het ziet nooit het pad, ziet nooit de querystring, en heeft geen mechanisme om te zeggen "ga in plaats daarvan ergens anders naartoe". Een A- of CNAME-record wijst; het stuurt niet door.
Dus wanneer je registrar "URL forwarding" aanbiedt, wijst hij in werkelijkheid de hostnaam naar een kleine webserver die ze zelf draaien, die namens jou de HTTP-redirect teruggeeft. Nuttig, en volkomen legitiem, maar het is een webserver die het werk doet, niet de DNS. Zodra je het zo bekijkt, houden de zes methoden hieronder op alternatieven te lijken en worden ze één enkele vraag: welke machine in het verzoekpad wil je laten antwoorden?
Zes plekken waar je een redirect kunt plaatsen
Elk van deze eindigt met dezelfde respons op de lijn. Wat verschilt, is de opzetkosten, wie het beheert, en wat er gebeurt met alles na de domeinnaam.
domain forwarding bij de registrar
De snelste optie, en de meest botte. In het controlepaneel van je registrar wijs je het domein naar een bestemming en kies je permanent of tijdelijk. Goed voor een domein dat je defensief hebt gekocht, een rebrand waarbij de oude naam gewoon moet overdragen, of een kort campagnedomein.
De adder onder het gras is wat het doet met de rest van de URL: de meeste registrar-forwarding vlakt elk verzoek af naar de ene bestemming die je hebt geconfigureerd, waardoor een diepe link op de homepage terechtkomt. Sommige bieden een padbehoudende modus; controleer dat voordat je erop vertrouwt.
een regel in je webserver
Als je nginx of Apache draait, hoort de redirect hier thuis, omdat je exacte controle krijgt over matching en behoud. Apache's documentatie over het remappen van URL's met rewrite-regels behandelt de patronen, en nginx's referentie voor de rewrite-module behandelt return 301 en rewrite ... permanent, wat het snelle pad is voor een simpele verhuizing.
Serverregels zijn het juiste gereedschap voor canonical-host- en HTTPS-afdwinging, padrewrites na een herstructurering, en alles wat conditioneel is. Het is ook waar redirectregels zich in de loop der jaren stilletjes ophopen, dus behandel het bestand als iets om te snoeien in plaats van alleen aan toe te voegen.
een regel bij je hostingplatform
De meeste moderne hosts zitten vóór de origin en bieden hun eigen redirectlaag: een _redirects-bestand, een configblok, een regels-UI in het dashboard. Deze worden geëvalueerd voordat je applicatie draait, wat ze snel en veilig maakt, en ze zijn meestal de beste plek voor bulkredirects na een sitemigratie omdat ze in versiebeheer leven samen met de rest van het project.
een plugin of instelling in je CMS
Elk serieus CMS heeft een redirectbeheerder, en voor een contentteam is dat het juiste antwoord: geen deploy, geen servertoegang, een audit trail, en iemand die de content begrijpt die de mappingbeslissing neemt. De afweging is dat het verzoek de applicatie moet bereiken voordat de redirect wordt uitgegeven, dus het is trager dan de lagen hierboven en het stopt met werken als de applicatie plat ligt.
meta refresh of JavaScript op de pagina
Een laatste redmiddel voor wanneer je niets serverside kunt aanraken. De pagina laadt, en stuurt de bezoeker vervolgens verder met een <meta http-equiv="refresh"> tag of een script. Het werkt, maar het kost een volledige paginalaad, het hangt ervan af of de client het uitvoert, en zoekmachines behandelen het als een zwakker signaal dan een serverrespons. Gebruik het wanneer het alternatief niets is.
een beheerde korte link
Wanneer het ding dat wordt geredirect een link is die je hebt gepubliceerd in plaats van een pagina die je bezit, hoort de redirect thuis in een linkbeheerder. De bestemming is een opgeslagen waarde die je kunt veranderen zonder DNS, servers, of een deploy-pipeline aan te raken, elke hop wordt gelogd, en de link blijft werken nadat hij is afgedrukt of gedeeld. Dit is het hele mechanisme achter wat een URL-shortener is, en het is waarom een afgedrukte campagnelink nooit rechtstreeks naar een landingspagina zou moeten wijzen.
Er een kiezen in dertig seconden
Het grootste deel van de beslissing komt neer op twee kolommen: wie heeft toegang, en wat moet overleven.
| Methode | Wie serveert het | Pad en query behouden | Best voor |
|---|---|---|---|
| Registrar-forwarding | Server van registrar | Vaak niet, controleer eerst | Overdracht van heel domein |
| Webserverregel | Je origin | Ja, als je hem zo schrijft | Canonical host, herstructurering |
| Platformregel | Host ervoor | Ja | Bulkmigratieredirects |
| CMS-plugin | Je applicatie | Ja | Contentteam, geen deploys |
| Meta refresh of JS | De browser | Ja, maar traag | Helemaal geen servertoegang |
| Beheerde korte link | De linkservice | Ja, vanaf de opgeslagen URL | Gepubliceerde en afgedrukte links |
Het pad en de querystring behouden
Dit is de fout die het testen overleeft, omdat iedereen de domeinroot test en de root altijd werkt.
Wijs oldsite.com naar newsite.com met gewone domain forwarding en volg dan een echte inkomende link, oldsite.com/pricing?utm_source=newsletter. Met een afvlakkende redirect komt die bezoeker op de nieuwe homepage terecht, is het pad verdwenen, en zijn de campagneparameters ermee verdwenen. Er verschijnt geen enkele foutmelding. Je analytics tonen gewoon direct verkeer naar de homepage, en de nieuwsbrief lijkt niets te hebben gedaan.
Twee gewoontes voorkomen dit. Test met een diepe URL die een querystring meedraagt, nooit met het kale domein. En wanneer de twee sites verschillende structuren hebben, breng de belangrijke paden expliciet in kaart in plaats van alles naar de root te sturen, wat ook is wat de SEO-waarde van de oude URL's verbonden houdt aan de best passende nieuwe pagina. Dezelfde discipline geldt wanneer je andermans links erft, wat is waarom korte links migreren zonder ze te breken eerst een mapping-oefening is voordat het een technische is.
Als de links in kwestie links zijn die je hebt gepubliceerd, is de bestemming bewerkbaar houden meer waard dan al het bovenstaande: zet je links op je eigen domein en de mapping wordt een veld dat je verandert in plaats van een configbestand dat je deployt.
Verifieer het voordat je het aankondigt
Eén commando maakt het duidelijk:
curl -sIL "https://oldsite.com/pricing?utm_source=newsletter" | grep -E '^HTTP|^[Ll]ocation'
Lees drie dingen in de output. De statuscode moet die zijn die je bedoelde, 301 voor permanent en 302 zolang dingen nog in beweging zijn, en 301 versus 302 behandelt waarom die keuze meer uitmaakt dan het lijkt. De Location header moet het volledige pad en de querystring dragen, niet een kaal domein. En er zou precies één redirect moeten zijn: een keten van drie of vier lost nog steeds op, maar elke hop is latency en nog een kans om parameters te laten vallen, en een herhaalde hostnaam betekent dat je een redirect-lus hebt gebouwd in plaats van een redirect.
Als je liever geen terminal opent, traceert onze linkchecker de keten en toont hij de status bij elke hop.
Wat zoekmachines ermee doen
Een redirect die goed is gedaan, is geen SEO-risico, en de richtlijnen zijn hier ongewoon duidelijk over. Google's documentatie over redirects en Search behandelt een permanente serverside redirect als het sterkste signaal voor het consolideren van een URL op zijn vervanger, rangschikt clientside redirects daaronder, en vraagt je ketens kort te houden.
De twee fouten die je wel geld kosten, zijn veel oude URL's samenvoegen op de homepage, wat de specifieke relevantie weggooit die elk van hen had, en een keten van historische hops laten staan na meerdere migraties. Geen van beide is een reden om redirects te vermijden; beide zijn redenen om ze te auditen. Die audit is dezelfde wekelijkse gewoonte als linkrotpreventie, en als de redirect op een aangepast kort domein staat, behandelt aangepaste domeinen voor korte links de DNS- en certificaathelft van de opzet.
Kies de laag die past bij wie de wijziging bezit, behoud het pad, houd het bij één hop, en een redirect stopt iets te zijn waar je je zorgen over maakt.
Lees de cornerstone-serie
Dit artikel valt onder de tutorials-cluster. Voor de statuscodes en hun semantiek is soorten URL-redirects de kaart, en hoe URL-shorteners werken behandelt wat er gebeurt wanneer de redirect een link is in plaats van een pagina.
Gerelateerd op de blog
- Soorten URL-redirects: 301, 302, 307, 308 en meer
- 301 versus 302 redirects: welke jouw links moeten gebruiken
- Redirect-lus: hoe je ERR_TOO_MANY_REDIRECTS vindt en oplost
- Korte links met een aangepast domein: DNS, TLS en de edge
- Migreren van Bitly zonder je links te breken
- Schaden URL-shorteners de SEO? De mechanica die ertoe doet
Veelgestelde vragen
Hoe redirect ik een URL naar een andere URL?
Laat wat het verzoek ook beantwoordt een 301 of 302 teruggeven met een Location header die naar het nieuwe adres wijst. In de praktijk betekent dat een laag kiezen: domain forwarding bij je registrar, een regel in je webserver of hostingplatform, een plugin in je CMS, of een beheerde korte link. De methode verandert wie de respons serveert en of het pad en de querystring behouden blijven, niet wat de browser ontvangt.
Kan ik een URL redirecten met DNS?
Nee, en dit is het meest voorkomende misverstand in het hele onderwerp. DNS lost een hostnaam op naar een adres; het heeft geen idee welk pad werd opgevraagd en kan geen redirect teruggeven. Wanneer een registrar URL forwarding aanbiedt, wijst hij de hostnaam naar een eigen kleine webserver die de HTTP-redirect namens jou uitgeeft.
Behoudt een redirect het pad en de querystring?
Dat hangt volledig af van welke methode je koos. Domain forwarding bij de registrar vlakt vaak alles af naar één bestemming, waardoor /pricing?utm_source=email op de homepage terechtkomt met de parameters weg. Een server- of platformregel kan beide behouden als je hem zo schrijft, en een beheerde korte link stuurt de opgeslagen bestemming door inclusief de querystring. Test met een diepe URL, niet alleen met de kale domeinroot.
Moet ik een 301- of een 302-redirect gebruiken?
Gebruik een 301 wanneer de verhuizing permanent is en je wilt dat zoekmachines signalen consolideren op de nieuwe URL, en een 302 zolang er nog iets in beweging is. De praktische valkuil is dat browsers een 301 hardnekkig cachen, waardoor een permanente redirect waar je later spijt van krijgt nog lang na het aanpassen van de server blijft afvuren bij terugkerende bezoekers. Test met een 302, promoveer naar 301 zodra de bestemming vaststaat.
Hoe controleer ik of mijn redirect werkt?
Voer curl -sIL uit op de URL en lees de statusregels en Location headers. Je wilt één redirect, de juiste statuscode, en de bestemming die je verwachtte, met pad en query intact. Een keten van meerdere hops werkt nog steeds maar verspilt latency, en een herhaalde hostnaam betekent dat je een lus hebt gebouwd in plaats van een redirect.
Schaden redirects de SEO?
Een correct geïmplementeerde redirect niet. Google behandelt een 301 als een sterk signaal om ranking te consolideren op de bestemming, en lange ketens, niet redirects zelf, zijn wat problemen veroorzaakt. Houd het bij één hop, wijs oude URL's naar de best passende nieuwe pagina in plaats van alles op de homepage te dumpen, en vermijd clientside redirects wanneer een serverside redirect mogelijk is.
Probeer Elido
Plak een URL, krijg een werkende korte link
Geen aanmelding nodig. Link blijft 30 dagen actief. Meld je aan om hem voor altijd te bewaren.
Gratis, geen aanmelding nodig · 2 per dag