Redirectketens opsporen voor je belangrijkste URLs
7 november 2026 · 8 min leestijd · Marketing Scan
In dit artikel
Welke URLs je eerst onderzoekt
Je hoeft niet je hele site te doorlopen. Begin met een lijst van hooguit enkele tientallen adressen die voor je bedrijf het zwaarst wegen. Denk aan de homepage, je belangrijkste dienst- of categoriepagina's, pagina's waar advertenties of nieuwsbrieven naartoe linken en pagina's met veel externe links.
Vul die lijst aan met adressen uit twee bronnen. De eerste is de prestatiegegevens in Search Console. Volgens de Search Console-startgids van Google toont dat rapport verkeer uit Google Search per zoekopdracht, pagina en land. Gebruik het om pagina's te vinden die nu al bezoekers opleveren. De tweede bron zijn je eigen oude adressen: vorige domeinnaam, oude mapstructuur, versies met en zonder www, met en zonder slash en met http. Zulke varianten zijn de meest voorkomende beginpunten van een keten.
Noteer per rij één bedoeld eindadres: het adres dat je wilt dat bezoekers en Google uiteindelijk zien. Zonder die afspraak weet je later niet of een keten klopt.
Elke stap en eindstatus vastleggen
Volg elk beginpunt hop voor hop. Dat kan met een crawler of via de ontwikkelaarstools van je browser, tabblad netwerk, met behoud van logboek. Een browser toont wat een bezoeker meemaakt. Dat een pagina in de browser laadt of status 200 geeft, bewijst niet dat Googlebot de keten kan crawlen of hoe Googlebot haar behandelt, want Googlebot houdt zich aan robots.txt en een gewone browser niet. Gebruik voor Google waar nodig URL-inspectie in Search Console.
Leg per beginpunt vast:
- het startadres;
- elke tussenstap met de statuscode (bijvoorbeeld 301, 302, 307 of 308);
- het eindadres en de eindstatus (200, 404 of iets anders);
- of het eindadres overeenkomt met het afgesproken bedoelde adres;
- de datum en de manier waarop je gecontroleerd hebt.
Let op twee zaken die in geen enkele tool vanzelf zichtbaar worden. Sommige verwijzingen worden niet door de server gedaan maar door JavaScript, bijvoorbeeld via een scriptmatige wijziging van de locatie. Zulke omleidingen zie je soms pas na renderen. De JavaScript-SEO-basisgids van Google beschrijft dat pagina's eerst gecrawld en daarna gerenderd worden, waarbij de pagina enige tijd in een wachtrij kan staan. Controleer dus de weergegeven pagina en niet alleen de ruwe HTML. Let ook op ketens die in lussen eindigen: noteer die apart, want ze hebben geen eindadres.
Beslisblad: wat doe je met welke keten
Gebruik de volgende beslisregels per rij van je blad. Ze zijn bedoeld als eigen werkregels, niet als vaste waarheid voor elke site.
| Situatie | Actie |
|---|---|
| Eén hop naar het bedoelde eindadres met status 200 | Laten staan; alleen interne links controleren |
| Twee of meer hops naar het bedoelde eindadres | Redirectregel van het beginpunt direct naar het eindadres laten wijzen |
| Keten eindigt op een ander adres dan afgesproken | Eerst beslissen welk adres bedoeld is, dan regels aanpassen |
| Keten eindigt op 404 of foutpagina | Nieuw doel kiezen met een inhoudelijk passende pagina, of bewust laten vervallen |
| Lus zonder eindadres | Direct herstellen; de pagina is voor bezoekers onbereikbaar |
| Omleiding via JavaScript | Serverzijdige redirect overwegen en effect controleren in URL-inspectie |
Een belangrijke nuance: het kiezen van een tijdelijke of permanente omleiding is een inhoudelijke keuze. Een permanente omleiding is volgens de documentatie van Google over canonieke URLs een duidelijk signaal dat het doeladres het canonieke adres moet zijn. Gebruik dat dus alleen als je dat ook echt bedoelt. Schrijf je voor een tijdelijke actie een permanente regel, dan stuur je een signaal dat je later weer moet terugdraaien.
Interne verwijzingen inkorten tot het eindadres
Een redirect repareren op serverniveau lost maar de helft op. Veel ketens blijven in stand omdat je eigen site nog naar het oude adres verwijst. Alle interne links horen direct naar het bedoelde eindadres te wijzen. Dat staat ook in de aanbevolen werkwijzen van Google voor canonieke URLs: wijs links binnen je site naar het canonieke adres en niet naar een duplicaat.
Werk de volgende plekken na, in deze volgorde:
- hoofdmenu, footer en breadcrumbs;
- links in lopende content, zoals blogartikelen en dienstpagina's;
- de sitemap: neem alleen eindadressen op, geen adressen die doorverwijzen;
- de canonical-annotatie op de pagina zelf, die naar het eigen eindadres hoort te wijzen;
- social profielen, e-mailhandtekeningen, nieuwsbrieftemplates en advertentie-bestemmingen.
Zorg dat je methodes niet tegenspreken. Een sitemap die adres A noemt, een canonical die adres B noemt en een redirect die naar C leidt, geeft Google drie verschillende signalen. Volgens de documentatie van Google moet je niet via verschillende methoden verschillende URLs als canoniek aanwijzen; zo'n combinatie is dus iets om te vermijden. Houd per pagina dus één eindadres aan in alle signalen.
Controle na de wijziging
Herhaal na je aanpassing dezelfde meting als in sectie 2 op je lijst van belangrijkste URLs. Het beoogde resultaat is: elk beginpunt heeft nog hooguit één hop, of is een rechtstreeks eindadres, en elk eindadres geeft de afgesproken status.
Gebruik daarna Search Console voor wat je zelf niet kunt zien. Open URL-inspectie voor een paar sleuteladressen en lees de geïndexeerde versie, niet de live test, als je wilt weten welke canonical Google heeft gekozen. De gekozen canonical staat in de geïndexeerde gegevens. Vergelijk die met je blad. Bekijk ook de dekkings- of indexeringsrapporten voor foutmeldingen en waarschuwingen. Volgens de startgids van Google hoef je niet dagelijks in te loggen: een maandelijkse controle of een controle na inhoudelijke wijzigingen is voldoende, en bij nieuwe problemen stuurt Search Console een e-mail.
Wees eerlijk over de onzekerheid. Een herstelde keten garandeert niet dat Google de gewenste pagina meteen of in een bepaalde termijn indexeert. Een canonical-annotatie is een signaal en geen opdracht. Als de gekozen canonical blijft afwijken, onderzoek je welke andere signalen (interne links, sitemap, inhoud) nog naar iets anders wijzen.
Fictief overdrachtsvoorbeeld voor je blad
Dit voorbeeld is volledig verzonnen en bevat alleen invoer en verwachte controles. Stel dat je een dienstpagina hebt met als bedoeld eindadres https://www.voorbeeld.example/diensten/boekhouding/. Je blad bevat drie beginpunten.
Beginpunt 1 is http://voorbeeld.example/boekhouding. Je verwacht bij de meting een rij hops: eerst naar https, dan naar www, dan naar de nieuwe mapstructuur. Beslissing: één regel van het beginpunt direct naar het eindadres.
Beginpunt 2 is https://www.voorbeeld.example/diensten/boekhouding zonder slash. Verwachte controle: één hop naar de versie met slash, of beter, een canonical die naar het eindadres wijst en interne links die al de slashvariant gebruiken.
Beginpunt 3 is een oude campagnepagina die nu op 404 eindigt. Beslissing: beoordeel of een inhoudelijk passende pagina bestaat. Bestaat die niet, laat dan bewust vervallen en haal het adres uit sitemap en interne links.
Geef het blad zo door: per rij het beginpunt, de gemeten keten, het bedoelde eindadres, de gekozen actie, wie de wijziging doet en de herhaalcontrole met datum. Wie het blad overneemt, kan dan zonder voorkennis nagaan wat al is gedaan en wat nog open staat.
Wil je ook zien welke publieke signalen je website nu uitzendt, bijvoorbeeld in titels, structuur en zichtbare verwijzingen? Bekijk ze via Marketing Scan. Dat is een eerste blik op zichtbare signalen; de controles in deze gids, zoals het volgen van elke hop en het uitlezen van de gekozen canonical in Search Console, blijven werk dat je met je eigen tools en toegang uitvoert.
Veelgestelde vragen.
Hoeveel hops zijn nog acceptabel in een redirectketen?
De bronnen geven hier geen vast getal voor, dus noem ik er geen. Als werkregel houd je het bij één hop waar dat kan en repareer je alles waarbij het eindadres afwijkt van wat je bedoelt. Elke extra tussenstap is een extra plek waar een regel kapot kan gaan.
Moet ik de oude redirect ook verwijderen nadat ik interne links heb aangepast?
Meestal niet. De redirect vangt nog bezoekers en externe links op die naar het oude adres wijzen. Verwijder hem pas als je zeker weet dat geen enkele bekende bron het oude adres meer gebruikt, en controleer dat met je blad.
Kan ik een redirectketen in Search Console zien?
Search Console toont indexeringsstatussen en de door Google gekozen canonical in de geïndexeerde URL-inspectiedata, maar niet noodzakelijk elke hop. Voor het volgen van de keten zelf heb je een crawler of je browser nodig, en voor Google gebruik je URL-inspectie als aanvulling.
Is een JavaScript-omleiding hetzelfde als een serverredirect?
Nee. Een serverredirect werkt al in het HTTP-antwoord. Een JavaScript-omleiding werkt pas na het renderen van de pagina, wat volgens Google in een aparte stap en soms met enige vertraging gebeurt. Voor belangrijke adressen is een serverredirect de voorspelbaardere keuze.
Bronnen bij dit artikel
Hoe werkt een marketing scan? Meetmethode en grenzen
Van advies naar actie voor jouw website
Maak een gratis account voor één website. Controleer zes kenmerken van je homepage en bekijk maximaal drie bevindingen.
Herhaal de check handmatig één keer per zeven dagen. Voor volledige audits en automatische opvolging is uitgebreide toegang nodig.
Maak je gratis account