You used AI to build your website. Make sure you actually own it.

“Owning a website” sounds like one thing. It is at least six. You can own the name but not the files. You can have the files but no way to put them online. You can have all of it and still be unable to change a sentence without help. Each of these is a separate question, and each has a simple answer once you know where to look.

None of this requires you to understand code. It requires you to know which accounts exist, whose name is on them, and what would happen if any one of the tools you used disappeared tomorrow.

1. Own the domain

Your domain is the address people type: yourbusiness.com. It is not something you buy outright. You rent it, usually a year at a time, from a company called a registrar. Common ones are Cloudflare, Namecheap, GoDaddy, Google Domains (now Squarespace), and Porkbun.

The question is: whose account is the domain in?

If you bought it yourself, good. If a freelancer, an agency, or a website-building service bought it for you, it may be in their account, with their payment details, under their control. That works right up until the relationship ends, the card expires, or the company goes away. Then your address stops working and you may not be able to get it back.

What to do

• Find the registrar. Search for “whois” plus your domain name; the result usually names the registrar.
• Make sure you can log in to that registrar account, that it uses your email address, and that your payment method is on it.
• Turn on auto-renew, and turn on two-factor authentication. A stolen domain is a very bad day.
• If someone else holds it, ask them to transfer it to an account you control. This is routine and any registrar has instructions for it.

Some AI site builders give you a free address on their own domain, something like yourbusiness.theirtool.app. That is fine for a prototype. It is not something you own, and if you are putting it on business cards, register a real domain first.

2. Own the source code

A modern website is a folder of files. The files describe every page, every button, every colour. When an AI tool “builds your site“, what it actually produces is that folder. This is the thing most people are least sure they have.

The place those files usually live is GitHub. GitHub is a website where folders of code are stored, with a complete history of every change ever made to them. A stored folder is called a repository. Tools like Claude Code, Cursor, Codex, Lovable, v0, Bolt and Replit can all put your site’s files in a GitHub repository, and some do it automatically.

The question is: if the AI tool vanished tomorrow, could you still get the files?

If your site exists only inside a builder’s own workspace, the answer may be no. You can see it, but you can’t take it. If the files are in a GitHub repository under your own account, the answer is yes: you can download them, hand them to a different tool, or give them to a developer, whenever you like.

What to do

• Create a GitHub account of your own if you don’t have one. It is free.
• Find out where your site’s files are. Most AI tools have a “connect to GitHub” or “export” option. Use it, and make sure the repository is under your account, not the tool’s and not a contractor’s.
• Open the repository on GitHub and confirm it is not empty. You should see folders and files with names that vaguely match your site.
• Note whether the repository is public or private. For a business site, private is the normal choice.

You do not need to read the code. You need to be able to reach it. Think of it the way you think of the original files for your logo: you may never open them, but you would be in trouble without them.

3. Own the hosting account

GitHub stores the files. It is generally not the thing that runs them. Somebody has to turn that folder of files into a live website that answers when someone visits your address. That is hosting.

For sites built the way AI tools build them, the usual hosts are Vercel, Netlify and Cloudflare. Some builders host the site themselves; Lovable, Replit and Bolt each have their own hosting, for instance. Either way, there is an account somewhere with your site’s deployment in it.

The question is: whose account is the site running in, and what is it connected to?

In a healthy setup, your hosting account is connected to your GitHub repository. When the files change, the host notices and publishes the new version. This is called a deployment pipeline, and it is what makes “save a change, it goes live” possible. If instead someone uploads files by hand from their own computer, you are dependent on that person and that computer.

What to do

• Find out where the site is hosted. If you don’t know, the person or tool that set it up does.
• Make sure the hosting account is yours, or that you are an owner on it, not a guest.
• Check that the hosting is connected to your GitHub repository, so that you are not dependent on any one person’s laptop.
• Know what it costs and what card it bills. Free tiers are common and fine for small sites, but they are attached to someone’s account.

4. Own the connection between them

The domain and the hosting are joined by a set of records called DNS. They tell the internet “when someone types this address, send them to that server“. DNS is usually managed at the registrar, but it can be moved elsewhere, and often is.

This is the part people forget, because it is invisible when it works. It matters because if DNS is managed in an account you don’t control, someone else can point your domain at a different site, or nowhere at all, without touching anything else you own.

What to do

• Log in to your registrar and look for “DNS” or “nameservers”. If it says the domain uses the registrar’s own nameservers, DNS is managed there. If it names another company, log in there too.
• If DNS is managed by a person or tool you don’t control, ask for it to be moved to your account.
• Take a screenshot of the DNS records as they are today. If anything ever breaks, that screenshot is how someone fixes it in ten minutes instead of a day.

5. Own the accounts your site depends on

A site that does anything at all leans on other services. Common ones:

• Email sending, for contact forms and notifications: Resend, SendGrid, Postmark, Mailgun.
• Forms: Formspree, Tally, Typeform, or the host’s own form handling.
• Analytics: Google Analytics, Plausible, Fathom, Mixpanel.
• Payments: Stripe, Lemon Squeezy, Paddle.
• Bookings, chat, maps, newsletters, and whatever else your site embeds.
• AI features, if your site calls a model to do something: an account with Anthropic, OpenAI or similar, with a key that is being billed.

Each of these is an account, and each account has an owner and a card on file. When an AI tool sets these up for you, it often does so under whatever account was convenient at the time. That is a quiet source of surprise months later, when a form stops sending because a key expired on an account nobody remembers.

What to do

• Make a list. Every service, the email it is registered to, who pays, and what would stop working if it lapsed.
• Move anything important to an account you own. Most services make it easy to add you as an owner, or to create a new key under your own account.
• Keep the list somewhere you will find it. A note in your password manager is ideal.

6. Own the ability to change it

This is the one people don’t think of as ownership, and it is the one that decides whether the site actually works for you.

If every change to your website, however small, has to go through the tool that built it, then in practice the tool owns your site’s day-to-day. You notice a typo. You open the AI tool, find the right project, explain which sentence, wait, check, and maybe go round again because the new wording wraps onto a third line. For a new feature that is a fair trade. For three words, it is not.

There are two honest answers. One is to accept it: most sites change rarely, and if yours is one of them, going back to the agent now and then is fine. The other is to make sure the routine changes, the words on the page, can be made directly by a person, on the real page, without a prompt. That is what Refino is for, and it is the reason we wrote this guide. It only makes sense on a site you own in the ways above. It adds nothing to a site that lives inside somebody else’s builder.

Whatever you choose, the principle holds: your coding agent should be a tool you use, not a gate you have to pass through to touch your own website.

The checklist

If you can honestly tick every box, you own your site. If you can’t, you now know which conversation to have.

Common questions

Do I need to learn to code to do any of this?

No. Everything above is about accounts: where they are, whose name is on them, what card they bill. You never have to read a line of code. If a step involves a setting you can’t find, the service’s support pages will have it, and so will your AI tool if you ask it plainly.

My AI builder says it hosts the site for me. Is that bad?

It is convenient, and for a prototype it is the right call. For a site your business depends on, it is worth knowing whether you can also export the code to GitHub and, if you had to, host it somewhere else. Most builders allow this. If yours doesn’t, that is a fact to know rather than a reason to panic.

What is the single most important step?

The domain. Everything else can be rebuilt, restored or re-exported. A domain that has expired and been bought by someone else is very hard to get back, and it is the one thing your customers actually know.

Where does Refino fit?

Step six, and only there. Refino is added to a site you already own: your code, on your hosting, with your domain. It gives you a way to change the words on the page directly. It does not host, rebuild or store your site. Here is how it works.