You paid the invoices, so you own the website. That is true of the invoices and only sometimes true of the website. What you call “your site” is at least eight separate assets, each sitting in a different account, each transferable on different terms, and a business can hold seven of them and still be completely stuck. Almost nobody discovers the gap at a calm moment: it surfaces when a supplier relationship ends badly, when a domain silently lapses, when email stops arriving, or on the morning a redesign is supposed to start. This article is the check you can run in an afternoon, plus what to do about whatever you find.
The eight things you own separately
People picture a website as one object, like a van or a laptop. It behaves more like a building: the land, the keys, the architect’s drawings and the utility accounts are all distinct, and holding one of them tells you nothing about the others.
The list
The domain registration. The legal registration of yourbusiness.com at a registrar, which is the company that sells and holds domain names. Whoever is named as the registrant, and whoever can log into that registrar account, controls the name.
DNS control. DNS (Domain Name System) is the address book that tells the internet where your domain points: which server serves the website, which service receives your email, which records prove you are allowed to send mail. Whoever controls DNS can move or break your site and your email in about five minutes.
The hosting account. The server or platform account where the site actually runs, and the billing relationship behind it.
The codebase or site file. The actual source: a repository of code, or the project file inside a builder like Webflow, Framer or Wix.
The CMS admin. The content management system login that lets someone add a page, change a price or publish a post, and specifically the administrator level that can create and remove other users.
The design source files. The editable Figma file or equivalent, with real layers, type styles and components. Not a folder of PNGs.
The brand and logo source files. Vector artwork, colour specifications, and the font licences that make your typography legal to use.
The measurement and advertising accounts. Analytics, Google Search Console, the tag manager, the ad accounts, and the conversion history inside them.
Why they come apart
Each item ends up wherever it was most convenient to put it on the day it was needed. The domain was registered before the kickoff call, so the developer used their own card. A staging server was needed, so the agency used the plan it already had. Analytics went in on launch day under whichever account the contractor was already signed into. Five convenient decisions later your website is distributed across other people’s accounts, and nobody made a single decision they would defend as a policy.
The one question that reveals everything
Ask this out loud: if every supplier who has ever touched this website vanished tomorrow, without warning and without goodwill, which of those eight items could I get into by myself, today, with a password reset to an address my company controls? Most businesses can answer yes to three or four.
The domain registration
This is the one that turns a business dispute into an emergency, because the domain carries your email as well as your website.
How it happens innocently
The domain is bought on day one, before contracts, sometimes before the business has an email address to register it against. The developer buys it in thirty seconds on their own registrar account, bills you eleven dollars, and everyone moves on. Nine years later that account belongs to a person who has changed companies twice and whose recovery phone number is a SIM they threw away.
What it costs
Two things, and the second is worse than people expect. First, you cannot move the site anywhere without the other party’s cooperation, because a migration ultimately means pointing the domain at a new host. Second, your email lives on the same name, so a lapsed or hijacked domain stops invoices reaching customers and stops customers reaching you.
Put a number on it with your own inputs. Assume the site produces 40 qualified enquiries a month, you close 25 percent of them, and average project value is 6,000 dollars. That is 40 x 0.25 x 6,000 = 60,000 dollars of work won per month. A month has about 4.33 weeks, so one week of the domain being unreachable costs roughly 60,000 / 4.33 = 13,900 dollars of won work, before you count the customers who email, bounce, and quietly go elsewhere. Swap in your own three numbers and the calculation takes a minute.
There is also a deadline you do not control. An expired domain goes through a grace period and then a redemption period, and recovering it from redemption carries a fee far above the renewal price: treat 100 dollars as a planning figure rather than a quote. Expired names with traffic get bought within hours, so losing it outright is a real outcome.
What good looks like
The registrar account is in your company’s name, with a company email as the contact, billed to a company card, two factor authentication held by someone who will still work there next year, and auto renew on. Suppliers get invited into that account, never the other way around.
DNS control
DNS is the item most business owners have never heard of and the item that decides how fast anything can be fixed.
What it actually controls
Your DNS zone holds the records that point the domain at your web host, the records that route email to Google Workspace or Microsoft 365, and the authentication records (SPF, DKIM, DMARC) that stop your mail landing in spam. It is often not held at the registrar. The domain can be registered in your name at one company while the nameservers point at a completely different account, typically the agency’s, or a CDN account somebody set up for performance reasons.
How it goes wrong
The awkward version is a split: you own the domain, they own the zone. On paper you are fine. In practice, on the day you launch a new site, you cannot change a single record and you are waiting on a supplier you no longer have a warm relationship with. Every cutover plan that keeps a site online depends on changing DNS to a schedule you set. Without zone access, “we go live Tuesday morning” is a hope. The worse version is that nobody knows where the zone is at all, because the site works, so nobody has looked since a contractor left three years ago.
What good looks like
You can log into whichever account holds the nameservers, see the full record list and edit it. Ideally the zone sits at your registrar or a DNS provider in your own account, so there is one less party in the chain. Export every record to a text file now and keep it with your company records: if the zone is ever lost, that file is the difference between an hour and a week.
The hosting account
The reseller trap
Plenty of agencies buy one large hosting plan and put many client sites on it. It is efficient, it is cheaper for you, and it is completely normal. It also means there is no account for you to be given, because the account is theirs and it holds other people’s businesses. You cannot be added as a user without exposing their other clients, so the honest handover is a migration rather than a transfer, and migrations take planning and money.
This is not fraud. It is a structural choice that quietly converts your exit into a project. Ask about it before the build, in the same conversation where you ask the other awkward supplier questions, not on the day you want to leave.
What you cannot do without it
Without hosting access you cannot take a backup, see the server configuration, renew or move the SSL certificate, read the error logs when something breaks, or give a new developer anywhere to work. You also cannot verify your own security basics, because you cannot see what version of anything is running.
What good looks like
The hosting account is in your company name, billed to your card, with your supplier added as a collaborator. A shared agency plan by choice is fine, but the contract should then say what an exit looks like: who performs the migration, on what timescale, at whose cost. Get that written while everyone is happy.
The code, or the only copy on the server
No repository, one copy, live
A repository is a version-controlled home for your site’s source code, usually on GitHub, GitLab or Bitbucket. It stores every version, records who changed what, and lets a new developer pick up the work. Plenty of smaller sites have never had one: the code was written locally, uploaded to the server, and the only copy that exists is the running site. That is a very bad place to keep an asset. There is no history, so nobody can undo a bad change, there is no way to test anything safely, and the day the server is lost the site is genuinely gone rather than offline.
The builder version of the same problem
If the site is on a hosted platform, the equivalent question is what an export actually produces. The honest answers vary a lot. Webflow gives you static HTML, CSS and assets, but not your CMS structure, your forms or the editor itself. Squarespace gives a partial import file that leaves most of the site behind. Wix gives you effectively nothing you can rebuild from. Shopify lets you download theme files and export products and orders as CSV, while app configuration and page-builder sections stay behind.
None of that makes those platforms wrong. It makes the phrase “we can export it” close to meaningless on its own, and it is the reason the cheap build is rarely the cheap decision once you price in what a future move will require.
What good looks like
A repository owned by a company account, your supplier invited into it, and at least one employee with owner rights. On a builder, you have a written, tested answer to “what comes out, and what does it cost to rebuild what does not”, plus a scheduled export of your content. Content took years to accumulate; layout can be rebuilt in weeks.
The CMS admin
The last remaining administrator
The most common version is boring. The site was built five years ago, the developer set themselves up as the only administrator, your team got editor accounts that can change text but cannot create users, and everyone was happy because everyone could do their job. Then the developer stopped replying to email. Now you can edit a paragraph but cannot install anything, cannot see who else has access, and cannot remove a former employee’s login. That last part is a security problem, not an inconvenience: an old account with publishing rights is an open door.
Ghost accounts and shared logins
Open your user list and read every row. Expect a former marketing hire, an SEO contractor from a campaign that ended, a support account somebody created to debug a problem in 2023, and a login called “admin” whose password lives in a shared document. Every one of those can publish to your website.
What good looks like
At least two administrators who are employees, named individually. Every supplier has their own account rather than a shared one, so access can be removed one person at a time, as part of offboarding, the week they leave rather than the year after.
Design, brand and font files
Editable files versus flattened output
You were sent the logo as a PNG and the pages as JPEGs, and both look right, so the handover felt complete. It was not. A PNG of a logo cannot be scaled to a building sign or printed cleanly, and a JPEG of a page cannot be edited by the next designer. Reconstructing artwork from a flattened image is real work, and redrawing a logo from a JPEG is a job people pay for precisely because the source was never handed over.
The design equivalent is the Figma file. If it lives in the designer’s personal account you have viewing access at best, and viewing access ends when they close the account or hit a seat limit. A rebuild that starts from a real file with type styles, components and spacing rules costs a fraction of one that starts from screenshots, which is why the file matters even if you never open it.
What a complete brand handover contains
Vector source for the logo (the editable original, not just an export), the full export set for different uses and sizes, exact colour values for screen and print, and the typography specification. If you are unsure whether what you were sent is complete, the checklist in logo file formats is a faster read than chasing a supplier who has moved on.
The font licence nobody checks
Fonts are software, and they are licensed. Two failure modes are common. A desktop licence bought in the designer’s name covers their machine, not yours, so your own team technically cannot set your brand type. A webfont licence is usually sold against pageview tiers and to a named licensee, so the licence covering your website may belong to an agency that no longer works for you. Nobody chases this until traffic grows or a lawyer reads the contract, and then the fix is either buying the licence properly, which is cheap, or changing your brand typeface, which is not.
Analytics, Search Console and the ad accounts
History belongs to whoever owns the account
Analytics data is not portable in the way people assume. If your Google Analytics property was created inside an agency’s account, the years of history sit in a container you do not own, and access that was granted can be removed. A fresh property started after a fallout begins at zero: no year-on-year comparison, no baseline for a redesign, no way to prove what worked. Everything worth knowing in what a business should measure depends on a continuous record, and a continuous record depends on account ownership.
The four separate accounts
Analytics, Search Console (Google’s tool showing what queries you rank for and what pages have indexing problems), the tag manager (the container holding the tracking snippets on your site), and each advertising account. They are separate systems with separate ownership. It is entirely normal to find your analytics fine and your Search Console verified only under a contractor’s personal Gmail.
Ad accounts carry an extra sting: the conversion history in an ad account is what the platform’s bidding uses to find customers. Starting a new account means starting that learning again, and paying for it in worse results for weeks.
What good looks like
Every account created under a company-owned identity, with your suppliers added as users at the access level they need. Where a platform separates the account owner from the property, check both. Before any redesign, take an export of your key reports, because protecting your baseline is impossible if you cannot see what the numbers were before you changed anything.
Most of this is drift, not malice
Be direct about this, because the topic invites paranoia and paranoia leads to bad decisions.
The honest picture
The overwhelming majority of ownership problems are created by helpfulness. A developer registered a domain to unblock a launch. A designer used their own Figma account because the client had no team plan. A contractor added analytics from the browser they were already logged into. None of those people intended to hold anything, and most would hand it over today if you asked clearly and they could find the password.
A small minority do use ownership as leverage, usually once a relationship has already gone bad, and they are the reason to run this check while things are good. But go into an audit assuming bad faith and you will damage a working relationship over a problem a five-minute conversation would have fixed.
The one thing that is not acceptable
Refusing to hand over assets you paid for, or pricing the handover as a penalty, is not a business model, it is a hostage situation. A studio that is confident in its work does not need to hold your domain. If a supplier’s answer to “can we own our domain” is anything other than yes, you have learned something important about the rest of the relationship.
The afternoon audit
Block three hours. You need your card statements, your password manager, and permission to log into things. Do it in this order, because each step tells you where to look next.
Hour one: the address and the server
Look up the domain. Use a public WHOIS or RDAP lookup, which is the directory record for a domain name. Privacy rules redact the registrant’s contact details, but the record still shows the registrar, the creation date, the expiry date and the nameservers. Write down all four. Good answer: you recognise the registrar, and you can log in and see your company as registrant. Bad answer: you have never heard of the registrar.
Find the DNS host. The nameservers in that record tell you where the zone lives. If they say something like ns1.someagency.com, the zone is not yours. Good answer: you can log in and edit records. Bad answer: you cannot identify the account, or you can see the records but only through a supplier’s screen share.
Find the hosting bill. Search your card and bank statements for recurring charges to hosting companies. Then ask your supplier directly: is our site on a plan in our name or on yours? Good answer: an account you can log into. Acceptable answer: an agency plan, with a written exit procedure. Bad answer: nobody is sure.
Hour two: the code, the admin and the people
Find the repository. Ask which repository holds the source and who owns the organisation it sits in. Good answer: a company-owned organisation where a named employee is an owner. Bad answer: a personal account, or “there isn’t one, it’s all on the server”. If it is the latter, your first spend is a backup and a repository, not a redesign.
Read the CMS user list. Open the users page and read every account: name, email domain, role, last login. Good answer: two employee administrators, every supplier separately named, nobody you cannot identify. Bad answer: one administrator who does not work for you, or shared logins.
Check the platform account. On a builder, check who owns the workspace and who is billed. On Webflow, Framer, Shopify or similar, workspace ownership is a separate thing from site access, and it is the thing that transfers.
Hour three: files, accounts and licences
Locate the design files. Whose account holds the Figma file, and what is your access level? Good answer: your organisation owns the file. Acceptable: the file has been duplicated into an account you own, and the copy has real layers. Bad answer: view-only access to a file in somebody’s personal workspace.
Locate the brand files. Do you have editable vector source for the logo, colour values, and the typography specification, in company storage rather than an email thread?
Check the four measurement accounts. For analytics, Search Console, the tag manager and each ad account, look at who has owner or administrator rights and which email domain they use.
Check the licences. Fonts, stock photography, premium plugins and themes, and any paid API keys. For each, find the licence document and check the name on it. Good answer: your company. Bad answer: the agency’s name, or no document at all.
Score it honestly
Mark each of the eight items green (you control it alone), amber (you have access but somebody else controls it) or red (you have neither). Reds are the work list. Ambers are the risk register. Do not average them into a comfortable overall number, because ownership does not average: one red on the domain outweighs seven greens everywhere else.
Having a copy is not having control
This distinction is where most people fool themselves, and it is worth stating plainly.
Three tests
A copy is a file you were sent. Control is the ability to act without asking anyone. Apply three tests to each item: can you change it, can you move it somewhere else, and can you remove someone else’s access to it? If the answer to all three is no, you do not have control, no matter how many files are in your Dropbox.
A zip of the site’s code you cannot deploy is a souvenir. Editor access to a CMS where you cannot manage users is a permission somebody granted and can revoke. Being “on” the analytics account as a viewer is an invitation, not ownership. An agency saying “of course it’s yours” in an email is a sentiment, not an access record.
Where the illusion usually hides
The favourite hiding place is the handover pack: logo exports, a PDF style guide, a folder of images, a document of passwords that were rotated a year later. It looks generous, and it contains almost nothing from the eight-item list, because those items are accounts rather than files. Judge a handover by what you can log into, not by how much you were sent. The same principle applies to what a developer actually needs at handoff: the useful thing is the working source, not a beautiful summary of it.
Getting control back without a fight
Assume good faith and structure the ask so it is easy to say yes to. Most of these resolve in a week.
The calm sequence
One: ask in writing, specifically. Not “please send us everything”. List the eight items and ask, for each, where it lives and what has to happen to put it in an account you own. Give a deadline, two weeks is generous, and say why: record keeping, insurance, continuity. You are not accusing anyone.
Two: prepare the destination first. Create your own registrar account, hosting account, repository organisation, Figma team and analytics account before you ask for anything. The commonest reason handovers stall is that there is nowhere to hand things to, and a supplier waiting on you looks exactly like a supplier stalling.
Three: take transfers in order. Domain and DNS first, because they are quick and they matter most. Then measurement accounts, usually a two-click permission change. Then code and hosting, which take real work. Then files and licences, which are slow but rarely urgent.
Four: confirm each one by using it. After each transfer, log in yourself and change something harmless. A transfer that has not been tested has not happened.
If they stall
Escalate calmly and in order. Move the conversation from a project manager to whoever owns the business, and restate the request as a list with dates. Offer to pay for the time: an agency spending half a day on migrations is entitled to bill for it, and a few hundred dollars moves this faster than any amount of principle.
If that fails, use the leverage you have. Ongoing payments to them are yours to stop. Registrars run dispute processes when a domain is registered to a party without authority, and they will want documentation, which is why your invoices and your written requests matter. A short letter from a lawyer is cheap relative to the asset and often ends the matter in a week.
When to stop trying and rebuild
At some point recovery costs more than replacement. Do the arithmetic instead of arguing about it. Assume a 12-page marketing site. Rebuild path: 12,000 dollars for a new build, six weeks, and the outcome is fully certain. Recovery path: 2,000 dollars of legal time, plus roughly 30 hours of your team’s attention across two months at an internal cost of 60 dollars an hour, which is 1,800 dollars, plus 3,000 dollars to a new developer to untangle undocumented code you have never seen. That totals 6,800 dollars and two months, with maybe a 60 percent chance of actually getting clean access.
On those assumptions recovery is cheaper on paper and worse in practice, because the expected outcome includes a 40 percent chance of spending 6,800 dollars and still needing the 12,000 dollar rebuild. Multiply: 0.6 x 6,800 + 0.4 x (6,800 + 12,000) = 4,080 + 7,520 = 11,600 dollars, which is within a rounding error of just rebuilding, and it takes twice as long. Swap in your own numbers, but expect this shape.
Two things change the answer. If the domain is the disputed asset, fight for it, because a domain cannot be rebuilt and your email depends on it. If the disputed asset is the code or the design of a site that is several years old and due for replacement anyway, stop fighting and put the money into the new one, using a realistic redesign budget and process rather than an emergency scramble. Do salvage your content, your URL list and your analytics exports first, because those genuinely cannot be recreated.
What your next contract must say
Four clauses, in plain language, and none of them should be controversial to a decent supplier.
Ownership and transfer
State that all domains, hosting accounts, repositories, design files, brand assets and measurement accounts related to the project are the client’s property, and that any account the supplier creates on the client’s behalf is registered in the client’s name or transferred within 14 days. Name the transfer, do not imply it.
Intellectual property on payment
State that ownership of the design and code passes to you on final payment, and that the supplier keeps only the right to show the work in their portfolio. That last part is fair and you should grant it. Note the exclusions: a supplier’s pre-existing internal tooling and any third party components stay licensed rather than transferred, and the contract should list them.
Exit and handover
Define handover as a list of accounts and a deadline, say who pays for migration off shared infrastructure, and state that handover is conditional on nothing except paid invoices. If a supplier will not agree to that last clause, you have your answer about them.
Source files and licences
Require editable source files, not exports, delivered into storage you own, and require that fonts, stock imagery and paid components are licensed in your company’s name with the licence documents delivered alongside.
The hygiene that keeps it true
An audit fixes today. These four habits stop the drift coming back, and they cost almost nothing.
Company identities, company card
Every account is created with a company email address, ideally a shared alias that survives staff changes, and billed to a company card. Personal Gmail accounts are how ownership leaks. Keep the credentials in a company password manager, never in a document or an email thread.
One named internal owner
Give one employee responsibility for the record, not the technical work. They keep a one-page register of the eight items: where each lives, who has access, what it costs, when it renews. Review it twice a year alongside the rest of your site maintenance routine. Twenty minutes twice a year prevents this entire category of problem.
Offboarding as a habit
When a supplier or employee stops working with you, remove their access that week. Registrar, hosting, repository, CMS, design files, analytics, ad accounts. Do it while the relationship is warm and it is administration. Do it eighteen months later and it is an incident.
Ask new suppliers on day one
Put the ownership questions in the brief, before anyone quotes. Who registers the domain, whose hosting, which repository, whose Figma, whose analytics. A good supplier will answer in two lines and be pleased you asked, because it means fewer arguments later. This belongs in the brief you write before a project starts, not in a lawyer’s redline at the end.
Where we stand
We hand over everything as a matter of course, and we set it up that way at the start rather than as a final favour. Your domain is registered in your name on day one, your hosting is in your account with us invited in, your code lives in your repository, your design files sit in a team you own. If we stopped working together tomorrow you would notice nothing except that we were not there. That occasionally costs us the easy retainer that comes from being the only party who can change anything, and it is a trade we are happy with, because a client who stays by choice is worth more than one who stays because leaving is expensive.
If your afternoon audit turned up more red than you expected, or you would like a second pair of eyes on where things actually live before you start a redesign, write to us at hello@beconfidency.agency and we will talk it through with no obligation, including telling you when the honest answer is that you do not need us.
When you are ready to rebuild on foundations you control from the first day, our web development service is built around exactly that.