Six Things That Must Stay in Your Name When Someone Else Builds Your Website

Everyone gets along while the website is being built. The trouble starts at the goodbye. You switch agencies, the person who handled it leaves, or the studio that built it quietly closes — and only then does the question come up: "Wait, whose name is our domain actually in?"

This article is about asking that question a few years early. A website looks like one object, but it is really a bundle of separate accounts and permissions. Some of those pieces have to sit in your name regardless of how the design turned out. There are six of them, and most can be checked in about five minutes.

This is not about distrusting whoever builds your site. Good partners tend to welcome the tidy-up — it removes the conversation nobody enjoys having later.

1. The domain — who is listed as the registrant

The most important item, and the one that goes wrong most often. A domain belongs to whoever is recorded as the registrant, not to whoever paid for it. If the domain fee was folded into the build cost, that does not automatically make your company the registrant.

Checking it is slightly awkward. Public whois lookups usually hide registrant details these days for privacy reasons. So the reliable method is to log in to the registrar with your own account and read the registrant record yourself. If you do not have an account to log in with, that is already your answer.

Two things worth knowing if you need to move it. First, transferring to another registrar normally requires an authorization code (often called an EPP code) plus unlocking the domain, and that code can only be issued from the account that currently holds it. Second, for gTLDs such as .com there are rules that can lock transfers for 60 days after a fresh registration or after a change of registrant details. So "just hand it over next week, we launch then" does not always work. Leave yourself time.

2. DNS — you own the address, but who holds the steering wheel

Even if your company is the registrant, the DNS settings decide which server that address actually points to. If those settings live inside someone else's account, that is where the real control sits. Open your domain management screen and check which nameservers it is pointed at. If they are not your registrar's defaults but some service you have never heard of, ask whether that account is yours too.

This matters more than it sounds, because DNS also governs your company email. Most "the mail went down while we were moving the site" incidents start right here.

3. Hosting and deployment — on your account, or inside someone else's

There are two shapes. (a) Your company holds the account and invites the builder in as a member. (b) Your site sits inside the builder's account as one of many client projects.

With (a), ending the relationship is just removing a member. With (b), the whole site has to be migrated, and domains can go briefly dark or settings get lost along the way. Not sure which one you have? Search your inbox for a signup confirmation or billing receipt from the hosting provider. If there isn't one, you have (b).

4. Source code — at minimum, keep a copy

Find out where the code lives and who owns that repository. Repositories are usually held under an organization account, and if that organization belongs to the agency, you are a guest in it.

The ideal arrangement is the repository under your organization with the builder added as a collaborator. If that is not workable, at least get a full archive of the code at launch. You do not need to be able to read it. The difference between being able to hand a developer a copy and saying "please continue from here" — versus not — is enormous.

While you are at it, ask the same question about the database and image storage the site depends on, and about the integration keys it uses. The things built up over time — posts, photos, records — are exactly the things you cannot buy back.

5. Analytics — starting fresh means losing the past

Here is the trap. If analytics was set up under the agency's account and you later say "fine, let's just create a new one under ours," the history does not come with you. Years of traffic data stay in someone else's account and you restart from zero.

So the order matters. Rather than creating something new, ask them to add your Google account as an administrator on the existing property. Take over the permissions and the data simply stays where it is.

Do the same for Search Console, which governs how you appear in search. It has a site ownership verification step, and if you verify ownership with your own Google account, your access survives even if the agency later cleans up its permissions. If you run ads, the ad account deserves the same treatment.

6. Content and licences — what you bought vs. what you borrowed

The photos and typefaces on your site are borrowed more often than people assume. Paid stock image licences are generally tied to the account that bought them, so an image purchased on the agency's account is a separate question from whether you may keep using it. Web fonts are frequently licensed per domain or per traffic volume too.

Copyright is worth naming explicitly. Copyright generally arises with whoever created the work. Commissioning something and paying the invoice does not by itself transfer it. That is why it helps both sides to write down in the contract what happens to those rights — assignment, a licence to use, and within what scope.

This section is not legal advice. For contracts that are large or central to your business, have a professional review them.

If you haven't signed yet, put these lines in

No elaborate legal language required. Spelling out roughly this much removes most disputes before they exist.

• The domain is registered in the client's name, and the client holds the registrar account.
• Hosting, deployment, and database accounts are opened in the client's name; the builder is granted access to work.
• Source code and deliverables are handed over at launch and again at the end of the engagement.
• Owner-level permissions on analytics and search tools are granted to the client's account.
• The scope and ownership of any purchased images and fonts are stated.
• The ownership or licensed scope of copyright is stated.

Already handed it over? A five-minute audit

If the site is running smoothly right now, this is the best possible moment. Asking is easiest when nothing is at stake.

• Can you log in to the registrar with your own account?
• Where do the nameservers on your domain point?
• Is there hosting or deployment mail in your inbox?
• Do you have a copy of the source code?
• Can you open analytics and Search Console with your own Google account?
• Whose account bought the paid images and fonts?

If any of the six comes back "I'm not sure," start there. Simply asking is enough to get it moving.

One last thing

Launch day is the start, not the finish. And anything that starts eventually passes to someone else — another agency, or the colleague who joins your team three years from now.

What that person will need is not an elaborate handover document. It is a handful of accounts that actually log in. Keep those in your name and the site stays yours long after the people who built it have moved on.