Tutorial guide

Five things you should control, even with a developer

Domain, hosting, customer data, backups and code. Check the business can get into each one, make a one-page list, and test it.

Swipe or tap Next · checked on 2026-10-04

At a glance

You needYour own logins, a password manager, and your developer on a good day

You'll end withA one-page list: the five, who controls each, and the day you tested it

Not on the listPasswords. Those go in a password manager.

Part 1 of 8

The five, in plain words

1 · Domain

In plain wordsYour website's address, the name people type, like example.com. You rent it from a company called a registrar.

You're good whenThe registrar account is in the business's name, renewal emails go to a business inbox, and you can log in yourself.

The five, in plain words

2 · Hosting

In plain wordsWhere the website actually lives: the company whose computers serve it.

You're good whenThe account is the business's, it's on the business card, and your developer is a user on it, not the only way in.

The five, in plain words

3 · Customer data

In plain wordsYour leads, form fills and customer list, wherever they land.

You're good whenYou can export it yourself and open the file.

The five, in plain words

4 · Backups

In plain wordsSaved copies of the site and its data, so you can go back if something breaks.

You're good whenYou know where they are and how often they run, and a restore has been tested.

The five, in plain words

5 · Code + instructions

In plain wordsThe files that make the site, plus written steps for how it all works.

You're good whenThe 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.

Part 2 of 8

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.

Check each one · step 1 of 5

Domain: look it up, then log in

Where: lookup.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.

Check each one · step 1 of 5

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.

Check each one · step 1 of 5

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.

Check each one · step 1 of 5

Auto-renew is on, and the card on file hasn't expired.

Check each one · step 2 of 5

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.

Check each one · step 2 of 5

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.

Check each one · step 3 of 5

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.

Check each one · step 4 of 5

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.

Check each one · step 5 of 5

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.

Check each one · step 5 of 5

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:

Check each one · step 5 of 5

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.

Check each one

Two more worth checking while you're in there

Google Search Console (where Google shows how your site does in search): the business should be an owner. Owners can add and remove users. Google warns that if every verified owner is removed, everyone else loses access after a grace period.

Google Analytics (your site's traffic): someone at the business should have the Administrator role. Google requires that role to add or change users.

Part 3 of 8

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.

Logins: somewhere safe, not on the list

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.

Logins: somewhere safe, not on the list

Recovery codes. If a site gives you backup or recovery codes when you turn on MFA, save them in the password manager too.

No passwords on the list

Not in the doc, not in an email, not on a sticky note on the monitor. The list says where. The password manager holds the rest.

Part 4 of 8

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:

The test: could someone new fix one broken form today? · step 1 of 4

Pick a stand-in

A teammate, or a second email address of yours. They play the new developer.

The test: could someone new fix one broken form today? · step 2 of 4

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.

The test: could someone new fix one broken form today? · step 3 of 4

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.

The test: could someone new fix one broken form today? · step 4 of 4

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.

Part 5 of 8

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.

Copy this: the one-page list

One-page control list · lines 1-15 of 43. Copy all copies the whole file; read it in full on the page.

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:  [ ]

Part 6 of 8

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.

Do it with Claude or ChatGPT

The control-list prompt · lines 1-1 of 20. Copy all copies the whole prompt; read it in full on the page.

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.

Part 7 of 8

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:

Domain

What they foundIn the business's name, but renewal emails go to the developer's old address.

The fixContact email changed to the office inbox. Auto-renew on.

Example (made up)

Hosting

What they foundIn the developer's personal account. The business can't log in.

The fixThe developer opened a business account, moved the site, and stayed on as an admin.

Example (made up)

Customer data

What they foundForm leads land in the customer system. The office can export them.

The fixNothing to fix. Exported once to prove it.

Backups

What they foundThey run on a schedule, but nobody had ever tried a restore.

The fixThe developer restored one to a test copy. It worked. Date written down.

Example (made up)

Code

What they foundIn the developer's own account, with no README.

The fixMoved 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.

Example (made up)

The developer's still on the job. The difference: now the developer can take a vacation without taking the website along.

Part 8 of 8

Mistakes to avoid

Putting passwords on the list

The list is meant to be shared. Passwords go in the password manager. The list only says where.

Asking instead of checking

"Yeah, you own it" isn't the same as you logging in. Log in yourself.

Mistakes to avoid

Two-step codes on one person's phone

You can have the password and still be locked out. Send the codes to a phone or app the business controls.

Waiting until someone leaves

Ask while everybody's friendly. It's an easy favor today and a hard one later.

Mistakes to avoid

Making it about blame

A site in your developer's account doesn't mean anyone did anything wrong. Fix the setup and keep the developer.

Checked on 2026-10-04 against · 1 of 2

The official docs behind every claim

Checked on 2026-10-04 against · 2 of 2

Analytics Help: Add, edit, and delete users

What each page backs up is listed at the end of the full guide.

The end

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.

Want help setting this up? Receipts Group builds these systems.

Open the full guide as a page (every file in full, plus the table of contents).