Who Actually Owns Your Website? The 15-Minute Ownership Audit (2026)

Key takeaways

• "Your website" is actually 13 separate assets — domain, hosting, files, email, analytics, ad accounts — usually bought from different companies, often all held by your developer.
• The domain is the one asset you can't replace. Hosting is rentable, files are rebuildable. A lost domain takes your email addresses and years of Google rankings with it.
• On Wix and Shopify you rent the platform: you can take your data, but not the site itself. On WordPress.org, you own everything.
• In the US, your developer legally owns what they built unless your contract assigns the copyright to you. Look for the word "assign" — "license" is weaker.
• Run the 15-minute audit below today, while the relationship is still friendly. Checking is free; recovering isn't.

Rescue work is a steady part of what we do — taking over half-built sites, abandoned stores, and projects where the developer went quiet. And after enough of these, a pattern shows up that has nothing to do with code quality.

The expensive rescues, the ones that cost real money and take weeks instead of days, almost never start as technical problems. They start as ownership problems. The business paid for a website but never actually held the keys to it. The domain is in the developer's personal GoDaddy account. The hosting renews on their credit card. The "admin login" they were given is a junior role that can't install a plugin, let alone move the site.

Then the relationship changes — a disagreement, a missed email, a freelancer who simply stops answering — and the business discovers it doesn't own its own front door.

Nobody loses a business over a forgotten WordPress password. Businesses get hurt over a domain registered in someone else's name that nobody renews.

This post is the audit we wish every client had run before they needed us. It takes fifteen minutes, it's free, and it only works well while everyone is still on good terms.

"Your website" is 13 separate assets, not one thing

Most owners think of their website as a single thing they "bought." It's not. It's a bundle of separate accounts, registrations, and files — usually purchased from different companies at different times, often all set up by one developer who holds every login. Here's the full inventory. For each asset: where it lives, whose name should be on it, and the 30-second check that tells you where you stand.

Print that table, or copy it into a doc. Go down it row by row. Anything you can't verify in thirty seconds is a gap — and gaps are only cheap to fix while everyone's still friendly.

The 15-minute ownership audit (do it today)

You don't need the full table memorized. This short version catches 90% of problems.

1. WHOIS your domain. Go to lookup.icann.org and search your domain. Note the registrar, the registrant name and email, and the expiry date. If the registrant isn't your business, that's your single biggest risk — write it down. Set a calendar reminder 60 days before expiry regardless of whose name is on it.
2. Log into your registrar. Not "ask your developer to check" — log in yourself. Confirm the account is in your name, the contact email is one you actually read, auto-renew is on, and the payment card isn't expiring next month. A lapsed domain can be grabbed by squatters within days of expiring, and then you're negotiating to buy back your own name.
3. Log into your hosting. Find the billing page. If your developer's card pays for it and their email gets the renewal notices, you have a single point of failure wearing a friendly face. The fix is boring: open your own account with the same host, and have them migrate the site into it. An afternoon's work.
4. Check the email trap. Here's the one people miss: your business email — quotes@, info@, your own name@ — runs on your domain. If the domain lapses or gets held hostage, your email stops too. Not just the website. Every invoice thread, every client conversation. When people tell us a domain dispute "shut down the business for a week," this is usually what they mean.
5. List every admin user. In WordPress: Users → All Users. In Shopify: Settings → Users. Delete (or demote) anyone who shouldn't be there, and make sure at least one login is fully yours — an email you control, with a password manager entry, not a sticky note. Shared logins ("we all use admin2021") are a liability; every human gets their own account.
6. Find your backups. Where are they, how old is the newest one, and can you download it without asking anyone? A backup you can't reach is a rumor. For WordPress, a plugin like UpdraftPlus pushing to your own cloud storage is the minimum. Monthly at least; weekly if you take orders or publish often.

The audit is free and takes fifteen minutes. The recovery — when the domain is in someone else's name and they're not answering — starts with lawyers and ends with "we should have checked." Check now.

What "ownership" actually means on each platform

Here's where it gets uncomfortable: on some platforms, full ownership isn't even on the menu. What you "own" depends entirely on what your site was built with.

The honest take: builders like Wix and Shopify are good products — we build Shopify stores for clients. You're renting a furnished apartment: lovely to live in, but you can't take the walls with you. WordPress.org is buying the house. Neither is wrong; what's wrong is signing a lease thinking you bought the building.

The one contract clause that decides everything

Here's the row from the inventory table that deserves its own section, because it's the one with legal teeth.

Under US copyright law, work an independent contractor creates for you belongs to the contractor — not to you — unless a signed written agreement transfers it. Paying the invoice doesn't transfer it. A handshake doesn't transfer it. Only the contract does.

What to look for: the words "assign" or "assignment." A sentence like "Contractor assigns all right, title, and interest in the work to Client upon final payment" is what you want. What you don't want: the word "license." A license means they still own it and you're borrowing it — which is fine for stock photos and premium plugins, and not fine for the website you paid five figures for.

If your contract doesn't mention intellectual property at all, assume you don't own it yet — and get that fixed with a one-page IP assignment before you need it, not after.

Two caveats. First, I'm a developer, not a lawyer — for a high-stakes project, have an actual attorney glance at the clause; it's a cheap review. Second, this is US law; other countries differ, but the principle travels well: if ownership isn't in writing, you don't have it.

When it's fine for your developer to hold the keys

Now the counterpoint, because "never let your developer touch anything" would be dishonest — and bad advice.

There are legitimate setups where your developer or agency holds significant pieces. Managed hosting and care plans are the big one: plenty of good agencies host client sites on their own infrastructure and handle everything — updates, security, backups — for a monthly fee. That's a real service with real value, especially if you'd rather never think about PHP versions.

The difference between a good version of this and a hostage situation is paperwork, not trust:

• The domain is still in your name. This one is non-negotiable even in the coziest managed setup. No exceptions, no "it's easier if we hold it."
• There's a written exit clause. What exactly do you receive if you leave, in what format, within how many days? "Full backup and handover within 14 days" is a sentence that prevents 90% of disputes.
• You hold your own admin logins — WordPress admin, analytics, ad accounts — even if you never use them.
• You can download a full backup anytime without asking permission. Test this once. Actually click the button.
• Every human has their own account. No shared "admin" login that five people know.

The one-question test that settles it: "If we parted ways tomorrow, what would I need from you to keep everything running?" The right answer is "nothing — it's all in your accounts already, here's where." If the answer is a list, you're not in a partnership, you're in a dependency. Dependencies are fine when they're chosen deliberately and priced accordingly. They're poison when they're accidental.

5 questions to ask before you hire anyone

Ask these in the first conversation — before price, before timelines. The answers tell you more about a developer than their portfolio does.

1. "Will the domain be registered in my name, in my account?"
   The only acceptable answer is yes. If you already own a domain, they should ask for DNS access — never your registrar login.
2. "Whose name goes on the hosting account?"
   Yours. They get a collaborator login you can revoke. "We'll host it for you" is fine as a managed service (see above) — but then ask for the exit clause in writing.
3. "What exactly do I receive at handoff?"
   Listen for: full codebase, database export, design source files, every credential, DNS documentation. If the proposal describes deliverables only in visual terms — "five pages, contact form, blog" — with nothing technical, that's a gap.
4. "Does the contract assign the copyright to me on final payment?"
   Listen for the word "assign." If they look confused, that's information too.
5. "If we part ways, what do I need from you to keep the site running?"
   The right answer is "nothing." Anything else needs to be in the contract.

Red flags to watch for in the same conversation: "we'll take care of the domain and hosting" with no transfer plan; their name already on your domain registration; "we built it on our proprietary platform" with no export story; resistance to putting any of this in writing. A good developer hears these questions and relaxes — it means you won't blame them for an expired renewal in two years. The defensive reaction is the tell.

Realized something's already off?

Don't panic, and don't send an angry email. Start with the domain — check the expiry date at lookup.icann.org, because that date is your real deadline. Then put every request in writing, calmly: transfer the domain into your account, add you as an owner everywhere, deliver the handoff package.

Most of these situations resolve with paperwork and patience, not lawyers — which is exactly what our developer-disappeared recovery playbook walks through step by step, in order of urgency. Read the audit above first so you know what you're asking for; read that playbook if the asking isn't working.

And if you're staring at a half-built site with no access and no answers, that's literally what our rescue service exists for — taking over messy builds and getting them production-ready, keys included.

Own the building, not just the furniture

Your website is a business asset — as real as your lease or your bank account. Treat the accounts behind it with the same seriousness: your name, your email, your payment method, in writing.

Run the audit. Fifteen minutes, free, and best done while everyone's still friendly — which, if you're reading this far, is probably right now.

Not sure where you stand? Get a free roast of your site — we'll tell you plainly what's working and what isn't. Or book a call and we'll walk through the ownership checklist with you, no pitch attached. And if you need a team that builds in your accounts from day one, that's what our web development service does — the keys are yours before we write a line of code.