By Mehdi HassanWhat does website ownership actually mean?
Website ownership means your company holds the legal rights to the site and the admin control of every account it runs on. Those are two separate things. A contract can say you own the code while the domain sits in your old agency's registrar account, and in practice the agency still controls whether your site loads.
For a modern marketing site, control lives in about seven places: the domain registrar, the DNS provider, the hosting account, the code repository (for code-based sites), the CMS, analytics and search tools, and the design source files. Our guide to website hosting for startups explains how those layers fit together. This checklist is about making sure each one is yours.
Lock-in rarely comes from bad intent. It usually comes from convenience: a freelancer registers the domain on their account to save time, a developer creates the hosting project under a personal login, and nobody moves it later. Two years on, that person is hard to reach and you need a DNS change today.
Who owns my website if an agency built it?
If an agency built your website, the contract decides who owns the design, code and copy, and the account settings decide who controls them. Paying the invoice alone doesn't transfer copyright in most cases. You want a written assignment of everything made for the project, triggered by final payment.
We cover the legal side in depth in who owns the website in agency contracts, including how to handle an agency's reusable components and third-party licenses. The short version: new work transfers to you, the agency's pre-existing tools are licensed to you permanently, and fonts, images and plugins are bought in your company's name.
On hosted builders like Framer and Webflow, you don't get a code repository in the usual sense. Ownership there means the project or site lives in your company's workspace, on a plan billed to your card, with the agency added as a collaborator rather than the owner.
What is on the website ownership checklist?
The checklist has one item per account, plus the contract. Work through it in order, because the domain and email account come first: if you don't control the address that receives password resets, you don't really control anything else.
- Create a shared company login address such as web@yourcompany.com, routed to at least two people. Use it as the owner email on every account below.
- Domain registrar: the domain is registered to your company, the registrar account uses the shared address, auto-renew is on and a registrar lock is enabled.
- DNS: you have admin access to wherever the nameservers point, whether that's the registrar, Cloudflare or your host. See domains, DNS and SSL setup for how to check.
- Hosting: the hosting account or team (Vercel, Netlify, Cloudflare, Framer, Webflow) belongs to your company and bills your card. The agency is a member, not the owner.
- Code repository: for code-based sites, the repo lives in your company's GitHub or GitLab organization, with full history, not a zip file sent at the end.
- CMS: your team has owner or admin roles in the CMS, and you know where the content database and media files are stored.
- Analytics and search: you're the owner of Google Analytics, Google Search Console, tag manager and any ad pixels, not a delegated user.
- Design files: Figma files sit in your team's workspace or have been transferred there, including components and assets.
- Licenses: fonts, stock images, plugins and paid components are licensed to your company, with the receipts saved.
- Contract: a signed assignment of design, code and copy on final payment, with a permanent license to any agency background code.
How do you check who controls your domain?
You check domain control by logging into the registrar yourself and confirming the domain appears in an account your company owns. A public WHOIS lookup often shows only a privacy service now, so it won't tell you much. If you can't find a registrar login, ask whoever set up the site which registrar they used.
Once you're in, confirm four settings: the registrant is your company, auto-renew is on with a valid card, the registrar lock (sometimes called transfer lock) is enabled, and two-factor login is required. An expired domain is the fastest way to lose a site, and expiry reminders often go to an inbox nobody reads.
If the domain sits in someone else's account, most registrars support either an internal push to another account at the same registrar or a full transfer using an authorization code. Do it now, while the relationship is good. Moving a domain doesn't have to change its DNS, so the site stays up during the move.
Do you own your website code on Next.js, Framer or Webflow?
You own your code most fully on a code-based stack like Next.js, where the repository is a complete, portable copy of the site you can host anywhere. On Framer and Webflow you own your content and designs, but the site runs on the platform, so ownership means owning the workspace and being able to export what the platform allows.
Stack | What you can take with you | What ownership looks like |
|---|---|---|
Next.js (or other code) | Full source code and history | Repo in your org; hosting account in your name |
Framer | Content and designs; the site runs on Framer | Project in your workspace on your plan |
Webflow | Content via CSV, plus a code export on some plans | Site in your workspace; check what the current plan exports |
WordPress | Theme files, database and media | Hosting and admin login in your name |
None of these is wrong. A hosted builder is often the right call for a small team that wants to edit pages without a developer. The trade-off is that leaving means rebuilding the front end, which is the main thing our Webflow and Framer migration agency guide covers. We build in Framer, Webflow and Next.js, and the ownership rules are the same on all three: your workspace, your billing, your admins.
For example, suppose your freelancer disappears
For example, suppose a freelancer built your site on their own hosting account and stopped replying. If the domain is in your registrar account, you can point DNS at a new host as soon as someone rebuilds or restores the site, and email keeps working throughout.
If the domain is also in their account, you're stuck until the registrar's dispute process resolves, which needs proof that the business owns the name. This hypothetical is why the registrar is item one on the checklist: it's the account everything else depends on.
What should you ask for at website handover?
At handover, ask for proof of each checklist item rather than a list of passwords. Shared passwords are a sign the accounts were never set up properly; the goal is that your people log in with their own credentials and the agency's access can be removed in a few clicks.
Confirm ownership roles
Log into each account yourself and check your company is the owner, not a guest or editor.
Collect the source
Get the repository in your organization, the Figma files in your workspace and any media not stored in the CMS.
Gather licenses and receipts
Save font, image and plugin licenses in one shared folder in your company's name.
Document the setup
Ask for a one-page note on where things live: DNS records, environment variables, form destinations and scheduled jobs.
Review agency access
Decide what access the agency keeps. If they're still working with you, keep them as members; if not, remove them and rotate any shared keys.
Form destinations are easy to miss. If contact forms send to the agency's email tool or a personal inbox, leads leak. Our guide to website form emails not being delivered covers how to route and authenticate them properly.
How do you avoid agency lock-in on future projects?
You avoid agency lock-in by setting the rules before work starts: the project lives in your accounts, the contract assigns the work to you, and the agency documents how the site is put together. An agency that pushes back on any of these is telling you something about how the relationship will end.
Ask three questions on the first call. Whose workspace or repository will the project live in? What happens to the site if we stop working together? Who'll own the domain, hosting and analytics accounts? Clear answers to all three are a good sign. You can also ask how other clients have moved on, because good studios have done clean handovers before.
This isn't a reason to avoid ongoing help. Plenty of teams work with a studio for years. The difference is that they stay because the work is good, not because leaving is hard. If you're weighing who should run the site after launch, read who updates your website after launch.
