301 Redirect Checker: volg elke redirectketen

Een redirect checker laat zien wat er echt gebeurt tussen het klikken op een link en het landen op een pagina. Elke URL die je invoert wordt vanaf de server van Marqly opgevraagd met automatische redirects uitgeschakeld, zodat elk antwoord apart wordt vastgelegd: de statuscode, de Location-header waar het naartoe wijst, hoe lang het duurde en de headers die voor SEO ertoe doen. De tool volgt die locatie vervolgens en herhaalt dat, tot 10 redirects, dezelfde limiet die de crawlers van Google standaard gebruiken. Je krijgt de volledige redirectketen, de eind-URL en -status, en waarschuwingen in gewone taal voor loops, tijdelijke redirects, trage hops, verloren trackingparameters en ketens die het waard zijn samen te voegen.

Zo controleer je een redirect

1. Plak een URL in het vak. Voor een bulkcontrole plak je tot 10 URL’s, één per regel.
2. Kies een user agent als je er een nodig hebt. De standaard meldt zich als de Marqly-checker; je kunt ook de user agent van Chrome, Safari op iPhone, Googlebot smartphone of Googlebot desktop sturen om regels op te sporen die browsers, telefoons en crawlers verschillend behandelen.
3. Vink Controleer ook de http/https- en www/zonder-www-versies aan om alle vier de vormen van hetzelfde adres tegelijk te testen. Zo bevestig je het snelst dat een site één canonieke hostnaam heeft en dat elke variant die in één hop bereikt.
4. Klik op Redirects controleren. Elke URL krijgt een eigen kaart met het oordeel, hints en de keten hop voor hop.
5. Gebruik Resultaten kopiëren voor een tekstrapport, CSV downloadenvoor een spreadsheet met één rij per hop, of Deellink kopiëren om een link te sturen die dezelfde controle opnieuw uitvoert.

Zo lees je de resultaten

Elke kaart begint met de eind-statuscode, de URL die je invoerde, het aantal redirects, de totale tijd en de eind-URL. Daaronder wijzen hints aan wat aandacht verdient, van fouten (loops, ketens boven de limiet, een keten die op een 404 eindigt) tot waarschuwingen (tijdelijke redirects, meta refreshes, een downgrade van https naar http, weggevallen queryparameters, een X-Robots-Tag: noindex op de eindpagina) en neutrale opmerkingen (wijzigingen van slash of www, een verhuizing naar een ander domein, trage hops).

De ketentabel toont elk verzoek op volgorde. Status is de HTTP-statuscode die de server teruggaf. URL is wat werd opgevraagd en daaronder waar die hop de client vervolgens naartoe stuurt, al omgezet naar een absoluut adres als de server een relatieve Location stuurde. Tijd is hoe lang de server erover deed om de headers van die hop terug te geven. Open Headers op een rij omLocation, Cache-Control, Content-Type,X-Robots-Tag, Link (waar een canonical kan worden aangegeven),Strict-Transport-Security, X-Redirect-By (WordPress en sommige plug-ins noemen zichzelf hier) en Server te zien. Cookiewaarden worden nooit getoond, alleen hoeveel er zijn gezet.

301 vs 302 vs 307 vs 308: wat elke redirectcode betekent

HTTP definieert de redirectstatuscodes in RFC 9110, sectie 15.4. Twee vragen scheiden ze: is de verhuizing permanent, en mag de client de requestmethode veranderen (bijvoorbeeld een formulier-POST omzetten in een GET) als hij de redirect volgt? De documentatie van Google over HTTP-statuscodeslegt uit hoe de crawlers en de indexering elke code behandelen.

Gebruik voor gewone pagina’s 301 als inhoud definitief is verhuisd: een hernoemde slug, een samengevoegd artikel, een domeinmigratie, de overstap naar HTTPS. Gebruik302 of 307 als de oorspronkelijke URL terugkomt, zoals een onderhoudspagina, een korte campagne of een test. Kies 308 als de methode ertoe doet, bijvoorbeeld bij een API-endpoint of een formulier dat POST-verzoeken ontvangt, want RFC 9110 laat clients een doorgestuurde POST bij 301 en 302 in een GET veranderen maar verbiedt dat bij 307 en 308.

Meta refresh en JavaScript-redirects

De gids van Google over redirectsraadt waar mogelijk een permanente redirect aan de serverkant aan. Een directe meta refresh behandelt Google als permanente redirect en een vertraagde als tijdelijke, en JavaScript-redirects raadt hij alleen aan als redirects aan de serverkant en via meta refresh niet mogelijk zijn, omdat renderen kan mislukken. Deze checker volgt meta refresh-tags en deRefresh-header en labelt ze, maar voert geen JavaScript uit.

Wat is een redirectketen en waarom is die schadelijk?

Een redirectketen is elk pad met meer dan één hop: http://example.com/page →https://example.com/page → https://www.example.com/page →https://www.example.com/page/. Ketens ontstaan zelden met opzet. Ze stapelen zich op naarmate een site naar HTTPS verhuist, een voorkeur voor www kiest, van CMS wisselt, secties hernoemt en oude redirects doorstuurt in plaats van ze te herschrijven. Elke laag werkt op zichzelf; samen lopen ze op.

• Snelheid. Elke hop is een volledig extra verzoek voordat de pagina begint te laden, en een hop naar een nieuwe hostnaam voegt een DNS-opzoeking en een TLS-handshake toe. De tijdkolom toont wat elke hop kost.
• Crawlen. Google zegt dat zijn crawlers standaard tot 10 redirect-hops volgen, en het rapport Pagina-indexering noemt een te lange redirectketen, een redirectloop en een slechte of lege URL in de ketenredirectfouten. De gids van Google over siteverhuizingenraadt aan direct naar de eindbestemming door te sturen en merkt op dat ketens latentie toevoegen en dat niet alle user agents en browsers lange ketens ondersteunen.
• Andere clients. RFC 9110 merkt op dat een eerdere HTTP-specificatie maximaal vijf redirects aanbeval en dat sommige clients nog steeds zo’n vaste limiet kunnen afdwingen, dus een keten die Googlebot tolereert kan voor andere software toch breken.
• Kwetsbaarheid en verloren gegevens. Elke hop is een extra regel die kan worden aangepast, verwijderd of overschaduwd. Een hop die de URL opnieuw opbouwt kan querystrings ongemerkt laten vallen, en zo verdwijnen UTM-tags voordat analytics ze ooit ziet; de checker waarschuwt als een parameter uit je oorspronkelijke URL in de uiteindelijke ontbreekt.

Zo los je een redirectketen op

1. Zoek de eind-URL. Draai de oude URL door de checker en kopieer de laatste URL in de keten.
2. Laat de eerste redirect direct naar de eind-URL wijzen. Stuurt A door naar B en B naar C, pas dan de regel van A aan zodat hij direct naar C gaat en houd B → C voor iedereen die B nog heeft. Zoek in een redirectmap of plug-in naar regels waarvan het doel zelf de bron van een andere regel is.
3. Combineer protocol- en hostnaamregels. De gangbaarste keten is http → https gevolgd door zonder-www → www. Schrijf één regel die elke variant in één stap naar de canonieke vorm stuurt, zoals in dit nginx-voorbeeld:

# Eén hop van elke variant naar https://www.example.com
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-regels weggelaten
    return 301 https://www.example.com$request_uri;
}

4. Werk links bij de bron bij. Pas interne links, canonical-tags, hreflang-annotaties en XML-sitemaps aan naar de eind-URL’s; de gids van Google over siteverhuizingen vraagt om interne links naar de nieuwe URL’s bij te werken. Redirects horen oude links van elders op te vangen en niet je eigen navigatie te dragen.
5. Houd de redirects in stand. Google raadt aan redirects zo lang mogelijk te bewaren, in het algemeen minstens een jaar. Een keten samenvoegen betekent hem een nieuw doel geven, niet de oude regels verwijderen.
6. Test opnieuw. Draai dezelfde URL’s nog eens, bij voorkeur met de variantenoptie aangevinkt, en bevestig dat elke URL in één hop een 200-pagina bereikt.

Redirectloops oplossen

Een loop is een keten die terugkeert naar een URL die hij al bezocht, en dus nooit eindigt; browsers tonen dan een melding over te veel redirects. De gebruikelijke oorzaken zijn twee lagen die het oneens zijn: een CDN dat via HTTP met de origin praat terwijl de origin HTTPS afdwingt, een slashregel in de webserver die vecht met de omgekeerde regel in de applicatie, of www-regels die zowel in DNS-doorsturing als in de site staan. Kijk naar de hop waar de URL terugspringt; de headers Server en X-Redirect-By vertellen vaak welke laag hem stuurde. Sommige loops ontstaan alleen zonder cookies (toestemmings- of loginredirects) en raken bezoekers die ze al hebben niet; de checker stuurt geen cookies en brengt die dus ook aan het licht.

Redirects in bulk controleren

Plak tot 10 URL’s, één per regel, om ze in één run te controleren; dubbelen worden verwijderd en elke URL krijgt een eigen resultaat. De CSV-export heeft één rij per hop met de invoer-URL herhaald, zodat je op status kunt filteren, op aantal hops kunt sorteren of het bestand kunt geven aan wie de redirectregels beheert. Voor een lijst met oude bladwijzers of links uit een document haal je de URL’s er eerst uit met debookmark file viewer (in het Engels) en controleer je daarna welke simpelweg dood zijn met decontrole op dode links, die 25 URL’s per keer aankan. Voor een hele site gebruik je een crawler of je serverlogs om doorgestuurde URL’s te vinden en controleer je de belangrijke hier steekproefsgewijs met de Googlebot-user-agent.

HTTPS, www en slashes aan het eind

De meeste sites horen op precies één combinatie van protocol en hostnaam te antwoorden, waarbij elke andere vorm er permanent en in één hop naartoe verwijst. De variantenoptie controleerthttp://example.com, https://example.com,http://www.example.com en https://www.example.com met hetzelfde pad en meldt of alle vier op dezelfde URL eindigen en hoeveel hops elk kost. De hints wijzen op een HTTPS-upgrade die laat in de keten gebeurt, een keten die meer dan één keer tussen www en zonder-www wisselt, en hops die alleen een slash toevoegen of weghalen of hoofdletters veranderen, en die je goedkoop in de eerste redirect kunt opnemen.

Waarom resultaten van je browser kunnen afwijken

Landt je browser ergens anders, dan onthoudt hij meestal iets. RFC 9110 staat toe dat een 301 wordt gecachet, dus een browser kan een oude redirect overslaan of er een blijven volgen die je al hebt verwijderd. Zodra een browser de HSTS-header van een site heeft gezien (of de site op de HSTS-preloadlijst staat), upgradet hij http:// intern naar https://voordat er een verzoek je machine verlaat. Cookies, je taal en je locatie kunnen eigen redirects uitlokken. De checker begint elke keer schoon en meldt wat de server stuurt, en dat is het beeld dat telt voor crawlers en nieuwe bezoekers.

Hoe de checker werkt

Elke hop is een GET-verzoek vanaf de server van Marqly op Cloudflare met redirects op handmatig, zodat niets wordt gevolgd voordat de checker het heeft vastgelegd. Elke hostnaam wordt omgezet en moet naar een openbaar adres wijzen; privénetwerken, localhost en metadata-adressen van clouds worden geweigerd, ook als een redirect halverwege de keten naar zo’n adres wijst. Elke hop heeft een time-out van 6 seconden, een hele keten stopt na 20 seconden of 10 redirects, en paginainhoud wordt weggegooid behalve de eerste 64 KB van een HTML-eindpagina, die op een meta refresh wordt doorzocht. Er wordt niets bewaard: de resultaten bestaan alleen in je browsertabblad.

Haal voordat je een link deelt die door een redirect of linkverkorter ging de trackingrommel weg met de URL-opschoner. Bouw je campagnelinks, dan maakt de UTM-builder ze en bevestigt deze checker dat de parameters elke hop overleven. Zodra de eindpagina laadt, bekijk je de titel, beschrijving en social preview die hij serveert met de Open Graph checker (in het Engels).