Wie is eigenaar van je website? Lock-in en toegang tot code, domein en hosting

Wie is eigenaar van je website? In principe jij, als opdrachtgever die ervoor betaalt.

In de praktijk hangt dat volledig af van wat er contractueel is vastgelegd, en op wiens naam de accounts staan.

Het verdict: je bent pas echt eigenaar als domein, code, content, hosting en accounts op naam van je eigen bedrijf staan. Leg dat vast vóór de eerste factuur.

Een website is namelijk geen enkel bezit. Het is een verzameling losse onderdelen, en die kunnen elk bij een andere partij terechtkomen.

Hieronder zie je welke onderdelen er zijn, waar lock-in ontstaat en wat je vastlegt om vrij te blijven. Vrij om te verhuizen, te vernieuwen of van leverancier te wisselen.

Waarom dit geen wantrouwen is

Dit is bewust een nuchter, praktisch verhaal.

De meeste bureaus hebben geen kwade bedoelingen.

Maar eigendom dat niemand expliciet regelt, belandt vaak per ongeluk op de verkeerde naam. En dat merk je pas op het slechtst mogelijke moment: wanneer je weg wil.

Wil je het bredere plaatje rond een professionele build? Lees dan onze gids om een B2B-website te laten maken; eigenaarschap is daar een vast onderdeel van.

Wat betekent “eigenaar van je website” eigenlijk?

Dat jij, zonder toestemming van een derde partij, bij elk onderdeel kunt dat de site laat draaien.

Dat omvat aanpassen en verhuizen. Het is dus geen vraag met één antwoord.

De vijf lagen van je website

Een website bestaat uit minstens vijf afzonderlijke lagen, en eigendom bekijk je per laag:

• De domeinnaam: het adres waarop je gevonden wordt, plus de DNS-instellingen.
• De broncode en designbestanden: HTML, CSS, maatwerkcode of het platformproject.
• De content en CMS-structuur: teksten, beelden en de opbouw van pagina’s.
• De hosting: de servers of het platform-abonnement waarop de site live staat.
• De gekoppelde accounts: analytics, Search Console, e-mail, formulieren, licenties.

Wat DNS precies doet, lees je in wat DNS is.

Per laag: wat zet je op je eigen naam?

Dit overzicht toont per laag wat je bezit, en wat er misgaat als je het niet regelt:

Waarom die lagen los van elkaar staan

Het venijn zit erin dat deze lagen los van elkaar staan.

Je kunt bijvoorbeeld de broncode bezitten, maar geen toegang hebben tot de hosting.

Of je hebt het domein op jouw naam, terwijl de CMS-content in een account zit waar enkel het bureau bij kan.

Vuistregel: echt eigenaarschap betekent dat je alle vijf controleert, of er op zijn minst onbelemmerd bij kunt.

Welk onderdeel is het belangrijkst om vast te leggen?

De domeinnaam. Daar doet lock-in het hardst pijn, en daar is ze het makkelijkst te vermijden.

De registrant is de eigenaar

Een domein heeft een geregistreerde houder, de registrant.

Die houder is juridisch de eigenaar, niet wie het beheert.

Registreert je bureau het domein “even voor jou” op zijn eigen naam of in zijn eigen registraraccount? Dan zit je daar vast.

Bij een verhuizing heb je hun medewerking nodig voor de transfercode.

Zonder die medewerking sta je nergens.

De regel voor je domein

De regel is simpel: het domein staat op naam van je bedrijf, in een registraraccount waarvan jouw bedrijf de inloggegevens heeft.

Laat je het beheren door je bureau? Prima.

Maar als geregistreerde houder en accounteigenaar staat jouw organisatie.

Een nieuw domein kiezen of registreren? Lees eerst een domeinnaam kiezen voor je bedrijf.

Hetzelfde principe voor je meetdata

Datzelfde principe geldt voor je belangrijkste meetdata.

Zet Google Analytics en Search Console op een account van je bedrijf.

Geef het bureau toegang als gebruiker, niet omgekeerd.

In Search Console kan volgens Google alleen een geverifieerde eigenaar gebruikers toevoegen of verwijderen.

Je controleert dat in de instellingen van je property:

Verhuist het werk, dan verlies je je historiek niet. Dat maakt het verschil bij een latere website-migratie zonder rankingverlies.

Voor advertentie-accounts geldt dezelfde logica: zie wie eigenaar is van je Google Ads-account.

Waar zit de lock-in per platform?

In de toegang, niet in het platform zelf.

Lock-in is geen eigenschap van een slecht platform, maar van slecht geregelde toegang.

Toch verschilt de vorm per type build.

Het is eerlijk om die verschillen te benoemen zonder één keuze als winnaar aan te wijzen.

Een open CMS zoals WordPress

Bij een open CMS zoals WordPress heb je in theorie alles in handen: jouw codebase, jouw database, jouw bestanden.

Die draaien op hosting die je zelf kiest. De software zelf valt onder een open licentie: WordPress verschijnt onder de GPLv2 (of later).

WordPress.org, oktober 2026. De software is gratis, de keuze van host en plug-ins ligt bij jou.

De lock-in zit daar niet in het platform, maar in de accounts eromheen. Drie vragen beslissen:

• Wie heeft de admin-login?
• Op wiens hostingaccount staat het?
• Wie bezit de licenties van betaalde plugins en het thema?

Zonder die zaken bezit je een site die je niet kunt verplaatsen. Waar je op let bij een host, staat in een websitehosting kiezen.

Een visueel platform zoals Webflow

Bij een visueel platform zoals Webflow krijg je gebruiksgemak en gehoste infrastructuur.

Maar het eigendom is anders verdeeld.

De homepage van Webflow, oktober 2026. Ook hier hangt de vrijheid af van wie de workspace bezit.

Je kunt de front-end code exporteren, op de daarvoor bedoelde abonnementen.

Maar die export bevat niet de CMS-inhoud, de formulieren of de hostingfunctionaliteit; die blijven aan het platform gebonden.

De praktische vraag: staat het project in een workspace op naam van je bedrijf? Dan draag je het beheer over zonder de hele site opnieuw te bouwen.

Meer over de grenzen van het platform lees je in de nadelen en beperkingen van Webflow.

Maatwerk of headless

Bij maatwerk of headless heb je doorgaans de meeste controle over de code.

Maar je bent afhankelijk van goede documentatie en toegang tot de repository en de losse diensten.

Zonder de Git-repository, de omgevingsvariabelen en een leesbare overdracht is dure maatwerkcode alsnog een black box.

Overweeg je om losse lagen te ontkoppelen? Onze uitleg over hoe een headless CMS werkt toont waar eigendom en afhankelijkheid precies liggen.

De drie builds naast elkaar

Kies op toegang, niet op technologie

De conclusie is dus niet “kies platform X om lock-in te vermijden”.

Bij elk platform bepaalt jouw toegang, niet de technologie, of je vrij bent. Wil je de twee populairste opties vergelijken, lees dan Webflow vs WordPress.

Welke optie het best past, hangt af van je team, je groeiplannen en hoe vaak je zelf wilt aanpassen.

Dat is ook hoe wij platform-onafhankelijk naar website ontwikkeling kijken: het juiste gereedschap voor jouw specifieke geval.

Wat moet er contractueel in staan?

Eigendom en toegang, schriftelijk vastgelegd vóór de eerste factuur.

Achteraf onderhandelen over iets dat je al betaald hebt, staat zwak.

Vijf punten voor je contract

Een goede afspraak hoeft niet lang te zijn, maar dekt deze punten:

1. Eigendom van het opgeleverde werk. Broncode, designbestanden en content worden na betaling jouw eigendom, niet enkel “in licentie”.
2. Accounts op jouw naam. Domein, hosting, CMS, analytics en betaalde tools staan op accounts van je bedrijf. Het bureau werkt als gebruiker.
3. Een exit-clausule. Wat krijg je mee bij het einde, in welke vorm en binnen welke termijn?
4. Documentatie en overdracht. Waar staat wat, hoe deploy je, welke diensten zijn gekoppeld?
5. Geen gijzeling bij betwisting. Je behoudt toegang tot je live site en je data, ook tijdens een factuurdiscussie.

Wat een exit-pakket bevat

Denk bij die exit-clausule aan vier concrete leveringen:

• een export van de content
• de volledige codebase
• een databasedump
• een lijst van alle accounts en licenties

Hoe je die afspraken in een volledig contract giet, staat in de checklist voor je website-contract en SLA.

Waarom een goed bureau hier geen probleem mee heeft

Een bureau dat met je meedenkt, heeft hier geen probleem mee.

Heldere afspraken over eigendom zijn net een teken van vertrouwen.

Onze ervaring: bij ons is de klant eigenaar van alles: content, links en accounts.

Regel ook het interne eigendom

Regel naast het externe eigendom ook intern wie de site beheert. Goede website governance legt vast wie binnen je eigen bedrijf eigenaar is van de site.

Het is dezelfde logica die bepaalt of bezoekers je geloven: zie vertrouwen wekken op je B2B-website.

Hoe haal je je eigendom terug als het misging?

Met een rustige inventaris, niet met een conflict.

Stap 1: inventariseer de vijf lagen

Maak een lijst van de vijf lagen.

Zoek per laag uit op wiens naam en in welke account het staat.

Vaak valt het mee. Dan is het een kwestie van toegang laten overdragen, of jezelf als eigenaar laten toevoegen.

Stap 2: verhuis het domein

Voor het domein vraag je de transfercode aan, de auth-code of EPP-code.

Bij .be-domeinen stuurt DNS Belgium die naar het e-mailadres van de geregistreerde houder.

Let op: de code is volgens DNS Belgium 7 dagen geldig. Is de code juist, dan kan je domeinnaam binnen enkele uren verhuisd zijn.

Daarna staat het bij een registrar op naam van je bedrijf. Hoe je verhuist zonder dat je site offline gaat, lees je in een domein verhuizen zonder downtime.

Stap 3: claim je meetdata

Voor analytics laat je jezelf als beheerder toevoegen, en in Search Console als eigenaar. Doe dat zolang je nog medewerking krijgt.

Want alleen eigenaars kunnen in Search Console gebruikers toevoegen of verwijderen.

Stap 4: red je content

Zelfs als je de oude site niet kunt exporteren, kun je de teksten en beelden meestal nog ophalen. Daarmee bouw je elders opnieuw op.

Tip: bewaar die export apart. Een goede backupstrategie voor je website voorkomt dat je ooit van één partij afhangt.

Stap 5: plan de nieuwe build goed

Wordt een verhuizing onvermijdelijk een nieuwe build? Plan die dan meteen goed, zodat je je posities niet kwijtspeelt.

Een doordacht website-redesignproces houdt rekening met precies die continuïteit. De volledige overstap staat in je website overdragen naar een ander bureau.

Bescherm eerst domein en meetdata

Het kostbaarste dat je kunt verliezen, is niet de code, want die kan opnieuw gebouwd worden.

Het zijn je domein en je opgebouwde meetdata. Bescherm die twee eerst, de rest volgt.

Veelgestelde vragen

Wie is eigenaar van mijn website als het bureau ze gebouwd heeft?

In principe jij als opdrachtgever, maar enkel voor wat contractueel is vastgelegd en op jouw naam staat. Staat het domein of de hosting op naam van het bureau, dan heb je hun medewerking nodig om te verhuizen. Leg eigendom van code, design en content daarom schriftelijk vast.

Hoe zie ik op wiens naam mijn .be-domein staat?

Je registrar toont de geregistreerde houder in je account. Bij een verhuizing stuurt DNS Belgium de transfercode naar het e-mailadres van die houder. Krijg jij die mail niet, dan staat het domein waarschijnlijk niet op jouw naam.

Mag mijn bureau mijn Search Console beheren?

Ja, als gebruiker. Jouw bedrijf hoort de geverifieerde eigenaar te zijn, want alleen een eigenaar kan gebruikers toevoegen of verwijderen.

De korte samenvatting

Eigenaar zijn van je website betekent dat jij onbelemmerd bij vijf onderdelen kunt: domein, broncode en designbestanden, CMS-content, hosting en alle gekoppelde accounts.

Lock-in ontstaat zelden uit kwade wil, maar uit toegang die per ongeluk op naam van het bureau staat.

Zet je domein en je analytics eerst op accounts van je eigen bedrijf. Leg eigendom en een exit-clausule vast vóór de start, en zorg voor een nette overdracht.

Wil je zeker weten dat je site volledig van jou is? Neem contact op en we lopen je eigendom en je opties samen door.