Does Your Old Web Guy Actually Own Your Domain? Here's How to Check (and Take It Back)

Here's a scenario I see enough that every owner should check it before they need to switch vendors. An owner wants to leave their current web guy. The relationship has soured, the site is slow, the monthly fee feels like a tax. They find someone new, get a proposal, and tell the new agency they're ready to switch. The new agency asks for the domain login. The owner doesn't have it. They email the old web guy. The old web guy stops returning emails. Two weeks later it turns out the domain is registered in the web guy's personal GoDaddy account, the site lives on the web guy's WordPress install, and getting any of it back is going to require a legal letter or a fresh domain entirely.

This isn't malice in most cases. It's sloppiness. The web guy may have set everything up under his own login because it was easier. Years later, that shortcut gives him control you should have had from day one. But the result for the owner is the same as if it were a deliberate hostage situation. Your front door, your address, your search history, your customer pipeline. None of it is actually yours.

The good news: you can find out where you stand in about ten minutes, without a phone call to anyone. The bad news: a lot of owners discover the answer is worse than they thought. This post walks you through the audit and what to do if any of it comes back wrong.

What "ownership" actually means

There are four things a web vendor might be holding for you, separately or together. They're not the same and they get conflated all the time:

1. The domain name registration. The actual yourbusiness.com registration record at a registrar like GoDaddy, Namecheap, Google Domains (now Squarespace Domains), or Cloudflare.
2. The DNS settings. The records that tell the internet where to send traffic when someone types your URL. Sometimes managed at the registrar, sometimes at a separate DNS host like Cloudflare.
3. The hosting account. Where the actual site files or platform account lives. Wix, Squarespace, WordPress.com, a managed WordPress host like WP Engine, or a modern host like Vercel or Netlify.
4. The code, content, and CMS access. Either administrator credentials inside the CMS, a copy of the source files, or both.

Real ownership means all four are in your name, on accounts you can log into, with credentials only you control. Partial ownership is the trap. Owning the domain but not the code means you can take your URL elsewhere but you're rebuilding from scratch. Owning the code but not the domain means you can move the site but you lose every link, every search ranking, every business card you've ever printed.

The ten-minute audit

Here's the sequence. Run through it tonight. You'll know exactly where you stand before tomorrow morning.

Step 1: Look up your domain's public record

Go to whois.com and type your domain in. The public WHOIS record will show one of three things:

• Your business name and address as the registrant. Good sign. Your domain is registered to you.
• A privacy-protected record with the registrar's name (like "Domains By Proxy" for GoDaddy or "Withheld for Privacy" for Namecheap). This is normal and doesn't tell you who actually owns the registration. You need to log into the account itself to confirm.
• Your web guy's name or company. This is the problem case. Your domain isn't yours. Even with privacy protection, an old WHOIS record will sometimes leak the original registrant before privacy was added.

If you don't already know which registrar holds your domain, the WHOIS record will tell you that too. Look for the "Registrar" line. That's where you need to be able to log in.

Step 2: Log into the registrar

Try to log in to the registrar with your own email and a password reset. If you can recover the account using an email address you own, you control the registration. If the recovery email goes to your web guy's address, you don't.

If you can't recover the account at all, that's the worst case. The domain is locked behind credentials only the other party has. You may be able to initiate an account-recovery process with the registrar if you can prove you own the business (EIN, business license, matching billing address), but it's slow and not guaranteed.

Step 3: Find your DNS host

While you're in the registrar account, look at the "Nameservers" setting for your domain. If they point to the registrar's own nameservers (something like ns1.godaddy.com), the registrar is handling DNS. If they point somewhere else (something like dns1.cloudflare.com or ns1.vercel-dns.com), DNS is being handled elsewhere and you'll need access there too.

Most small-business sites have DNS at the registrar. A site using Cloudflare for performance reasons will usually have DNS at Cloudflare. Either way, you want the password to that account.

Step 4: Find your hosting

This depends on what your site is built on. A few patterns to check:

• Wix, Squarespace, GoDaddy Website Builder. Log in to your account on that platform directly. The site is hosted there. Confirm the account is in your name and you have admin access, not just contributor access.
• WordPress. Try to log in at yourdomain.com/wp-admin. If you get the dashboard, look at "Users" and confirm you're listed as Administrator. If you're an "Editor" or "Author," you don't actually control the site. Also check who's hosting WordPress itself, which is usually a separate account at WP Engine, Bluehost, SiteGround, or similar.
• Custom build (Next.js, Astro, anything modern). Hosting will usually be Vercel, Netlify, or Cloudflare Pages. The deployment account should be yours. The source code should be in a GitHub or GitLab repository that you own.

If you can't identify who hosts your site, run your domain through BuiltWith.com. It'll tell you what platform and host the site is on. From there, work backward to figure out whose account it's in.

Step 5: Check CMS and source-code access

Beyond hosting, you want either administrator access inside the CMS (so you can edit content) or a copy of the actual source code (so you can move it elsewhere).

For platform sites (Wix, Squarespace), admin access is the bar. You should be able to log in, change anything, add a user, remove a user, export content.

For WordPress sites, you want Administrator role and ideally a recent backup file (.zip or .sql) you've downloaded yourself.

For custom builds, you want access to the GitHub or GitLab repository where the source code lives. The repo should be owned by your business account, not a personal account belonging to the developer.

What to do if any of it isn't yours

Different problems, different fixes. None of them are impossible, but some take patience.

If the domain isn't yours

Email your web guy with a clear, polite, written request: "I'd like to transfer the registration of yourbusiness.com into my name. Please initiate the transfer to [your registrar account] and provide the auth code." Give a deadline of two weeks. Keep the email professional. You may need it later.

If he refuses or ghosts you, the next step depends on jurisdiction, but most cases come down to one of two paths. Path one: ask a domain attorney whether an ICANN UDRP complaint fits your situation. UDRP is for trademark-based domain disputes, and it may or may not apply when a vendor registered the domain during a business relationship. You can read the basics on ICANN's UDRP page. Path two: hire a lawyer to send a demand letter referencing the business relationship and the implied ownership of the trade name. Both can take time and money, and neither is guaranteed. Sometimes the cheaper move is to register a slightly different domain (yourbusinessllc.com, gotoyourbusiness.com) and start fresh, then redirect once you regain the original.

If the hosting isn't yours but the domain is

Easier case. Build the new site somewhere you control, then change the DNS records at your registrar to point at the new host. The old site goes dark, the new one comes online. You may lose any unbacked-up content from the old site, so download what you can first.

If the CMS access isn't yours

If you have administrator-level credentials inside the CMS (Wix, Squarespace, WordPress), you can usually export your content and rebuild elsewhere. If you have contributor or editor access only, you'll need either an upgrade in permissions from the account owner, or a manual rebuild based on the visible content you can copy off the public site.

How to lock this down going forward

The fix is structural. Once you've done the audit and consolidated whatever you needed to consolidate, set things up so this never happens again:

1. Register the domain yourself. In your name, on an account that uses your business email, with two-factor authentication enabled. Pay the renewal yourself, not through a vendor.
2. Set the renewal to auto-renew for the maximum allowed length. Five or ten years out, depending on the registrar. Domain expirations are how a lot of businesses accidentally lose their URL to a squatter.
3. Use your business email as the registrant contact. Not a personal Gmail. Not your web guy's email. Something tied to the domain itself or to a permanent business inbox.
4. Whatever agency you hire next, add them as a delegated user, not as the account owner. They can do the work, but you can revoke their access at any time.
5. Keep a single document with credentials. Domain registrar, DNS host, hosting account, CMS admin, GitHub repo if there is one. Store it in a password manager you control.

Frequently asked questions

What if my web guy says he can't transfer the domain because of technical reasons?

Sometimes there is a real transfer lock or waiting period. But if he will not name the specific blocker, treat that as a red flag. Domain transfers between registrars are a standard, well-documented process. The current registrar provides an authorization code, the new registrar uses it to initiate the transfer, the original registrant approves it, the transfer completes in five to seven days. If your web guy says it's complicated, ask him to explain specifically what's blocking it. If he cannot name the blocker, the issue may not be technical.

I don't even know who registered my domain. What now?

Start with WHOIS at whois.com. The Registrar line will tell you which company holds the registration. From there, try to log in to that company's website with every email address that could plausibly be associated with the account. Initiate password resets. If you find the account, great. If you don't, contact the registrar's support directly, explain the situation, and ask about their lost-access recovery process. Ask what documents they need to prove business ownership.

Can I avoid all of this by hiring a big agency instead of a freelancer?

Size doesn't determine behavior here. Big agencies sometimes lock clients in worse than freelancers do, because the lock-in is a deliberate business model rather than accidental sloppiness. The protection is the contract and the account ownership structure, not the size of the vendor. Ask the nine questions in our agency pre-signing checklist before you sign with anyone.

How long should I expect to keep my domain?

Forever, if you can. Your domain is a permanent asset. The cost is usually low compared with replacing the domain. Check your registrar's current renewal price before you assume anything. Even if you change businesses, agencies, platforms, branding, or markets, the domain itself can travel with you. Treat it like a permanent piece of business infrastructure, not like a subscription you can cancel.

Your domain is your business's permanent address on the internet. Spend the ten minutes tonight to confirm you actually own it. If you find out you don't, today is a better day to deal with it than the day you decide to fire your current vendor and can't.