De vraag “ben ik eigenaar van mijn website” lijkt simpel, maar het antwoord is bijna nooit ja of nee. Eigenaarschap valt namelijk uiteen in vier losse lagen: je domein, je hosting, je broncode en je content. Je kunt prima de ene laag bezitten en de andere niet, en precies daar ontstaat het probleem. Wie bij een goedkope bouwer of een builder als Wix start, ontdekt vaak pas bij het overstappen dat de site technisch niet van hem is. In deze cluster bij onze gids over een maatwerk website laten maken leggen we per laag uit wat je bezit, waar de lock-in zit, en welke vier dingen je vooraf opeist zodat je nooit vastzit.
Wat betekent website eigenaarschap eigenlijk?
Website eigenaarschap is niet één ding dat je wel of niet hebt. Het zijn vier lagen die je los van elkaar kunt bezitten of huren:
- Domein: de naam, bijvoorbeeld jouwbedrijf.nl. Dit is een jaarlijkse registratie bij een registrar, geen koop. Je bezit het zolang je verlengt.
- Hosting: de server waar de site draait. Bijna altijd een huur-relatie, en dat is prima zolang je er zo van weg kunt.
- Broncode: de daadwerkelijke bestanden waaruit de site bestaat. Dit is de laag waar eigendom het meeste uitmaakt en het vaakst misgaat.
- Content: je teksten, afbeeldingen, blogartikelen, productdata. Juridisch vaak van jou, maar praktisch waardeloos als je het niet kunt exporteren.
Het kantelpunt zit bijna altijd in de broncode. Bij een maatwerk website krijg je die code in eigendom en kun je morgen van leverancier wisselen. Bij een gesloten builder huur je effectief alle vier de lagen tegelijk, verpakt als één abonnement. Het verschil merk je niet op dag één, maar wel op de dag dat je weg wilt.
Ben ik eigenaar als ik een bureau betaal om mijn site te bouwen?
Dit is de duurste misvatting in de markt: betalen voor het bouwen geeft je niet automatisch de code in eigendom. In het Nederlandse auteursrecht ligt het auteursrecht op software standaard bij de maker, niet bij de opdrachtgever, tenzij het schriftelijk wordt overgedragen. Veel bureaus weten dit en houden de broncode op hun eigen GitHub-account. Je krijgt toegang tot de live site, een inlog op het CMS, maar niet de onderliggende bestanden.
Het effect: zolang alles goed gaat merk je niets. Wil je over twee jaar weg, een functie laten bouwen door iemand anders, of het bureau valt om, dan sta je met lege handen. Je hebt een werkende website die je niet kunt verplaatsen, want je hebt nooit de bouwstenen gekregen.
Vraag daarom voor de start expliciet om code-eigendom, contractueel vastgelegd. Bij TopDevs staat dat standaard in onze algemene voorwaarden en is het geen onderhandelpunt. Voor de juridische diepte rondom dit thema schreven we een aparte uitleg over code-eigendom en vendor lock-in.
Wie is eigenaar van mijn website bij Wix of Squarespace?
Bij een builder als Wix of Squarespace is de scheiding hard. Je bent eigenaar van je content en, als je het zelf registreerde, van je domein. De code en het platform blijven van de builder. Dat is geen verborgen clausule, het is hun businessmodel: je huurt het hele bouwwerk per maand.
Het pijnpunt zit in de export. Squarespace biedt een XML-export die teksten en wat structuur meeneemt naar WordPress, maar geen design, geen functionaliteit, geen exacte opmaak. Wix biedt nog minder: er is geen export van je site als werkende website, alleen losse content die je handmatig moet overzetten. In de praktijk betekent overstappen vanaf een builder dus: opnieuw bouwen, niet verhuizen.
| Wat je bezit | Wix | Squarespace | Maatwerk (Git in jouw account) |
|---|---|---|---|
| Domein | Ja, als je het zelf registreerde | Ja, als je het zelf registreerde | Ja, eigen registrar-account |
| Content (tekst, beeld) | Ja, juridisch | Ja, juridisch | Ja |
| Content-export naar elders | Beperkt, handmatig overzetten | XML-export, geen design | Volledig, in open formaten |
| Broncode | Nee | Nee | Ja, eigendom |
| Overstappen zonder herbouw | Nee | Nee | Ja |
Wat is vendor lock-in en hoe ontstaat het bij websites?
Vendor lock-in betekent dat overstappen naar een andere partij zo duur of technisch ingewikkeld wordt dat je in de praktijk vastzit. Bij websites stapelt die lock-in zich op uit drie veelgemaakte keuzes:
- De broncode staat niet op jouw account. Het bureau bezit de repository. Vertrek je, dan vertrekt de code mee.
- Het domein staat op het account van het bureau. Dit is verraderlijk: het domein is van jou, maar als het in het registrar-account van de bouwer staat, heb je hun medewerking nodig om het te verhuizen. Sommige partijen rekenen daar kosten voor of laten je weken wachten.
- De content leeft alleen in een gesloten editor. Geen export, geen database-toegang, geen markdown. Je kunt er niets mee buiten dat ene platform.
Hoe meer van deze lagen je zelf bezit, hoe lichter de lock-in. Het verschil tussen platforms is hierin groot. Een open systeem als WordPress geeft je je database en bestanden; een headless opzet geeft je content in schone, herbruikbare formaten. We zetten die opties tegen elkaar in WordPress vs maatwerk vs headless. Volgens de HTTP Archive Web Almanac draait een groot deel van het web op WordPress, juist omdat je daar in principe je eigen data en code houdt.
Wat moet je precies in eigendom hebben? De checklist
Eigenaarschap is geen gevoel, het is een lijstje dat je kunt afvinken. Dit zijn de zaken die je vooraf opeist en bij oplevering controleert. Niet “zou fijn zijn”, maar de minimumstandaard.
| Wat je opeist | Waarom het telt | Hoe je het controleert |
|---|---|---|
| Git-repository op jouw account | Bewijs van code-eigendom, basis voor migratie | Log in op GitHub of GitLab, zie je de repo als eigenaar? |
| Domein in jouw registrar-account | Je kunt verhuizen zonder toestemming van het bureau | Inloggen bij de registrar op jouw eigen naam |
| Volledige content-export | Teksten en beeld zijn herbruikbaar buiten het platform | Vraag een export-bestand op en open het |
| Hosting onder jouw beheer of overdraagbaar | Geen gijzeling van de live site | Toegang tot het hostingpaneel of overdraagbaar contract |
| Alle credentials op jouw naam | DNS, analytics, mailservices blijven van jou | Een wachtwoordkluis met alle logins bij oplevering |
| Handover-document of README | Een ander kan de site begrijpen en draaien | Lees het: snapt een vreemde ontwikkelaar het? |
Bij TopDevs krijg je deze lijst standaard mee: een Git-repository onder jouw eigen account met alle broncode, het domein op jouw registrar-account, een README met deploy-instructies, alle credentials in jouw beheer en een handover-sessie. Vertrek je later, dan kan elke andere ontwikkelaar er zonder ons mee verder. Dat is de definitie van geen lock-in.
Welke red flags wijzen op lock-in voordat je tekent?
Je hoeft geen jurist te zijn om de signalen te herkennen. Deze zinnen en situaties zijn waarschuwingen dat je straks vastzit:
- “De code blijft van ons, je krijgt een gebruikslicentie.” Dat is huur, geen eigendom. Vraag waarom.
- “Wij regelen het domein voor je, daar hoef je niet naar om te kijken.” Prima service, maar eis dat het op jouw account komt, niet op dat van het bureau.
- “Exporteren kan, maar dat is een apart traject met meerkosten.” Eigendom dat geld kost om op te halen, is geen volledig eigendom.
- Een eigen, gesloten CMS of framework dat alleen zij onderhouden. Hip klinkt het, maar niemand anders kan eraan werken. Vraag altijd: op welke standaard, open stack bouwen jullie?
- Geen schriftelijke afspraak over wat je bij vertrek meekrijgt. Als het niet op papier staat, bestaat het bij een conflict niet.
Een goede partij beantwoordt de vraag “wat krijg ik mee als ik weg wil” binnen vijf minuten, zonder ontwijking. Een partij die daar omheen draait, wil je liever vasthouden dan goed bedienen. Dat is de scherpste lakmoesproef die er is.
Wat is het verschil tussen hosting huren en je site bezitten?
Hier zit een hardnekkig misverstand: mensen denken dat ze hun site bezitten omdat ze hosting betalen. Maar hosting huren is normaal en geen probleem. Vrijwel iedereen huurt serverruimte bij een hoster, of dat nu TransIP, Hetzner, Vercel of Cloudflare is. De vraag is niet of je huurt, maar of je weg kunt.
Bezit zit in de broncode en de portabiliteit, niet in de server. Heb je je code in een Git-repository en je content in open formaten, dan is hosting een commodity die je in een dag verplaatst. De applicatie staat los van de infrastructuur. Heb je dat niet, dan is je hosting een gijzeling: stoppen met betalen betekent dat de site offline gaat en je niets in handen hebt om hem elders neer te zetten.
Voor de techniek achter snelle, overdraagbare sites is de web.dev gids over Core Web Vitals een goede standaard om naar te vragen, en voor hoe Google sites beoordeelt is Google Search Central de bron. Een site die je bezit, kun je op die punten blijven verbeteren bij wie je maar wilt.
Hoe haal je je website terug als je nu al vastzit?
Zit je al klem, dan is er bijna altijd een weg terug, in een vaste volgorde:
- Domein eerst. Verhuis het domein naar je eigen registrar-account. Dit is de belangrijkste laag en vaak een kwestie van een verhuiscode opvragen. Lukt het niet via je bouwer, dan kan de registrar of in het uiterste geval SIDN (voor .nl-domeinen) helpen.
- Content veiligstellen. Kopieer alle teksten, download alle afbeeldingen, exporteer wat exporteerbaar is. Doe dit voordat je ergens een abonnement opzegt.
- Beoordeel de broncode. Heb je geen repository, dan is herbouw waarschijnlijk goedkoper en sneller dan onderhandelen om code los te krijgen die op een gesloten platform leeft.
- Bouw opnieuw op een open basis. Kies een maatwerk aanpak of een open platform waarbij eigendom vanaf dag één geregeld is, zodat je dit nooit meer meemaakt.
Reken voor een builder-site (Wix, Squarespace) op een echte herbouw, niet op een verhuizing. Dat klinkt als verlies, maar het is een eenmalige correctie waarna je voor altijd vrij bent. Voor de afweging tussen platforms en wat dat kost, lees WordPress vs maatwerk vs headless.
Hoe bewijzen onze cases dat eigenaarschap werkt?
Eigenaarschap is geen belofte op een slide, het is wat je bij oplevering in handen krijgt. Twee voorbeelden waar dit concreet werd:
- De Bungelaer. Voor deze website en webdesign-case leverden we de volledige broncode in een repository onder eigen beheer, plus het domein en alle credentials. Het bedrijf kan de site door elke ontwikkelaar laten doorontwikkelen.
- Quantum Life. Bij dit platform met eigen interface was code-eigendom vanaf de discovery een harde eis. Alles staat op naam van de klant, inclusief de deploy-instructies.
De rode draad: één team dat ontwerpt en bouwt, en je daarna alles in handen geeft om er zonder dat team mee verder te kunnen. Dat is precies waar het verschil tussen huren en bezitten zichtbaar wordt.
Wat is de eerste stap?
- Stap 1: inventariseer je vier lagen. Waar staat je domein, wie heeft je hosting, bestaat er een repository, en kun je je content exporteren? Schrijf per laag op of je het bezit of huurt.
- Stap 2: claim je domein terug als dat nog niet op jouw account staat. Dit is de snelste en belangrijkste winst, vaak in een dag geregeld.
- Stap 3: leg eigendom vast voor je volgende project. Eis een Git-repository op jouw account en een handover-document, contractueel.
Plan een vrijblijvend gesprek als je samen wilt kijken of je echt eigenaar bent van je site en hoe je dat terughaalt. Geen verkoopdruk, wel een eerlijk beeld. Onze afspraken over eigendom staan zwart op wit in onze algemene voorwaarden, en de bredere context vind je in onze gids over een maatwerk website laten maken.
