The Website Ownership Checklist: What a Small Business Should Actually Hold

Here is the short version of the website ownership checklist: you should personally hold eleven things, and if you hold them, you can fire anyone, move anywhere, and rebuild from scratch without asking permission. Owners usually ask us what should I own on my website after something goes wrong, when a developer stops replying or a renewal notice arrives from a company they have never heard of. It is a much easier conversation to have on a calm Tuesday than in a panic.

None of this requires you to be technical. It requires you to know which accounts exist, whose name and email are on each one, and where the credentials live. That is a filing problem, not an engineering problem.

The website ownership checklist at a glance

Work down this table one row at a time. For each item, the question is not "can I get to it" but "is the account in my company's name, billed to my card, tied to an email address I control?" Those are different questions and the gap between them is where small businesses get stuck.

The four that actually keep you safe

If you only ever fix four rows, fix these. The rest are recoverable inconveniences.

1. The domain registrar account

This is the deed. The registrar is the company where your domain name is registered and renewed, and whoever controls that account controls where your website and email point. A public WHOIS or RDAP lookup will tell you which registrar holds it, along with the creation and expiry dates. Most registrant contact details are redacted in the public record now, so the lookup usually confirms the registrar rather than the person, which is still the fact you need.

Two follow-ups once you know the registrar. Log in and check the account email. And check whether auto-renew is on, because an expired domain takes your email down with it. We wrote a full timeline of that in what happens if your domain name expires.

2. Business email admin

Email is the master key, because almost every other account resets its password by sending a link to an inbox. If your web developer set up Google Workspace or Microsoft 365 for you and kept the admin console, they can read, create, or remove any mailbox at your company. Being able to send and receive mail is not the same as being the administrator.

Two checks. Open the admin console for your provider and see if you can add a user. And make sure the accounts on this whole checklist are registered to a company address like owner@yourdomain.com rather than a personal Gmail or, worse, an address at your agency's domain.

3. Hosting, plus a copy of the site off the server

You want the host login itself, not a white-labeled panel your developer built on top of it. Ask which company the hosting is actually with and log in there directly. Then get a backup you can hold: the files and the database, downloaded and dated, sitting in your own cloud storage.

One caveat worth knowing on WordPress. The built-in export tool under Tools produces an XML file of your posts, pages and comments, but it is not a full backup. It leaves out your theme files, your plugins, your uploaded media library files and your settings. A real backup is the whole file directory plus a database dump, which is what a host's backup tool or a backup plugin produces.

4. Verified ownership of Search Console and analytics

Google Search Console distinguishes between a verified owner, who proved control of the site itself through a DNS record, an HTML file or a tag, and a delegated owner or user, who was simply invited by someone else. A delegated owner's access can be revoked by whoever invited them. Verify the property in your own right, using the DNS method if you can, so nobody can lock you out of your own search data.

Analytics is the one asset on this list that genuinely cannot be recreated. Traffic history does not backfill. If your developer created the property under their own account, get admin rights at the account level, not just the property level, before you part ways.

The rows people forget

These are the ones that surface months later, usually at an awkward moment.

• Fonts. Web fonts are licensed by page views or by domain. If a designer used a licensed typeface on a personal license, the license does not follow the site to you. Ask for the license document.
• Stock photography. Same story. Standard stock licenses are usually granted to the buyer, and that buyer may be your agency. If the images are on your site and the license is in someone else's name, you have exposure you did not know about.
• Premium plugins and themes. Most sell an annual license key that turns on updates and support. When the key expires or the developer's bundled license stops covering you, your plugins quietly stop updating, which is how sites get hacked. Ask which paid extensions are running and whose account each key sits in.
• The SSL certificate. Many hosts issue and renew these automatically at no cost, which is fine. Problems come when a developer bought a paid certificate on their own account. Know which situation you are in.
• Your Google Business Profile. For a plumber or a dentist this listing usually brings in more calls than the website. Sign in and confirm your account is the primary owner. If someone else claimed it, Google has a Request Access process: it emails the current owner, who gets 3 days to respond before you can move to claiming it yourself.

Where to keep all of it

The list is only useful if you can find it in eighteen months. Three rules that hold up.

1. 1One password manager, one shared vault. Not a spreadsheet, not a note on your phone, not a thread in your inbox. A manager lets you share a credential with a developer and revoke it later without changing every password.
2. 2Company email addresses on every account. Set a role address you keep forever, like accounts@yourdomain.com, and use it as the login and recovery email everywhere. When staff change, the accounts do not.
3. 3One document listing the eleven items. Asset, provider, login email, who else has access, and the renewal date. Update it whenever you hire or fire anyone. This is the single page a new developer needs on day one, and it turns a two-week handover into an afternoon.

If you go through the list and come up short

Start with what is public. A free built-with scan reads your site's own fingerprint and reports the platform, plugins, hosting company, nameservers and registrar, which fills in half the table without a single password. Our guide on how to find out who manages your website hosting walks through reading those results, and how to find out who built your website covers tracing the person behind the build when the paperwork is long gone.

If the trail leads to a developer who has gone quiet, do not start changing passwords yet. Read what to do when your web developer disappears first, because the order you do things in matters.

And if you would rather hand the whole filing job to someone: we take over sites we did not build. That is a normal part of our website maintenance work, and the first thing we do on a takeover is exactly this audit, documented back to you in your own accounts, in your own name. If your hosting is also a mystery, our managed hosting includes moving the site off whatever it is on now. We have been doing this from Mill Creek, north of Seattle, since 2011, for local clients and remote ones. Either way, you should end up owning your own website, whether we are the ones holding the wrench or not.