Verkeerscontrole: hoe je ervoor zorgt dat links naar het juiste domein leiden

Wat telt als een overgang naar het juiste domein

Verkeer komt op het juiste domein terecht wanneer de gebruiker na alle doorverwijzingen een pagina opent op de bedoelde host. Het is niet genoeg om het adres te controleren dat in de streambeschrijving, het profiel of de advertentie is geplaatst: de link kan via een linkverkorter, tracker, oud domein, tussenliggende landingspagina of georedirect gaan.

Controleer niet alleen de domeinnaam, maar ook de variant ervan: www en zonder www, HTTP en HTTPS, het hoofddomein en het subdomein. De adressen site.example, www.site.example en promo.site.example kunnen bij hetzelfde project horen, maar voor de browser, analytics en logs zijn het verschillende hosts.

Open de link zoals het publiek dat doet

Ga naar de link vanaf de echte plaats van plaatsing: vanuit de streamomschrijving, het profiel, het vastgezette bericht, de post of de advertentie. Controleer na het laden van de pagina de adresbalk. De URL die in de browser overblijft is belangrijk, niet het oorspronkelijke adres uit de publicatie.

• Vergelijk de eindhost met het domein van de landingspagina.
• Controleer het pad: de link kan naar het juiste domein leiden, maar naar een verouderd gedeelte.
• Zorg ervoor dat een mobiele overgang niet naar een technisch subdomein gaat.
• Vergelijk het resultaat voor de link met en zonder UTM-tags.
• Controleer of de campagneparameters na alle overgangen behouden zijn gebleven.

Het nadeel van handmatige controle: het toont één scenario — jouw browser, apparaat, regio en set cookies. Voor een deel van het publiek kunnen de regels anders werken.

Controleer de hele redirectketen in de browser en via curl

Gebruik voor een technische controle curl met de parameters -I en -L: de opdracht toont de responsheaders en volgt de doorverwijzingen. Let op de statussen 301, 302, 307, 308 en de Location-headers. Ze tonen naar welk adres de server de gebruiker bij elke stap stuurt.

Open voor een controle in een echte browser de ontwikkelaarstools, ga naar het tabblad Network en schakel Preserve log in. Open vervolgens de oorspronkelijke link. In de lijst met verzoeken zijn de redirects, het einddocument en de verzoeken die al na het laden van de pagina worden uitgevoerd zichtbaar.

1. Schakel Preserve log in zodat de lijst niet wordt gewist na een doorverwijzing.
2. Schakel indien nodig de browsercache uit.
3. Open de oorspronkelijke link uit de publicatie of plak deze in een nieuw tabblad.
4. Zoek de responses met status 3xx.
5. Vergelijk de Request URL van elke stap met de waarde van Location.
6. Controleer het domein en de URL van het laatste document met status 200.

Wanneer een oud domein in de keten normaal is en wanneer het een fout is

Een oud domein in de keten betekent niet altijd een probleem. Na een verhuizing is een route zoals old-site.example/stream → site.example/stream normaal: het oude adres accepteert het verzoek en verwijst de gebruiker permanent door naar de equivalente pagina van de nieuwe site. Het einddomein is correct, het pad is behouden en de UTM-tags zijn niet verdwenen.

Een bug is de situatie waarin old-site.example/stream naar de homepage van de nieuwe site leidt, naar een andere landingspagina, of de gebruiker op het oude domein laat. Een apart probleem ontstaat wanneer na de redirect de tekenreeks na het vraagteken verdwijnt: de gebruiker komt op de juiste pagina, maar analytics verliest utm_source, utm_medium en utm_campaign.

Controleer niet alleen het laatste domein, maar ook het pad met de parameters. Een overgang naar site.example zonder de juiste pagina of tags kan de campagnegegevens net zo sterk vertekenen als een overgang naar een andere host.

Houd rekening met JavaScript-redirects en linkparameters

curl is handig voor serverresponses, maar ziet niet altijd de doorverwijzingen die door een script na het laden van de pagina worden gestart. DevTools in de browser helpt zo'n scenario op te merken: eerst wordt een tussenpagina geopend, daarna wijzigt het script het adres of stuurt het de gebruiker naar een ander domein.

Controleer in Network niet alleen het hoofddocument, maar ook het moment waarop het adres na het laden ervan verandert. Als de UTM-tags verdwenen zijn, vergelijk dan de oorspronkelijke URL, de waarde van Location en de uiteindelijke regel in de adresbalk. Zo kun je begrijpen bij welke stap de redirectregel de parameters heeft weggegooid.

Het nadeel van het doorgeven van alle parameters zonder controle: er kunnen overbodige technische waarden op het doeldomein terechtkomen. Voor belangrijke links is het de moeite waard om vooraf te bepalen welke tags, promocodes en partnerparameters behouden moeten blijven.

Controleer in-app browsers van applicaties

Sociale netwerken, messengers en streamingplatforms openen een link vaak niet in de hoofd-browser van het apparaat, maar in een ingebouwde browser. Zo'n browser kan een andere user-agent doorgeven, scripts beperken, geen cookies opslaan of redirects anders verwerken.

Open de link rechtstreeks vanuit de app van het platform waar deze is geplaatst. Herhaal de test vervolgens via de optie 'Openen in browser', als die beschikbaar is. Vergelijk het einddomein, het pad, de UTM-tags en het gedrag van het formulier, de betaling of de autorisatie.

Het nadeel van controle in een ingebouwde browser: niet alle apps laten je de technische verzoekketen bekijken. Die is toch belangrijk, omdat het mobiele publiek vaak juist zo overgaat.

Vergelijk overgangen uit verschillende regio's en omstandigheden

Als de site georedirects, een CDN of verschillende versies van landingspagina's gebruikt, herhaal de controle dan via een VPN, proxy of extern apparaat in de gewenste regio. Vergelijk het einddomein, het pad, de URL-parameters en de inhoud van de landingspagina.

Controleer niet alleen het land, maar ook de browsertaal, autorisatie, cookies en het apparaattype. Deze omstandigheden kunnen de route beïnvloeden: bijvoorbeeld een gebruiker uit de ene regio wordt naar een lokaal subdomein gestuurd, en een bezoeker zonder cookies naar een algemene landingspagina.

Het nadeel van VPN en proxy: ze reproduceren niet altijd volledig de omstandigheden van een echte kijker. Geolocatie kan op basis van meerdere signalen worden bepaald, dus zo'n test bevestigt een mogelijk probleem, maar dekt niet het hele publiek.

Bevestig het domein in Yandex Metrica en GA4

Bekijk in Yandex Metrica de rapporten over toegangspagina's en pagina-URL's. Filter de gegevens op het volledige adres of het gewenste domein en voeg vervolgens een segment toe op UTM-tag, bron of campagne. Zo kun je zien op welke host de bezoeken na een specifieke plaatsing zijn begonnen.

Gebruik in GA4 voor zo'n controle de dimensie Hostname samen met de landingspagina, de sessiebron en de campagne. Vergelijk hoeveel sessies op het hoofddomein, het oude adres en belangrijke subdomeinen zijn aangekomen. Als de tag op meerdere hosts is geïnstalleerd, laat het rapport snel de vermenging van verkeer zien.

Het nadeel van analytics: tellers registreren een deel van de bezoeken niet vanwege adblockers, uitgeschakelde JavaScript of het sluiten van de pagina voordat de tag is geladen. Ook helpen de gegevens niet voor een domein waar de teller helemaal niet is geïnstalleerd.

Controleer aanvragen in de serverlogs

Serverlogs bevestigen welke verzoeken daadwerkelijk de infrastructuur van de site hebben bereikt. Voor de controle zijn velden nodig met tijd, Host, URL, responscode, user-agent en referer, als die wordt doorgegeven. Zoek naar aanvragen in de periode van de linklancering en bekijk afzonderlijk de verzoeken naar het oude en het doeldomein.

Responses 301, 302, 307 en 308 tonen dat de server de gebruiker heeft doorgestuurd. Verzoeken met status 200 naar de doelhost bevestigen dat de pagina vanaf het juiste domein is geleverd. Als er in de logs overgangen naar de oude host staan, maar geen verzoeken naar de nieuwe, controleer dan de redirectregels en mogelijke verbindingsfouten.

Het nadeel van logs: er komen bots, scanners en technische verzoeken in terecht. Referer ontbreekt vaak bij overgangen vanuit apps en messengers, dus de bron van een specifiek bezoek is niet altijd te achterhalen.

Scheid het hoofddomein en subdomeinen in rapporten

De landingspagina, het klantportaal, de betaling en de kennisbank kunnen op verschillende subdomeinen staan. Als je ze in één rapport zonder segmenten verzamelt, kun je over het hoofd zien dat een link uit de stream naar promo.site.example leidt in plaats van naar de hoofdsite, of naar checkout.site.example voordat men kennis heeft gemaakt met het aanbod.

Maak een apart segment voor de doelhost en laat een algemeen rapport over alle domeinen van het project staan. Het eerste helpt het landingsverkeer te beheren, het tweede om het pad van de gebruiker tussen landingspagina, betaling en klantportaal te zien.

Het nadeel van te strikte filtering: een normale overgang tussen subdomeinen kan uit het rapport verdwijnen, waardoor de funnel afgebroken lijkt.

Checklist voor het controleren van een link vóór plaatsing

• Open de link vanaf de plaats waar het publiek deze zal zien.
• Controleer het einddomein, het pad en de parameters in de adresbalk.
• Bekijk de 3xx-keten en de Location-headers via curl of Network.
• Zorg ervoor dat het oude domein bij de redirect het pad en de UTM-tags behoudt.
• Herhaal de overgang in de ingebouwde browser van de app.
• Controleer een andere regio als er georegels worden gebruikt.
• Vergelijk Hostname en landingspagina's in analytics na de lancering.
• Bevestig aanvragen naar de juiste host via de serverlogs.

Controleer na een wijziging van domein, CDN, landingspagina of redirectregels zowel de nieuwe als de oude links. Oude streambeschrijvingen, video's en vastgezette posts kunnen het publiek blijven leiden naar een verouderde route.