I don't actually know if I own my own website's code. How do I check?

This page may contain affiliate links from which Blur Studio earns commissions.

This question comes up most often when a relationship with an agency or freelancer has gone sideways, and suddenly "can I get my website somewhere else" becomes urgent. The uncomfortable answer for a lot of business owners is that they don't actually know, because nobody ever explained that hosting, the domain, and the actual code are three separate things that can each be controlled by someone different.

This check matters whichever host your site actually runs on. A lot of modern sites, including ones built on a platform like Netlify, work by connecting to a Git repository and rebuilding the live site automatically whenever that repository changes. Netlify is one example among several hosts that work this way, not the only one, and the point isn't which host you pick. It's that the repository the host connects to, not the hosting account sitting on top of it, is the actual asset worth confirming you control.

Three separate things that get confused as one

• The domain name (yourbusiness.com) is registered somewhere, under some account. Whoever controls that account can point it anywhere, or take it down, or refuse to hand it over.
• Hosting (where the live site actually runs) is a separate account, which may or may not be in your name even if you're the one paying the bill.
• The code itself, typically stored in a Git repository, is the part people check least often, and it's the part that actually determines whether you can rebuild or move the site at all if the relationship ends.

You can technically own the domain and pay for hosting and still not own the code, if the repository lives under the agency's own account with no access granted to you. That's the scenario this question is really about.

How to actually check

1. Ask directly: "Can you add me as a collaborator on the repository this site is built from?" A straightforward agency will do this without hesitation. Hesitation, vague answers, or being told "you don't need that" are the real warning signs.
2. If they do add you, confirm it's a real Git repository, not a one-time file export. Being emailed a ZIP of the current files once is not the same as having ongoing access to the actual version history and ability to make changes.
3. Check who the repository's actual owner is, not just who has access. Owner and collaborator are different levels; a collaborator can be removed by the owner at any time. For genuine control, the repository should live under your own account, or at minimum an account you fully control, with the agency added as a collaborator rather than the reverse.
4. If none of this exists yet, ask for it to be set up, going forward, as a condition of continuing the relationship. This is a reasonable, normal request, not an adversarial one, and a professional agency should have no issue with it.

Why this matters more than which host you use

Netlify or any other host connects to a Git repository and deploys whatever is in it; the hosting platform itself has no bearing on who controls the code. Switching from one host to another changes where the site runs, not who owns the underlying files. If you don't control the repository, you could switch hosting providers a dozen times and still be exactly as locked in as before, because the thing that actually matters was never the hosting account.

The alternatives, and what they actually fix

Put the code in your own GitHub account and give the agency access flips the ownership structure the right way around: you own the repository, they work in it as a collaborator. This is the cleanest fix if the relationship is otherwise fine and you just want the structure corrected going forward.

A contract clause for code handover is worth having regardless, specifying that on contract end, you receive full, working access to the repository within a set number of days. This matters because even a well-intentioned agency can be slow or disorganized about handover without an explicit deadline forcing the issue.

When hosting is not the actual problem

Hosting doesn't fix ownership. If you move your site to a new host, Netlify or anywhere else, while the code repository still lives entirely under the old agency's account, you've changed where the site runs, not who controls it. Fix the contract and the repository ownership first; the hosting decision is a separate, much less urgent question once that's settled.

A worked example: finding out the hard way

Say a business owner's agency relationship ends badly, invoices went unpaid on one side, promised work went unfinished on the other, and the owner asks for their website files so a new developer can take over. The agency stops responding. The owner still technically has access to the domain registrar and can see the site is live somewhere, but has no idea where the actual code lives, and the agency that built it is now unreachable. A new developer can, at best, rebuild the visible site by copying what's publicly viewable in a browser, but anything that wasn't visible on the surface, backend logic, saved content structures, configuration the agency set up and never documented, is gone unless it can be recovered from the old repository, which the owner never had access to in the first place.

This is the scenario a five-minute "can you add me as a collaborator" conversation, asked early in a healthy relationship rather than during a breakup, would have entirely prevented. The cost of asking upfront is a slightly awkward moment. The cost of not asking, discovered only once the relationship has already soured, can be a full rebuild from scratch.

Common mistakes with code ownership

• Assuming a good relationship means ownership doesn't matter yet. The best time to sort out repository access is precisely while the relationship is good and the request feels routine, not after it's deteriorated and the request feels like an accusation.
• Treating "I can see my website" as proof you control it. Anyone can view a live website in a browser. That tells you nothing about whether you can access, edit, or move the actual source code behind it.
• Not writing the handover terms into the contract at all. A verbal assurance that "of course you'll get access if we part ways" carries no actual weight if the relationship ends on bad terms. Get it in writing, with a specific timeframe, before you need it.

How I'd approach this

When someone comes to me worried about this, the first thing I do is help them get a clear, honest answer to "who actually owns this code right now," since that determines everything else. If the answer is genuinely nobody but the agency, getting real access transferred (or rebuilt from scratch if the agency won't cooperate) comes before any conversation about hosting or new features. Every custom build I do ships with the client owning the repository from day one, specifically so this situation never has a chance to happen again. Get in touch if you want a second, independent opinion on where you actually stand.