Who Actually Owns Your Website? Domain, Hosting, and Code Explained for Non-Techies

You paid $6,000 for your website last year. It's up. It looks good. Customers use it. Your designer is responsive and things are fine.

Then one day, the designer stops responding. Or their business closes. Or they raise their rates by 300% and you want to leave. Suddenly the question that never mattered becomes urgent: do you actually own your website? Can you take it with you? Or are you stuck?

Most business owners don't know the answer to this question until they need to. This post is the plain-English explainer of website ownership — what the three critical pieces are, how to check what you own right now, and what to do if the answers aren't what you want.

The three pieces every website is made of

Every website consists of three separate things, each of which is separately owned. Understanding this is the whole game.

The domain name. The address of your site, like `smithplumbing.com`. This is registered through a company called a domain registrar (GoDaddy, Namecheap, Google Domains, Cloudflare, etc.) and typically costs $10-$20 per year. Whoever's name is on the registration owns the domain, legally.

The hosting. The server infrastructure where your site's files actually live. This is provided by a hosting company (Bluehost, SiteGround, WP Engine, Vercel, DigitalOcean, etc.) and typically costs $10-$50 per month for a small business site. Whoever pays the hosting bill controls the server.

The code and design. The actual files that make up your site — HTML, CSS, JavaScript, images, content management system, database. These are the "site" itself in the intellectual property sense. Whoever has the source files (and copyright) owns the site.

Each of these three can be owned by different parties. Your domain could be owned by you, your hosting could be controlled by your designer, and your code could belong to a subcontractor of your designer. This is not how it should be, but it's how it often is.

How ownership actually plays out in different scenarios

The three ownership pieces determine what happens in every real-world scenario:

Scenario 1: Designer disappears. If you own all three (domain, hosting, code), you're fine — hire a new developer to make whatever changes you need. If you own the domain but not hosting or code, your site keeps running for now, but you can't make changes and the site will eventually break. If you don't own the domain, your entire site can disappear when the designer stops paying for it.

Scenario 2: You want to change designers. If you own everything, you just give the new designer access to your hosting and hand off the code. Painless. If the designer owns the code, you may need to negotiate to buy it (or rebuild from scratch). If the designer owns hosting or domain, you have to migrate to your own accounts first — sometimes with the previous designer's cooperation, sometimes without.

Scenario 3: Designer's business closes. If they owned the domain, that domain may expire and become available to anyone (including domain squatters who might resell it back to you at high cost). If they owned the hosting, your site might go offline when their business account stops paying bills. If they owned the code, the source files might be lost entirely.

Scenario 4: You want to sell your business. The website is part of the business's assets. Selling requires transferring the website to the buyer. This is easy if you own everything and near-impossible if pieces are controlled by a designer who's no longer involved.

Understanding these scenarios shows why ownership matters even when everything is fine. The consequences of not owning things only appear when something goes wrong, but by then it's too late to fix.

How to check what you own right now

Do this now, whether you have a designer or not. It takes about 30 minutes.

Check your domain ownership.

Go to `whois.com` (or any WHOIS lookup site). Enter your domain name. Look at the "Registrant" field. If you see your name and business address, the domain is legally registered to you. If you see "Privacy Protected" or the designer's name, you have a problem to solve.

Even if you're listed as the registrant, verify you have login access. Try logging into the registrar (GoDaddy, Namecheap, whatever it is) using an email you control. If you can't log in, you don't have practical control, only theoretical ownership.

Check your hosting.

Ask your designer (or yourself, if you're technical) where the site is hosted. Try to log into that hosting account using your credentials. If you can log in and see admin controls, you have hosting access. If you don't have credentials, or the account is owned by the designer, you don't have practical hosting control.

Even if you have hosting access, verify who's paying the bill. If the designer's credit card is the payment method on file, your site depends on their continued cooperation.

Check your code and content.

Ask your designer if you have the source code files. Ideally, ask for a copy of everything — the HTML, CSS, JavaScript, database exports, image files. Store them somewhere safe (your own Google Drive, Dropbox, or hard drive). If you can't get the source files, you don't fully own the site's IP.

If your site is built on WordPress, Webflow, Squarespace, or Wix, ask for admin access to the platform. Verify you can log in. Verify you can export content.

The most common ownership mistakes

Reading the Reddit threads on ownership disasters, the same patterns show up repeatedly.

Designer registered the domain in their name. Extremely common. The designer set up the domain during the project because they were doing the technical work. It ended up on their credit card and in their name. Now you have no legal ownership of the domain that represents your business online.

Designer's business is the hosting account holder. Same pattern. Designer set up hosting during the project on their business account. If the designer's business closes or the credit card lapses, your site goes offline.

Designer built the site and never delivered the code. The site works on the internet, but you don't have the source files. If you want to move to a new developer, they have to start from scratch or reverse-engineer the existing site.

Site built on a proprietary platform that can't be exported. Some site builders (especially some agency-built sites) use custom content management systems that lock you into that agency permanently. If you leave, you rebuild from scratch.

Multi-year hosting or domain deals that lock you in. Some designers register the domain or hosting for multiple years with their own account. Even if you want to leave, the paid-through-2028 accounts create friction.

How to fix ownership problems right now

If your ownership check revealed problems, fix them systematically. In this order:

Fix domain ownership first. This is the most urgent and often the most fixable. Contact the current registrar. Request a transfer of the domain to a registrar you control (Namecheap and Cloudflare Registrar are common choices with reasonable pricing). The transfer requires an authorization code from the current registrar and takes 5-15 days. If the designer is cooperative, they'll provide the code. If not, contact the registrar directly for dispute resolution.

If the domain is genuinely registered in the designer's name (not just accessed through their account), you have a harder path. Ask them to transfer ownership to you formally. Most will if asked professionally. If they refuse, legal action is possible but usually expensive.

Fix hosting next. Set up your own hosting account with a reputable host. Copy your site's files to your new hosting. Point your domain to the new hosting. This can be done with your current designer's help (they typically don't care about hosting) or by hiring a developer for a few hours.

If your current site is on a proprietary agency platform that can't be exported, you may need to accept that migrating means rebuilding from scratch. In that case, plan for a new build on ownable infrastructure rather than fighting to extract from the agency platform.

Fix code ownership last. Request the source files from your designer. Save them somewhere you control. If your designer refuses to provide source files, check your original contract — many web design contracts include an "at completion, ownership of deliverables transfers to client" clause. If yours does, cite it and request the files formally.

The prevention playbook for future websites

Whatever you build next, structure ownership correctly from day one.

Register the domain yourself before hiring anyone. Cost: $12/year. Time: 10 minutes. Value: essentially unlimited if things go wrong. Register in your business's name, at your business address, with a credit card you control. Save the login credentials somewhere secure.

Set up your own hosting account (or verify the model transfers to your account). For flat-rate one-week builders, the model often includes hosting transfer to your account at launch. For traditional designers, insist on setting up your own hosting from day one. Give the designer collaborator access rather than making them the account owner.

Require source code delivery at launch. Explicit contract language: "At launch, developer will provide client with all source code, database exports, and content files necessary to independently maintain the site." Don't accept anything less.

Avoid proprietary platforms unless there's a strong reason. Custom-built CMS platforms often mean permanent lock-in. Common platforms (WordPress, Webflow, Squarespace, or well-known modern frameworks like Next.js) let you take the site elsewhere if needed. The exceptions are worth it only when they solve real business problems.

Document everything at launch. Get a launch document listing where the domain is registered (with login), where the site is hosted (with login), where the source files are stored (with access), and any accounts associated with the site (analytics, email marketing, etc.). Keep this document safe.

What Reddit gets right about ownership

The r/smallbusiness threads on ownership disasters usually end with the same recognition: "I didn't realize this mattered until it did." The consequences of not owning your website are invisible until something goes wrong, at which point they're catastrophic.

The prevention is boring but effective. Register your own domain. Set up your own hosting. Get your own source code. Document who has access to what. Do this at every website project, no exceptions, no matter how much you trust the designer.

Trust is not a substitute for ownership. Good designers who deliver great work sometimes have life events, close businesses, get sick, retire, or move on. Any of these can leave you stranded if you don't own what you paid for. Ownership isn't about distrust of your current designer. It's about the reality that any relationship might end for reasons that have nothing to do with either party, and your website needs to survive that.

Own what you pay for. That's the whole rule.