www, apex en wildcard forwarding zonder SEO-schade
Hostnormalisatie lijkt simpel totdat root, www, subdomeinen, paden en query strings elk een eigen regel krijgen. Een duidelijke policy houdt de canonieke URL stabiel.
Hostnormalisatie klinkt als een klein DNS-klusje. In een echte migratie wordt het al snel een URL policy.
De directie gebruikt de apex. Het oude systeem gebruikt www. Een product, blog of docs draait op een subdomein. De agency heeft wildcard forwarding in de migratielijst staan. Een campagne moet nog steeds UTM behouden. Als die keuzes pas op launchmoment samenkomen, krijg je vaak een redirect chain.
De vraag is niet of www of apex altijd beter is. De vraag is: welke host is canoniek, en hoe volgen de andere varianten die host?
Als de hostwissel deel is van een grotere migratie, begin dan met de checklist voor website-migratie redirects. Dit artikel gaat alleen over de hostlaag.
De host hoort bij de URL-policy
example.nl, www.example.nl en *.example.nl zijn operationeel niet hetzelfde.
- De apex oogt vaak strakker in marketing.
wwwpast bij oudere stacks.- Een subdomein kan een product, docs of support zijn.
- Wildcards helpen wanneer veel hosts dezelfde regel moeten volgen.
Belangrijk is dat die varianten niet per ongeluk gaan lopen.
Kies de canonieke host vóór de launch
Beantwoord vroeg:
| Vraag | Waarom het telt |
|---|---|
Draait de site op apex of www? | Bepaalt de zichtbare canonieke URL |
| Welke subdomeinen zijn aliases? | Niet elk subdomein mag mee worden samengevoegd |
| Moeten paden behouden blijven? | SEO, bookmarks en deep links hangen daarvan af |
| Moeten query strings blijven? | UTM, coupons en IDs kunnen anders verdwijnen |
| Zijn er tijdelijke uitzonderingen? | Campagnes en launches kunnen andere logica vragen |
Als dit open blijft, gaan meerdere lagen tegelijk proberen te helpen.
DNS lost niet alles op
DNS zegt waar verkeer heen gaat. Het bepaalt niet automatisch de zichtbare URL-wissel.
Schone flow:
http://www.oude-merk.example/prijzen?utm_source=email
-> https://nieuwe-merk.example/prijzen?utm_source=emailFragiele flow:
http://www.oude-merk.example/prijzen
-> https://www.oude-merk.example/prijzen
-> https://oude-merk.example/prijzen
-> https://nieuwe-merk.example/prijzenEen enkele hop is makkelijker te testen en onderhouden.
Wildcard forwarding werkt als de structuur gelijk blijft
Een wildcardregel helpt wanneer paths goed op elkaar aansluiten:
old.example.nl/* -> new.example.nl/$1Dat werkt goed als:
- er veel oude URLs behouden moeten blijven
- de structuur weinig verandert
- je niet per pagina een regel wilt schrijven
- oude subdomeinen echte aliases zijn
Als de architectuur veel verandert, moeten belangrijke URLs expliciet gemapt worden.
Houd path en query vast wanneer de link nog telt
Hostnormalisatie mag niet de context wissen.
http://old.example.nl/docs/api?ref=partner&utm_source=newsletterzou, als de structuur het toelaat, moeten eindigen in:
https://new.example.nl/docs/api?ref=partner&utm_source=newsletterDat is belangrijk voor:
- SEO pages
- documentatie
- paid campaigns
- affiliate links
- opgeslagen gebruikerslinks
Als path of query verdwijnt, lijkt de redirect technisch goed maar verliest hij alsnog waarde.
Vermijd chains
De klassieke fout is verantwoordelijkheden opsplitsen:
- HTTP naar HTTPS ergens anders
wwwnaar apex op een andere laag- domeinwissel in CDN of hosting
- de app voegt nog een canonical rule toe
Het resultaat wordt http -> https -> www -> final.
Als je stack er zo uitziet, kijk dan naar Redirect chains and loops.
Test een launch matrix
Test vóór livegang echte varianten:
| Test | Voorbeeld |
|---|---|
| Apex root | https://example.nl/ |
www root | https://www.example.nl/ |
| Deep path | https://example.nl/prijzen |
| Deep path met query | https://example.nl/prijzen?utm_source=email |
| Oude host met path | https://old.example.nl/blog/post-1 |
| Wildcard subdomein | https://docs.example.nl/guide |
Controleer:
- juiste canonieke host
- path blijft intact
- query blijft intact
- status code past bij de intentie
- geen extra hop ertussen
Waar UrlEdge past
UrlEdge helpt als hostnormalisatie als routing policy moet worden beheerd, niet als los snippetje.
- Free Redirect Service voor automatisch HTTPS en wildcard forwarding
- Advanced Redirect Rules voor conditionele logica
- Redirect Checker om echte hops te bekijken
- Redirect domain zonder path en query te verliezen voor het volledige patroon
Het voordeel is één plek die eigenaar is van canonieke host, varianten, paths, queries en status codes.
FAQ
Moet ik altijd apex boven www kiezen?
Nee. Beide kunnen werken. Het belangrijkste is één canonieke host kiezen en de rest netjes laten volgen.
Kan ik wildcard subdomeinen met één regel afhandelen?
Ja, als de structuur gelijk blijft. Als die sterk verandert, map dan belangrijke URLs expliciet.
Is DNS genoeg?
Nee. DNS vervangt geen HTTP redirect policy die voor de gebruiker zichtbaar is.
Moet ik campagneparameters behouden?
Meestal wel, tenzij je daar een expliciete reden voor hebt. Verloren attributie is moeilijk terug te halen.
Referenties
Leg de canonieke host één keer vast
Redirect root, www en wildcard subdomeinen met automatisch HTTPS, behoud van pad en een canonieke bestemming.
Probeer Free Redirect ServiceGerelateerde artikelen
Alles bekijken
Link firewall voor paid en affiliate verkeer: bot, proxy en slechte clicks filteren
Niet elke slechte click is fraude, maar elke slechte click kan budget, attributie en partnerreports verstoren. Een link firewall bepaalt wat er gebeurt voordat verkeer de bestemming bereikt.
Verificatiebestanden aan de edge serven: ads.txt, security.txt, AASA en assetlinks.json
Sommige bestanden moeten in de root of onder /.well-known/ staan. Als CMS of shopplatform dat lastig maakt, kan een edge response ze direct met de juiste status en Content-Type serveren.