Redirectketen en SEO: hoeveel hops zijn te veel?

Een redirectketen is twee of meer redirects achter elkaar tussen de URL die iemand opvroeg en de pagina die uiteindelijk met een 200 antwoordt. Google documenteert dat Googlebot tot 10 hops volgt, adviseert rechtstreeks naar de eindbestemming door te sturen en noemt lange ketens een rem op het crawlen. Het zegt niet dat ze de ranking vernietigen, en het zegt dat permanente redirects geen verlies van PageRank veroorzaken. De eerlijke samenvatting is dus dat ketens een probleem van latentie en crawl-efficiëntie zijn dat je goedkoop moet oplossen, geen SEO-catastrofe.

De meeste ketens worden niet met opzet gebouwd. Iemand voegt een HTTPS-regel toe, iemand anders een www-regel, een marketingtool wikkelt de link in een tracker, en elke hop is op zichzelf redelijk. Hieronder: hoe de lagen zich opstapelen, wat elke hop kost, welke SEO-claims standhouden tegen de documentatie van Google, en hoe je een keten traceert en afvlakt. Voor de woordenschat van statuscodes eerst is soorten URL-redirects de kaart. Als de keten in zichzelf terugloopt, wil je in plaats daarvan hoe je een redirect-lus oplost.

Wat een redirectketen is

Een redirectketen ontstaat wanneer URL A doorstuurt naar B, en B doorstuurt naar C, in plaats van dat A rechtstreeks naar C wijst. Elke pijl is een eigen HTTP-respons, en de client doet voor elke een nieuw verzoek. Eén redirect is normaal; "keten" begint bij twee.

Meerdere redirects en redirecthops beschrijven hetzelfde vanuit verschillende hoeken: het aantal redirects tussen verzoek en eindpagina. Een redirect-lus is een keten die nooit eindigt omdat hij een URL opnieuw bezoekt. Een keten eindigt daarentegen wel; het duurt alleen te lang om er te komen.

Hoe redirectketens ontstaan

Ketens stapelen zich op omdat elke laag zijn eigen voorkeur afdwingt. De gebruikelijke lagen, in de volgorde waarin een verzoek ze tegenkomt:

• Schema. http:// gaat naar https://, meestal in een server- of proxyregel.
• Host. De apex gaat naar www, of omgekeerd, in een andere regel die na de schemaregel afgaat.
• Pad. Een normalisator voor slotstreepjes of kleine letters herschrijft /Promo/ naar /promo.
• Campagne- of trackingwrapper. Een advertentieklik-tracker, de linkherschrijver van een e-mailplatform of een korte link staat vóór al het andere.
• Legacy-map. Een redirect van een eerdere redesign die niemand opnieuw heeft gewezen.

Zet ze samen en een gewone http://example.com/Promo/ kan vier hops nemen: naar HTTPS, dan naar www, dan naar het genormaliseerde pad, dan via een oude redesignregel naar de live pagina. Korte links sluiten vooraan aan. Een is een legitieme hop. De schade begint wanneer de bestemming niet de uiteindelijke URL is. Plak http://example.com/promo als doel en je link staat aan het hoofd van een keten die de bestemmingssite ongezien bouwde. Schaden URL-verkorters SEO behandelt de rankingkant van die vraag; het korte antwoord is dat één schone hop prima is en een gestapelde aan jou is om op te lossen.

Ketens zijn makkelijk te missen omdat browsers ze verbergen: de adresbalk toont de uiteindelijke URL en de pagina laadt, dus niets lijkt mis. Ze verschijnen ook alleen voor de verzoekvariant die elke regel activeert, meestal de oudste http://-link op het oudste gedrukte materiaal.

Hoeveel hops volgt Googlebot?

Googlebot volgt standaard tot 10 redirecthops. Dat komt rechtstreeks uit de crawlerdocumentatie van Google. Die voegt toe dat specifieke Google-producten andere limieten kunnen gebruiken en dat de URL-inspectietool helemaal geen redirects volgt. Google zegt niet wat er met een langere keten gebeurt, dus ga ervan uit dat de bestemming simpelweg niet wordt bereikt.

Tien is een plafond, geen aanbeveling. De richtlijnen van Google voor sitemigraties zeggen rechtstreeks naar de eindbestemming door te sturen en, wanneer dat niet kan, de keten laag te houden, "ideally no more than 3 and fewer than 5", omdat ketens latentie voor gebruikers toevoegt en niet alle user agents lange ketens ondersteunen. Citeer dat: een doel van één hop, een tolerantie van een paar en een harde stop bij tien.

Browsers hebben hun eigen limieten. Chrome geeft op bij 20 en geeft ERR_TOO_MANY_REDIRECTS terug, het symptoom dat in de gids over redirect-lussen wordt behandeld. De HTTP-standaard legt ook geen getal vast: RFC 9110 zegt alleen dat clients cyclische redirects moeten detecteren en erop moeten ingrijpen.

Wat elke hop kost aan latentie

Elke hop kost minstens één netwerkronde. Een hop naar een andere hostnaam kost meer. De client lost de nieuwe naam op, opent een TCP-verbinding en voltooit een TLS-handshake voordat hij iets kan versturen. De eigen audit van Lighthouse laat een pagina met twee of meer redirects falen en zegt dat de extra reis een resource "by hundreds of milliseconds" kan vertragen.

Hier is de rekensom, als illustratie en niet als benchmark. Neem een round trip van 100 ms aan, gewoon voor een mobiele verbinding met een matig signaal. Een hop naar een nieuwe host met DNS, TCP en een TLS 1.3-handshake vóór het verzoek kan makkelijk drie tot vier rondes kosten, dus 300 tot 400 ms. Een hop die een open verbinding met dezelfde host hergebruikt, kost er een, dus 100 ms. Een keten van vier hops met twee nieuwe verbindingen besteedt dan ruwweg 900 ms voordat de echte pagina begint, tegen ongeveer 450 ms voor één vlakke redirect.

Mobiel maakt het erger om een eenvoudige reden: latentie, niet bandbreedte, is de beperking. Redirectresponsen zijn piepklein, dus het wachten bestaat volledig uit rondes, en een sneller abonnement doet er niets aan. Een hop verwijderen is vaak goedkoper dan een afbeelding verkleinen. Voor wat een enkele hop aan serverkant zou moeten kosten, zie hoe redirects onder 15 ms komen.

Ketens verliezen ook data. Elke hop is een plek waar een herschrijfregel een querystring kan laten vallen, en een weggestripte utm_source is de gebruikelijke manier waarop UTM-parameters verdwijnen uit analytics.

Linkwaarde en crawlbudget: wat Google documenteert

Eerst linkwaarde. De documentatie van Google over sitemigraties stelt dat "301 and other permanent redirects don't cause a loss in PageRank". Gary Illyes van Google zei in 2016 hetzelfde over 30x-redirects, maar dat was een bericht op social media, geen documentatie. De oude vuistregel dat elke redirecthop een vast percentage waarde lekt, is dus folklore. Geen enkele bron van Google noemt een percentage, en je ziet getallen zoals 15 procent in SEO-artikelen herhaald zonder bronvermelding. Als iemand je er een geeft, vraag dan om de bron.

Ketens zijn toch niet gratis. Twee effecten zijn gedocumenteerd. Ten eerste crawl-efficiëntie: de crawlbudgetrichtlijnen van Google voor grote sites zeggen ronduit lange redirectketens te vermijden, die een negatief effect op het crawlen hebben. Ten tweede gebruikerslatentie, hierboven behandeld, die de signalen voor paginabeleving voedt. Crawlbudget doet er vooral toe op zeer grote of snel veranderende sites; een site van 200 pagina's merkt van een paar ketens waarschijnlijk geen crawlbudgetprobleem, al voelen bezoekers de snelheidskosten wel.

Er is ook een nuance voor indexering. Google gebruikt permanente redirects als canoniek signaal voor de bestemming. Welke URL wordt getoond, hangt deels af van of elke redirect tijdelijk of permanent was. Een keten die 301- en 302-hops mengt, maakt dat signaal minder duidelijk, wat een goede reden is om de codes eenmalig vast te leggen. Canonical vs 301-redirect gaat in op hoe die signalen samenwerken.

Mijn standpunt: raak niet in paniek over waarde, los ketens op voor snelheid en crawlhygiëne, en beloof geen rankingwinst van het afvlakken van een keten. Niemand heeft die winst gedocumenteerd. Snellere laadtijden en minder verspilde fetches zijn wat je kunt meten.

Hoe je redirectketens opspoort

Begin met curl, omdat die elke hop afdrukt waar een browser ze verbergt. Het eerste commando toont de statusregel en Location van elke respons:

curl -sIL http://example.com/Promo/ | grep -E '^HTTP|^[Ll]ocation'

Een schoon resultaat is een 3xx gevolgd door een 200. Een keten toont eerst twee of meer 3xx-regels. Voor een telling en de tijd die in redirects wordt besteed, vraag je curl om zijn eigen getallen:

curl -sL -o /dev/null \
  -w 'hops: %{num_redirects}\nfinal: %{url_effective}\nredirect time: %{time_redirect}s\ntotal: %{time_total}s\n' \
  http://example.com/Promo/

Twee kanttekeningen. -I stuurt een HEAD-verzoek, en enkele servers antwoorden anders op HEAD dan op GET, dus als het resultaat te schoon lijkt, herhaal dan zonder -I en gooi de body weg met -o /dev/null -D -. En test de slechtste variant, die welke elke regel zou activeren: http://, geen www, hoofdletters in het pad, slotstreepje. Alleen de canonieke URL testen is hoe ketens overleven. Ik test liever de lelijke varianten te veel dan de schone te vertrouwen.

Open in een browser de devtools, ga naar het Network-paneel, vink "Preserve log" aan zodat eerdere hops de navigatie overleven en laad opnieuw. Elke redirect verschijnt als een eigen 301- of 302-rij. Onze linkchecker toont dezelfde keten zonder terminal.

Om een hele site te auditen heeft een desktopcrawler zoals Screaming Frog of Sitebulb een rapport over redirectketens dat elke keten met elke hop en de statuscodes opsomt. Zet voor langlevende links dezelfde trace in een geplande taak, zoals in redirects van links bewaken.

Hoe je een redirectketen afvlakt

Afvlakken betekent dat elke legacy-URL rechtstreeks naar de uiteindelijke URL wijst. Stappen, op volgorde:

1. Kies de canonieke vorm: schema, host, beleid voor slotstreepjes en hoofdletters. Schrijf het op.
2. Trace elke oude URL en noteer zijn eindbestemming.
3. Herschrijf elke regel zodat hij naar die eindbestemming wijst, niet naar de volgende regel.
4. Werk interne links, sitemaps en rel="canonical"-tags bij naar de uiteindelijke URL, zodat crawlers en gebruikers de keten helemaal niet meer binnenkomen.
5. Draai de trace opnieuw en bevestig maximaal één hop.

De truc aan serverzijde is schema en host in één regel te combineren. In nginx ziet dat er zo uit, met $request_uri zodat pad en querystring behouden blijven:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    # ssl_certificate and key directives go here
    return 301 https://www.example.com$request_uri;
}

Een verzoek voor http://example.com/page gaat nu in één hop naar https://www.example.com/page, waar twee regels er twee zouden hebben opgeleverd. Een redirect instellen in .htaccess en hoe je een URL doorstuurt behandelen de Apache- en applicatieniveau-equivalenten.

Test eerst met 302. Browsers cachen 301 agressief, dus een fout blijft hangen. Zodra de keten uit één hop bestaat, schakel je over op de permanente code. HSTS helpt ook: nadat een browser een Strict-Transport-Security-header heeft gezien, upgradet hij http:// intern naar https://, zodat terugkerende bezoekers die hop helemaal overslaan. Het doet niets voor crawlers of nieuwe bezoekers, dus het vult de regel van één hop aan en vervangt hem niet.

Als ketens blijven terugkomen, is de oorzaak proces, geen syntaxis; het voorkomen van linkrot beschrijft de auditgewoonte die voorkomt dat oude maps zich opstapelen.

Hoe een goedgemanierde redirect van een korte link eruitziet

Een korte link moet precies één hop zijn van de slug naar de definitieve canonieke pagina, en niets anders. Het verzoek bereikt het korte domein. De respons is een 3xx met de bestemming in Location. De bestemming antwoordt rechtstreeks met 200. Geen tussenliggende verkorter, geen tracker die opnieuw doorstuurt, geen bestemming die naar www of naar HTTPS hopt omdat je de oude vorm plakte.

De code hangt af van het gebruik.

• 302 (of 307) voor getrackte, bewerkbare links in campagnes, socialmediaberichten, e-mail en QR-codes. Het laat je de bestemming later omleggen en houdt elke klik bij de redirectlaag zodat analytics compleet blijven.
• 301 (of 308) wanneer de verhuizing permanent is en je wilt dat de bestemming als canoniek wordt behandeld, zoals een vanity-URL die een oud adres voorgoed vervangt.

301 vs 302-redirects loopt de cachingval door die de 302-standaard verstandig maakt. Twee gewoonten houden de keten op één hop. Plak altijd de uiteindelijke URL als bestemming, nadat je hem eenmaal hebt geladen en het adres uit de balk hebt gekopieerd, en draai de curl-telling hierboven op nieuwe links vóór de lancering. Wil je die bestemming eenmaal opgeslagen en bewerkbaar zonder opnieuw te drukken, begin dan met een gratis Elido-werkruimte en trace je eerste link met de commando's in dit artikel.

Derden kunnen hops toevoegen waar je geen controle over hebt. De klik-tracker van een advertentieplatform of de linkwrapper van een e-mailprovider staat vóór je korte link, of je dat nu wilt of niet, en dat is het beste argument om je eigen deel van het pad op één hop te houden. Een merkdomein voegt er geen toe, zoals eigen domeinen voor korte links uitlegt.

Dit artikel staat in het engineering-cluster. Voor de volledige kaart van statuscodes lees je soorten URL-redirects, en voor de redirectlaag achter een korte link, hoe URL-verkorters werken.

Gerelateerd op de blog

• Redirect-lus: hoe je ERR_TOO_MANY_REDIRECTS vindt en oplost
• Soorten URL-redirects: 301, 302, 307, 308 en meer
• 301 vs 302-redirects: welke moeten korte links gebruiken
• Schaden URL-verkorters SEO? Het eerlijke antwoord
• Canonical vs 301-redirect: zo kies je het juiste signaal
• Hoe je een URL doorstuurt: zes manieren, en wanneer elke past