Five things you should control, even if a developer runs your website. Not run. Control. "Dave knows how it works" isn't a plan. Dave's allowed to go on vacation.
This guide gives you the five and how to check you can really get into each one. Plus where the logins go (not on the list), and one simple test. I'm not saying you should manage servers all afternoon. Please don't. Hire good people for that. Just make sure the business holds the keys.
The five, in plain words
| Item | In plain words | You're good when |
|---|---|---|
| 1 · Domain | Your website's address, the name people type, like example.com. You rent it from a company called a registrar. | The registrar account is in the business's name, renewal emails go to a business inbox, and you can log in yourself. |
| 2 · Hosting | Where the website actually lives: the company whose computers serve it. | The account is the business's, it's on the business card, and your developer is a user on it, not the only way in. |
| 3 · Customer data | Your leads, form fills and customer list, wherever they land. | You can export it yourself and open the file. |
| 4 · Backups | Saved copies of the site and its data, so you can go back if something breaks. | You know where they are and how often they run, and a restore has been tested. |
| 5 · Code + instructions | The files that make the site, plus written steps for how it all works. | The code lives in an account the business owns, with instructions a new developer can follow. |
On a website builder, where you edit pages in a browser and never see code? Then number five is the builder account itself, plus the instructions. Same rules.
Check each one
Do this yourself, logged in as you. "We have that, right?" doesn't count. Your developer can sit next to you. That's the friendly version.
Domain: look it up, then log in
Wherelookup.icann.org (ICANN Lookup)Type your domain into ICANN Lookup. It shows the registrar (the company you rent the domain from), the expiration date, and the nameservers. Nameservers show where your DNS is managed. DNS is the address book that points your domain at your website and email. The contact details are often hidden for privacy. That's normal.
If the nameservers belong to a different company than the registrar, that's one more login to find. Put it on the list under Domain.
Now log in to the registrar yourself and check:
- The account is in the business's name.
- The contact email is a business inbox somebody reads. ICANN says registrars must send at least two renewal reminders before a domain expires: about a month before, and about a week before. They go to the registrant's email (the registrant is whoever the domain is registered to). If that's an old address, nobody sees them.
- Auto-renew is on, and the card on file hasn't expired.
Hosting: whose account is it?
Log in to the hosting account. Find the account owner and the billing page. The account and the card should be the business's. Your developer should be on it too, as an admin or team member, with their own login.
If the whole site sits in your developer's personal account, ask to move it into a business account, or to make the business an owner. Your host's help pages or support can tell you how.
Customer data: export it yourself
List every place leads and customers land: your customer system (a CRM, the app that keeps your customer list), the website form, the booking tool, the email list. For each one, find the export button and download the file yourself. Open it. Is everyone there, with names, phones and notes? If only your developer can pull it, that's a gap.
Backups: ask four questions, then test one
Ask: Where are the backups? How often do they run? Is there a copy somewhere other than the host? Who can restore one?
Then test it. Have your developer restore one backup to a test copy of the site, not the live one. A backup nobody has ever restored is a hope, not a plan.
Code: where it lives, and the instructions
Code usually lives in a repository: an online folder that keeps every version of every file, on a service like GitHub. It should sit in an account the business owns, with your developer added as a member. On GitHub that's an organization. Its owners have complete admin access, and GitHub says to keep the owner role small, but no fewer than two people.
Code in your developer's personal account today? On GitHub, someone with admin access can transfer a repository to the business's organization, and its issues, pull requests and wiki move with it.
Then the instructions. GitHub says a README (the instruction page in a repository) usually covers what the project does, how to get started, where to get help, and who maintains it. For a business website, ask for these too:
- What the site is built with, in one line.
- How to make a change and publish it.
- Where the backups are, and how to restore one.
- What connects to what: the forms, the customer system, the email.
- Where the logins live: the vault's name, never the passwords.
Logins: somewhere safe, not on the list
The one-page list says where things are and who controls them. It never holds a password. Logins go in a password manager: an app that makes, stores and fills in passwords. CISA, the US government's cybersecurity agency, recommends one, and says not to save passwords in a file on your computer. Use a shared business vault, so the logins belong to the business, not to one person's phone.
Two more things people miss:
- Two-step codes. Turn on multifactor authentication (MFA): after your password, you enter a code from a text or an authenticator app. Then check where those codes go. If they only go to your developer's phone, you can't get in without your developer. Send them to a phone or app the business controls.
- Recovery codes. If a site gives you backup or recovery codes when you turn on MFA, save them in the password manager too.
The test: could someone new fix one broken form today?
Say your developer's out for a month. Could you let someone new in to fix one broken form, today? Find out while everybody's still friendly:
Pick a stand-in
A teammate, or a second email address of yours. They play the new developer.
Invite them to each account
From your own login, add them to the hosting, the code, the customer system and, if it allows more than one user, the registrar. Give them the access a new developer would need. If you can't add someone to an account, you don't control it yet. Write that down.
Have them find the form
Using only the README and their own login, can they find where the contact form is built and where its leads go? They don't have to fix anything. Finding it is the test.
Remove them and write the date
Take their access away again. Put today's date on the list. Run it again once a year, and any time a developer or agency changes.
Copy this: the one-page list
Print it or paste it into a shared doc. For who controls each one, use job titles, not names. Logins go in the password manager, never here.
WEBSITE CONTROL LIST
Business: ______________________
Updated: _________
1. DOMAIN
Registrar: _____________________
In whose name: _________________
Renewal emails go to: __________
Renews on: ________ Auto-renew [ ]
DNS managed at: ________________
2. HOSTING
Host: __________________________
Account in whose name: _________
Paid with business card: [ ]
Developer has own login: [ ]
3. CUSTOMER DATA
Where it lands: ________________
I exported it myself: [ ]
4. BACKUPS
Where: _________________________
How often: _____________________
Restore tested on: _____________
5. CODE + INSTRUCTIONS
Lives in: ______________________
Business is an owner: [ ]
README says how to publish
and restore: [ ]
WHO CONTROLS EACH (job titles)
Main admin: ____________________
Backup admin: __________________
Developer access: ______________
LOGINS: in the password manager
Vault name: ____________________
Two-step codes go to: __________
NO PASSWORDS ON THIS PAGE.
Handoff test done on: __________Do it with Claude or ChatGPT
Paste this into Claude or ChatGPT. It interviews you one question at a time, fills in the list, and drafts a friendly note to your developer. It should never ask for a password. If it does, don't answer.
Help me make a one-page list of who controls my website. A developer runs the site, and that's fine. I just want to be sure the business controls the five things that matter.
RULES
- Never ask me for a password, a code or a login. If I paste one by accident, tell me to change it.
- Ask me one question at a time. Use plain words. Explain any tech word in a few words.
- If I don't know an answer, tell me exactly where to look or who to ask.
THE FIVE
1. Domain: the website's address. Who is the registrar? Whose name and email are on it? When does it renew? Where is the DNS managed?
2. Hosting: where the site lives. Whose account is it? Whose card pays for it? Does my developer have their own login?
3. Customer data: where leads and customers land. Can I export it myself?
4. Backups: where are they, how often do they run, and who can restore one? Has a restore been tested?
5. Code and instructions: where does the code live? Is the business an owner of that account? Is there a written README?
For each one, also ask: where do the two-step login codes go?
WHEN WE'RE DONE, give me:
a) The one-page list: item, where it lives, in whose name, who controls it (job titles only), last tested. No passwords.
b) The gaps, worst first, each with one next step.
c) A short, friendly message I can send my developer. Ask for help closing the gaps and for a date to test it together. Make it clear nothing is wrong. We're doing this while everyone's on good terms.Example (made up)
Pine Street Plumbing has a developer who built the site and still runs it. The office manager fills in the list with the developer on a call. Here's what they find:
| Item | What they found | The fix |
|---|---|---|
| Domain | In the business's name, but renewal emails go to the developer's old address. | Contact email changed to the office inbox. Auto-renew on. |
| Hosting | In the developer's personal account. The business can't log in. | The developer opened a business account, moved the site, and stayed on as an admin. |
| Customer data | Form leads land in the customer system. The office can export them. | Nothing to fix. Exported once to prove it. |
| Backups | They run on a schedule, but nobody had ever tried a restore. | The developer restored one to a test copy. It worked. Date written down. |
| Code | In the developer's own account, with no README. | Moved into a business organization with two owners. The developer wrote a one-page README. |
Then the test. The office manager invites a second email address to each account, opens the README, and finds where the contact form lives. She removes the test login and writes the date on the list.
The developer's still on the job. The difference: now the developer can take a vacation without taking the website along.
Mistakes to avoid
Putting passwords on the list
Asking instead of checking
Two-step codes on one person's phone
Waiting until someone leaves
Making it about blame
That's the list
If "we own it" still means tracking down the one guy who remembers the login, we're not done. Five lines, one page, one test. Then we're done.
Checked on Oct 4, 2026 against
Every claim about a third-party tool in this guide (plans, prices, menu paths, commands, limits) was checked against these official pages on Oct 4, 2026. These screens change often: if something looks different, trust the page over this guide.
- ICANN: Registration data lookup toolLooks up a domain's current registration data (RDAP, the replacement for WHOIS): the registrar, expiration dates, nameservers and contacts, with personal details often redacted for privacy.
- ICANN: Information for registrantsA registrant is the person or organization who registers a domain name; ICANN Lookup finds your registrar.
- ICANN: Expired Registration Recovery Policy, 5 things to knowRegistrars must send at least two renewal reminders, about one month and about one week before expiration, to the registrant email on file, so that contact must be current.
- GitHub Docs: Roles in an organizationOrganization owners have complete administrative access; the owner role should be limited, but to no less than two people.
- GitHub Docs: Transferring a repositoryTransferring needs admin access to the repository; a repository can go to another account or an organization; its issues, pull requests, wiki, stars and watchers transfer too.
- GitHub Docs: About READMEsA README typically covers what the project does, why it's useful, how to get started, where to get help, and who maintains it.
- CISA: Use strong passwordsUse a password manager, a program that generates, stores and fills in passwords, rather than saving passwords in a file on your computer.
- CISA: Turn on MFAMultifactor authentication adds a second step at login, such as a code by text or from an authenticator app, so a stolen password alone isn't enough.
- Search Console Help: Owners, users, and permissionsOwners can add and remove users; if all verified owners are removed, remaining users and delegated owners lose access after a grace period.
- Analytics Help: Add, edit, and delete usersAdding or modifying users needs the Administrator role at the account or property level.
