Redirectketens en loops opsporen voor SEO-migraties

Redirectketens ontstaan wanneer URL A naar URL B redirect, URL B naar URL C redirect en de request pas daarna de eindbestemming bereikt. Redirectloops ontstaan wanneer het pad nooit stabiel eindigt.

Beide problemen zijn oplosbaar. Toch komen ze vaak voor bij hostwissels, domeinforwarding met padbehoud, CMS-replatforming en haastige SEO-migraties.

Een keten ziet er zo uit:

/old-page -> /legacy-page -> /new-page

Een loop ziet er zo uit:

/old-page -> /new-page -> /old-page

Voor SEO, performance en QA wil je zo dicht mogelijk bij dit principe blijven: een request, een redirect, een bestemming.

Waarom ketens en loops slecht zijn

Ze vertragen echte gebruikers

Elke extra hop kost tijd. Een enkele extra redirect lijkt klein, maar ketens stapelen latency op in het kritieke pad.

Ze maken migraties onduidelijk

Een redirectmap moet een verhuizing overzichtelijk maken. Ketens doen het tegenovergestelde: ze verbergen welke URL echt canonical is.

Ze verspillen crawl- en QA-capaciteit

Zoekmachines kunnen redirects volgen, maar een rommelig redirectsysteem is moeilijker te crawlen, valideren en onderhouden dan een directe mapping met één hop.

Loops breken de request

Een loop is geen performanceprobleem. Het is een fout. De browser landt nooit op een stabiele bestemming.

Veelvoorkomende oorzaken van redirectketens

Ketens ontstaan vaak wanneer meerdere redelijke regels over tijd worden toegevoegd zonder centrale eigenaar.

Typisch patroon:

1. HTTP -> HTTPS
2. non-www -> www
3. oude slug -> nieuwe slug
4. CMS-plugin voegt nog een redirect toe
5. het canonical domein verandert later opnieuw

Los bekeken klinkt elke regel logisch. Samen maken ze een keten.

http://old-brand.example/docs
  -> https://old-brand.example/docs
  -> https://www.old-brand.example/docs
  -> https://new-brand.example/docs

Dit hoort meestal direct te worden:

http://old-brand.example/docs
  -> https://new-brand.example/docs

Veelvoorkomende oorzaken van loops

Loops komen meestal door conflicterende logica:

• een hostregel stuurt verkeer naar een andere host
• een tweede regel stuurt het terug
• app middleware spreekt de edge-regel tegen
• locale- of deviceregels hebben geen stabiele fallback
• een CMS-plugin blijft actief nadat CDN-regels live zijn gegaan

Tijdens migraties zijn vaak te veel systemen tegelijk actief: CDN, applicatie, reverse proxy en CMS. Kies een eigenaar voor redirectlogica en zet oude lagen uit waar mogelijk.

Zo vind je redirectketens

Gebruik niet alleen een browser. Browsers cachen redirects en verbergen soms tussenstappen.

Controleer met:

• een redirect checker
• commandlinetools zoals curl -I -L
• crawltools voor grote redirectmaps
• access logs tijdens staging en launch

Voor een losse URL kun je starten met:

curl -I -L https://old-brand.example/docs

Let op:

• hoeveel Location-headers je ziet
• welke statuscodes worden gebruikt
• of HTTP en HTTPS door elkaar lopen
• of queryparameters behouden blijven

Zo los je ketens op

1. Bepaal de eindbestemming

Vraag niet alleen "waar gaat deze URL nu heen?". Vraag: "waar zou deze URL direct heen moeten?".

2. Verwijs oude URL direct naar de eind-URL

Vervang:

/a -> /b -> /c

door:

/a -> /c

3. Update interne links

Als je interne links nog naar oude URL's wijzen, blijven ketens terugkomen. Redirects zijn vangnetten, geen vervanging voor canonical interne links.

4. Verwijder dubbele regels

Zoek naar regels die hetzelfde pad of dezelfde host op meerdere lagen verwerken.

Zo voorkom je loops

Een loop voorkomen is vooral discipline:

• definieer een definitieve canonical host
• maak fallbackbestemmingen expliciet
• test geo-, device- en taalregels samen
• blokkeer regels waarin bron en bestemming gelijk zijn
• laat een simulator elke regel testen voordat die live gaat

In UrlEdge detecteren we loops tijdens validatie waar mogelijk, maar app- of CMS-redirects buiten de edge kunnen nog steeds conflicten veroorzaken. Test daarom altijd het volledige pad.

Checklist voor migraties

Voor elke URL met hoge waarde:

• eindigt de redirect in een HTTP 200?
• is er maximaal één hop?
• is de statuscode logisch: 301/308 permanent, 302/307 tijdelijk?
• blijft het pad behouden wanneer dat nodig is?
• blijven UTM- of partnerparameters behouden?
• gedragen mobiel, desktop en bots zich consistent?

Gebruik deze checks vooral bij domein doorsturen met pad en querybehoud en bij grote website migraties.

Veelgemaakte fouten

Alleen de eindbestemming controleren

Een browser die uiteindelijk een pagina toont, bewijst niet dat de route schoon is. Je moet de tussenstappen zien.

HTTP en hostnormalisatie stapelen

HTTP -> HTTPS en non-www -> www hoeven geen losse hops te zijn als je direct naar de canonical URL kunt sturen.

CMS-plugins actief laten

Laat niet tegelijk je CMS, CDN en edge-platform dezelfde redirects beheren zonder duidelijke verantwoordelijkheid.

Locale- en device-regels zonder fallback

Elke conditionele regel heeft een stabiele default nodig. Anders ontstaan onverwachte terugroutes of loops.

UrlEdge aanpak

Gebruik UrlEdge om:

• redirectpaden te testen
• bulk redirectmaps op loops te controleren
• wildcard- en regexregels eerst te simuleren
• oude regels naar eindbestemmingen te consolideren
• analytics te monitoren na launch

Een goede redirectarchitectuur voelt saai: weinig hops, duidelijke statuscodes en voorspelbare bestemmingen. Dat is precies wat je wilt.