Who actually owns your website? 7 things to check before you hire a developer
It usually starts with a simple request. You want to change a phone number, add a page, or move to a new developer. Then you discover you can't. The domain is registered to someone else. The hosting account is in your old developer's name. Nobody can find the login for the admin panel. And the person who built the site has stopped answering emails.
This happens more often than you might think, and rarely because anyone meant harm. A freelancer sets things up in their own accounts because it is faster. An agency keeps everything on its servers because that is how it bills. Years later, the person moves on, and you are left paying for a website you don't fully control.
The fix is simple, and it is much easier to arrange before a project starts than after.
The 7 things that should be in your name
1. The domain
Your domain is your address online, and the most important thing to own. It should be registered in your name or your company's name, with your email address on the account. If it expires or is held by someone else, your website and your email can disappear with it.
2. The hosting account
The account where your site runs should belong to you, paid with your card or invoiced to your company. Your developer can be added as a team member with their own login. If the hosting lives in their account, ask how and when it will be transferred to you.
3. The code
If your site is custom-built, the code should live in a repository you own, for example on GitHub, with your developer added as a collaborator. Without the code, another developer can't make changes or take over the project without starting again.
4. The database and uploaded files
Your content, images, products and customer data often live in a separate database or storage service. These should be in your account too, with regular backups you can access.
5. The admin logins
You should have your own administrator account for the website's admin panel, not a shared login, and not only an "editor" account while the developer keeps the keys. Each person who works on the site should have their own login, so access can be removed cleanly when someone leaves.
6. Your business email
If your email runs on your domain, the email service (such as Google Workspace or Microsoft 365) should be in your name as well. Losing control of the domain or the email account can mean losing access to everything else, because password resets go there.
7. Analytics and Google Search Console
Your visitor statistics and your Google Search Console property hold years of data about your site. Make sure you are the owner, not just a user someone else added.
Logins should not travel by email
A common shortcut is for the client to send passwords to the developer, or the other way round. It works, but it is risky: passwords end up in inboxes and chat apps, and you never quite know who still has access.
The cleaner way is simple. You create the accounts in your name and invite your developer as a member. They work with their own login. If you ever part ways, you remove them with one click and keep everything. Where keys or passwords do need to be shared, a shared password manager is much safer than email or messaging apps.
What a proper handover looks like
At the end of a project, you should receive more than a link to your new website:
- All accounts in your name: domain, hosting, code, database, email and analytics.
- A short technical document explaining how the site is set up and deployed, so any competent developer could take over.
- A guide or a recorded walkthrough showing how to edit your content.
- A list of what was set up for search engines, such as redirects from old page addresses if your site was moved. We describe why that matters in how we moved a content platform off WordPress without losing traffic.
Who looks after the site after launch?
Websites need updates over time: security fixes, new versions of the tools they are built on, backups that actually work. Agree on this in writing before launch. There are usually three options:
- A maintenance plan with your developer, with a clear monthly price and a clear list of what is included.
- Another developer, which is only realistic if the site is built on standard, well-documented tools and you own all the accounts.
- No plan, paying for help only when something needs fixing. This can work for simple sites, but know what you are accepting.
Whichever you choose, ownership is what keeps all three options open. If you are deciding between platforms, our comparison of WordPress and custom sites covers what maintenance looks like on each.
Questions to ask before you hire a developer
- Will the domain be registered in my name?
- Whose account will the hosting be in, and who pays for it?
- Where will the code live, and will I own that repository?
- Will I have my own administrator login?
- What will I receive at handover?
- Who handles updates after launch, and what does that cost?
- If we stop working together, what happens to my site and my data?
A good developer will answer these without hesitation. If the answers are vague, take that seriously. And if the price seems unusually low, check whether ownership is part of the deal. We explain what goes into a fair price in what you are actually paying for in a website today.
Already stuck?
If you are reading this because you have already lost access to part of your website, don't panic. Domains, hosting and accounts can usually be recovered or transferred, especially when they were paid for by your business. Start by finding invoices and the email addresses used to register things, then contact the domain registrar and hosting provider directly.
At Foldworth, every client project is set up in the client's own accounts from day one, and we are added as members. If you want a second opinion on your current setup, or you need to move a site away from a developer who is no longer available, get in touch. We'll start with a free technical check and tell you plainly what you own, what you don't, and what to do next. You can also see what we build.