TrueURL

Gratis redirecttool

Meta-refresh-checker

Niet elke redirect is een HTTP-statuscode. TrueURL leest de HTML van elke pagina in de keten en vindt meta-refresh-tags en JavaScript-redirects, met hun doel-URL en vertraging.

Wat is een meta-refresh-redirect?

Een meta refresh is een HTML-tag die de browser na een aantal seconden een andere URL laat laden:

<meta http-equiv="refresh" content="0; url=https://example.com/new-page">

Met een vertraging van 0 gedraagt hij zich als een normale redirect. Bij een langere vertraging zien bezoekers eerst de pagina, zoals op de ouderwetse pagina’s met “Even geduld, je wordt doorgestuurd”. JavaScript-redirects doen hetzelfde met code zoals location.href = '...' of location.replace('...'). Beide zijn client-side redirects: de server antwoordt met 200 OK en de browser verzorgt het doorsturen.

Zo detecteert TrueURL client-side redirects

Bij elke HTML-response met een 2xx-status doorzoekt TrueURL de eerste 256 KB van de pagina op een meta-refresh-tag en op eenvoudige, onvoorwaardelijke JavaScript-redirects. Ook een Refresh-header in HTTP, die werkt als een meta refresh, wordt gedetecteerd. Vindt TrueURL er een, dan toont het de tag of het stukje script, de volledige doel-URL en de vertraging, labelt het de hop als meta refresh of JavaScript en zet het de keten voort vanaf het doel. Een refresh die alleen dezelfde pagina opnieuw laadt, is geen redirect en wordt genegeerd.

Onder Geavanceerde instellingen kun je het volgen van elk van beide typen uitzetten om naar de pagina zelf te kijken. TrueURL voert geen JavaScript uit: het leest de scripts in de pagina en herkent redirects naar een vaste URL die altijd worden uitgevoerd als de pagina laadt, direct of in een setTimeout op het hoogste niveau. Redirects die van een voorwaarde afhangen, zoals een klik, een keuze voor toestemming of de schermgrootte, of die de doel-URL in code opbouwen, worden niet gedetecteerd. Gebruik GET in plaats van HEAD, want een antwoord op HEAD heeft geen body om te doorzoeken.

Hoe zoekmachines met client-side redirects omgaan

  • Directe meta refresh (vertraging 0): Google behandelt die als een permanente redirect, net als een 301.
  • Vertraagde meta refresh: wordt behandeld als een tijdelijke redirect, dus de oorspronkelijke URL blijft meestal geïndexeerd.
  • JavaScript-redirects: Google ziet ze pas na het renderen van de pagina, en dat kan ruim na het crawlen gebeuren. Veel andere crawlers en de meeste linkpreviewbots voeren helemaal geen JavaScript uit.

Google raadt server-side redirects aan waar je die kunt instellen, met meta refresh als terugvaloptie, bijvoorbeeld bij statische hosting die geen 301 kan sturen.

Toegankelijkheid en gebruikerservaring

Getimede redirects zijn een toegankelijkheidsprobleem: mensen die een schermlezer gebruiken of gewoon langzaam lezen, raken de draad kwijt als de pagina onverwacht verandert. WCAG noemt een getimede meta refresh een fout (F40), terwijl een directe redirect met een vertraging van 0 een geaccepteerde techniek is (H76).

Moet je in HTML doorsturen, gebruik dan een vertraging van 0, voeg een canonical tag toe die naar de nieuwe URL verwijst en zet op de pagina een zichtbare link ernaartoe voor bezoekers van wie de browser de refresh niet volgt.

Gidsen

Veelgestelde vragen

Geeft een meta refresh SEO-waarde door zoals een 301?

Google behandelt een directe meta refresh (vertraging 0) als een permanente redirect, dus in de praktijk werkt die grotendeels als een 301. Een vertraagde refresh telt als tijdelijk. Andere crawlers gaan mogelijk minder betrouwbaar om met meta refresh, dus gebruik een server-side 301 zodra je hosting dat toelaat.

Waarom toont mijn redirectchecker 200 terwijl de pagina in mijn browser doorstuurt?

De redirect gebeurt in de HTML of JavaScript van de pagina, niet in de HTTP-response. Tools die alleen statuscodes volgen, zoals curl -L, stoppen bij de pagina met 200. TrueURL doorzoekt de inhoud van de pagina en toont de client-side redirect als aparte hop.

Welke vertraging hoort een meta refresh te hebben?

0, als het doel is om door te sturen. Elke vertraging maakt er voor Google een tijdelijke redirect van, laat bezoekers wachten en veroorzaakt toegankelijkheidsproblemen. Een vertraging heeft alleen zin op een pagina die eerst een bericht moet tonen, en die pagina hoort ook een duidelijke link te hebben om verder te gaan.

Kan TrueURL elke JavaScript-redirect detecteren?

Nee, alleen eenvoudige, onvoorwaardelijke redirects met een vaste doel-URL in de HTML van de pagina, zoals location.href = '...', window.location = '...' of location.replace('...'), ook binnen een setTimeout op het hoogste niveau. Redirects in externe scriptbestanden, achter voorwaarden, na een actie van de gebruiker of met een berekende URL kunnen alleen in een echte browser worden uitgevoerd. Stopt de keten op een pagina waarvan je weet dat die doorstuurt, dan is dat waarschijnlijk de reden.

Waarom zou een site een meta refresh gebruiken in plaats van een 301?

Meestal omdat de site geen HTTP-redirects kan sturen: statische hosting zonder redirectregels, een pagebuilder of een oud CMS. Sommige linkverkorters en kliktrackers gebruiken ook HTML-redirects, zodat ze eerst analyticsscripts kunnen uitvoeren of kunnen bepalen welke referrer de bestemming ziet.

Detecteert een HEAD-verzoek een meta refresh?

Nee. Een antwoord op HEAD heeft headers maar geen body, dus er is geen HTML om te doorzoeken. TrueURL waarschuwt je als je met HEAD controleert; gebruik voor deze tool GET.