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.

Don’t know what you have? Start with the diagnostic: Where is my website hosted?

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. For a finer-grained version that scores each layer, take the portability test.

Want the practical version?

This page is the overview. Each of the questions above has a step-by-step guide behind it, written for the owner of the site rather than a developer, and checked against the current rules and documentation of the services involved.

1. Where is my website hosted?A step-by-step diagnostic for finding out who hosts your website, where its code is, whether there’s a GitHub repository, and who controls each account, starting with nothing but your domain name.
2. How to register a domain you actually ownHow to register a domain so that you, not a developer, agency or website builder, control it: whose account it should be, the settings to turn on the same day, how to give a developer access without giving away the domain, and what to save.
3. GitHub for website owners who aren’t developersGitHub explained for people who own a website but don’t write code: what a repository is, why your site’s files should be in one under your account, and what to check so you could take them elsewhere.
4. GitHub is not your web hostGitHub stores the code for your website. A host such as Cloudflare, Vercel or Netlify serves it to visitors. DNS connects your domain to the host. Why these are separate, and who should control each one.
5. How to put your website’s code in GitHubHow to get the actual source code of your website into a GitHub repository you control, whether it’s already on GitHub under someone else’s account, only on a developer’s computer, or inside an AI or site-building platform. With a verification checklist.
6. Environment variables and secrets for website ownersWhy a site whose code you own can still fail to run anywhere else: the settings and secrets the host holds outside the code. What they are, where they live, how to inventory them, which are safe to see and which must be rotated, and how to recreate them on another host.
7. Where your website’s data livesOwning the repository is not the same as owning the website. The database, uploaded files, user accounts, form submissions, CMS content and analytics each live in a service with its own owner. How to find every one, work out whose account it’s in, check whether the data can be exported, and record what would have to move.
8. How to change DNS without breaking your website or emailA cautious procedure for changing DNS records or nameservers: capture what exists first, work out which records support the website and which support email and other services, change the least you can, and verify everything afterwards.
9. How to move your website to a new host without downtimeThe sequence for moving a website between hosts while it stays online: inventory the current setup, build and verify on the new host’s own address first, reproduce the configuration, lower TTLs, change only the website records, watch HTTPS, keep email working, and keep a way back.
10. How to transfer a domain to an account you controlA safe procedure for moving a domain into a registrar account you control: work out whether you need a transfer at all, preserve the current DNS, unlock, get the authorization code, approve, and verify that the website and email still work.
11. How to give a developer or coding agent access without sharing your passwordsThe order of preference for letting someone work on your site: their own account with the smallest role that does the job, then a scoped token, and a shared password only when nothing else exists. Covers the domain and DNS, GitHub, hosting, databases and services, and AI coding tools, and what to revoke when the work ends.
12. How to take your website with you when you leave an AI builderLeaving an AI website builder means more than downloading the code. An inventory of everything a site depends on, from the domain to the database to the secrets, and a structured checklist for moving it all.
13. Is your AI-built website actually portable?A concrete portability test for a website built with an AI tool: nine questions about the code, the accounts, the hosting, the domain, the data, the credentials and the deployment path, with a way to score where you stand and what to fix first.

If you built the site with a specific AI builder, there’s a guide to what you own there and one to leaving: Lovable, Bolt, Replit and v0. See all the guides, in reading order.

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. When the time comes, there is a guide to leaving a builder with your whole site, and specific ones for Lovable, Bolt, Replit and v0.

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.