Your website · Updated October 4, 2026
Who should own my website and domain?
Updated October 4, 2026
Your business should own all of it. Register the domain in a registrar account the business controls, with the business named as registrant, and keep the top role on hosting, DNS and the site builder. Your developer gets a separate login. For code and content they write, get the copyright assigned to you in a signed document.
Make the business the registrant and the account holder on every layer
If you are setting up a website or reviewing yours, put the business's name on the domain and the business's login at the top of every account the site runs on. Whoever builds or maintains it gets their own login. The business owns; the people who work on it get access.
A website is four things, and each has its own owner. Whoever holds each account, or signed each document, controls that piece. Different organizations document each one, and none of them mentions the others.
- The domain registration
- Held at a registrar under a registration agreement with the registrant. ICANN tells registrants: "it is your right to transfer your domain name registrations between registrars." That right belongs to whoever is named.
- Yours if the business is the registrant and the domain sits in a registrar account you sign in to.
- DNS
- The records that send visitors to your host and email to your inbox. A sender's computer "looks up the MX records for your email domain" to decide where to deliver, Google explains. Whoever edits DNS controls both.
- Yours if you can sign in where the nameservers point and edit the records.
- Hosting and the site builder
- The server or builder subscription. On Wix, the owner role goes to "The person who created the site, or received site ownership", and changes only "by transferring the site to a new owner."
- Yours if the business holds the owner role and pays the bill.
- Copyright in the site
- The text, design and code. Under US law copyright "vests initially in the author": for an outside developer, the developer.
- Yours if your contract assigns copyright to the business in writing.
Who holds the name
Where the name points
Where the site lives
Who owns the work
ICANN names the trap. Its guide to registrant rights describes a holder who lets someone else use the name, "such as a website designer registering a domain name for a client." The designer is then the holder of record. Avoid that arrangement.
Check who holds your domain today: the public record, then your logins, then the contract
Run these checks in order. The first takes two minutes and tells you whether the rest is routine or a recovery.
- Search your domain at lookup.icann.org. ICANN says "The Registrar field shows you who your registrar is." Note the expiry date, the name servers and the status codes, which show whether the name is locked, on hold or being deleted.
- Sign in to that registrar with a business login. If the domain is not in your list, it sits in someone else's account, whatever the invoice says. If it is, check that the registrant contact shows the business name and a business email.
- If the name servers belong to another company, such as your host or a DNS service, sign in there too. Whoever holds that account decides where your site and email go.
- Open the hosting or builder account and find its users or permissions page. The business should hold the owner role; your developer should appear as a separate user.
- Find your website contract and search it for "assign", "copyright" and "work made for hire". A clause that assigns copyright to the business, signed by both sides, is what you are looking for.
If the domain is in your account, the business is registrant, and you hold the top role everywhere, you own it. Add the protections in the next section.
If the domain or DNS account is someone else's, start with the recovery section below.
If the business is registrant but the domain sits in the developer's account, you are in a strong position. As registrant you can ask the registrar for the transfer code yourself.
Set it up so control stays with the business
Invite your developer as a user instead of sharing your password
Give each person who works on the site their own login through the platform's invite screen, and remove it when the work ends. A shared password cannot be taken back from one person.
ICANN's security committee advises that when the people on a registrar account change, "new credentials" be created "and old credentials to be revoked." Turn on two-step sign-in wherever it is offered.
- GoDaddy. Open Delegate Access, choose Invite to Access and pick an access level. Delegates such as "your web designer or developer" can use your products "but they can't view or change account information like your payment methods and passwords."
- Squarespace. Open Permissions & Ownership, click Invite Contributor and switch on only the permissions they need. The Basic plan allows one contributor besides the owner.
- Wix. Invite them under Roles & Permissions as Website Designer or Website Manager. Even Admin (Co-Owner) "Cannot delete or transfer the site, or connect a domain," so keep the owner role yourself.
- Cloudflare. Use Invite on the Members page with the narrowest role that works. Only a Super Administrator can manage members, so keep that role.
- WordPress. Create a user for them. Administrator has "access to all the administration features within a single site", so keep one Administrator login of your own.
Put a contact email on the registration that does not run on the same domain
Use a registrant and account email that would still work if your domain stopped working, and make it a role address the business keeps, not one person's inbox.
Renewal notices and transfer confirmations go by email to the registrant. If that address is on the domain itself and the domain lapses, the warnings stop arriving. ICANN's security committee advises contact addresses "assigned to mail servers named outside that domain," and contacts not tied to one employee, which it says "may help an organization avoid disputes over ownership of a domain."
Turn on auto-renew and keep the card on file current
Set the domain to renew automatically on a business card, and put the expiry date from the lookup in your calendar a month ahead. ICANN's registrant terms say that if you choose auto-renewal, "you must also keep your payment information current."
The timeline after a missed renewal is shorter than most owners expect. ICANN's Expired Registration Recovery Policy requires the registrar to send at least two reminders, about one month and about one week before expiry, and one more within five days after. After that:
Redemption Grace Period
30 days
The last window to restore a deleted domain, through the registrar that deleted it, usually for a fee.
- From expiry, "registrars may delete registrations at any time after they expire." For at least the last eight days it can still be renewed, the registrar must cut its DNS, so your site and email stop.
- Once deleted, the name enters a 30-day Redemption Grace Period. Only the registrar that deleted it can restore it, for the registrant, and restoring can cost a redemption fee on top of the renewal.
- Five days after that, ICANN says the domain "is purged from the registry database and becomes available for registration" by anyone.
For example
A roofer's first web designer registered the domain in the designer's name, on the designer's card. The designer closes up shop, the card expires, and the reminders go to an inbox nobody reads. The roofer finds out when the website and every company email go dark. The name can still be renewed, but the registrar deals with the registrant, and that is the designer. With the business as registrant on its own card, the reminders reach the roofer.
Get the copyright in your site assigned to you in a signed document
If an outside developer or writer builds your site, put a clause in the contract that assigns the copyright in the design, code and text they create for you to the business, and have both sides sign it.
Paying for the work does not transfer the copyright. The US Copyright Office explains that ordinarily "the author is the person or persons who actually created the work." A contractor's work becomes a "work made for hire", owned by the client from the start, only when it falls into one of nine listed categories and both parties sign a written agreement saying so. "If a work fails to satisfy any of these requirements, it is not a work made for hire."
Websites are not one of the nine categories by name, so a work-made-for-hire clause alone is a gamble. That is a judgment, not a ruling; the Copyright Office "cannot provide legal advice about the status of a work." An assignment is safer, and the Copyright Act says a transfer of copyright "is not valid unless" it is "in writing and signed by the owner of the rights conveyed."
- Assignment. Copyright in everything made for you passes to the business on payment.
- Third-party parts. A list of themes, plugins, fonts and stock photos the developer did not create, with whose name each license is in.
- Handover. On request or at the end of the contract, the developer hands over the site files, a database export and every login they created, and removes their own access.
Isn't a website I paid for automatically a work made for hire?
Not when the builder is a contractor. One route is a work by an employee within their job. Among the Copyright Office's tests for employee status: "Does the creator have his or her own business?" A designer with their own business and other clients points to contractor, not employee.
The other route needs all four: one of the nine categories (a contribution to a collective work, part of an audiovisual work, a translation, a supplementary work, a compilation, an instructional text, a test, answer material for a test, or an atlas), a written agreement, express words that it is a work made for hire, and both signatures. Miss one and the developer keeps the copyright. A signed assignment avoids the question.
If a former developer holds the domain
If you are the registrant, ask the registrar for the transfer code and move the domain into your own account
Open a registrar account in the business's name, ask the current registrar for the domain's authorization code (also called the auth code or transfer code), and start the transfer from your new account.
ICANN says your registrar must either let you generate the code yourself or "provide you with the AuthInfo code within five (5) calendar days of your request." It must also lift its transfer lock on request, and may not refuse either "solely because there is a dispute between the Registered Name Holder and the Registrar over payment."
A transfer can still be refused for listed reasons: within 60 days of first registration or a previous transfer, payment owed for a past period, fraud, or a dispute such as a court order. A transfer fee is allowed, but "a transfer cannot be denied due to non-payment of this transfer fee." If a refusal looks wrong, file a Transfer Complaint with ICANN.
If the developer is the registrant, get their written agreement and do the transfer before the name change
Ask the developer in writing to move the domain to the business. A change of registrant needs their confirmation, which ICANN says "typically will take the form of an email to the registered name holder."
Order matters because of a 60-day lock. Changing the registrant's name, organization or email can block a move to another registrar for 60 days. ICANN's advice: "you may want to consider completing the transfer process before changing your contact information." Some registrars let you opt out before the change; they do not have to. ICANN's Board voted in June 2026 to remove this lock, but the change is not in force and has no start date yet, so check the current rules when you start.
- Open a registrar account in the business's name, on a business email that is not on the domain you are recovering.
- Send the developer a short written request: the domain, the account it should end up in, and a date. Ask them to lift the transfer lock and send you the auth code.
- Start the transfer from your new registrar with the code. The current registrar asks the registrant to confirm, so agree in advance that the developer will approve it.
- Once the domain is in your account, change the registrant to the business and the contact email to your role address. Doing this last keeps the 60-day lock from blocking the transfer.
If the developer will not cooperate, the UDRP covers trademark cases. A complaint must prove the domain is "identical or confusingly similar to a trademark or service mark in which the complainant has rights", the holder has "no rights or legitimate interests" in it, and it "has been registered and is being used in bad faith." The remedy is cancellation or transfer. Without a trademark, the routes left are an agreement or a court.
If the domain has already expired, act inside the grace windows
Call the registrar the same day and ask which stage the domain is in: expired but renewable, or in its 30-day Redemption Grace Period.
ICANN's recovery policy gives the right to renew and restore to the registrant at expiration, so a domain registered to an unreachable developer has to be renewed through them. A domain in the grace period "must be restored by your current registrar before it can be transferred," and ICANN "does not have the authority to transfer domain names, including expired ones, back to you." Once released, it goes to whoever registers it first.
Take back DNS, hosting and Search Console the same week
Once the domain is in your account, move every other layer into business accounts before anyone notices a gap.
- DNS first, email second. Before you change the name servers, copy every existing record, especially the MX records that deliver your email, and recreate them in the new DNS account. Leave them behind and email stops arriving.
- Hosting and builder. Get the owner role moved to the business, or a full copy of the files and database to move to a host in your name.
- Search Console. Verify ownership yourself, then remove the old owner. Google warns that unless you delete their verification tokens, "the removed owner will be able to re-verify ownership", and for a domain verified by DNS record, "You must find and remove the DNS record associated with the user."
- Every other login. Remove the developer's users and change any password they knew.
The other accounts tied to your site
If your site feeds Google tools, hold the top role on those too
Apply the same rule to every account that connects to the website: the business holds the top role and the developer is a user. Check these after the domain and hosting are settled:
- Google Search Console: a verified owner on a business login.
- Google Business Profile: the business as primary owner, others as managers.
- Google Analytics and Tag Manager: Administrator on two business emails.
- Google Ads: Admin access and the payments profile in the business's name, covered in full on the page about who should own your Google Ads account.