Where is my website hosted?

What you need to start

Just the domain name, the address people type to reach your site. It helps to also have: the email inbox you used when the site was set up, any logins you remember (the AI builder, GitHub, a host), and about half an hour. You won’t need to install anything or read any code.

Work through the steps in order. Each one narrows down the next, and by the end you’ll have a short written record, which is the point of the exercise. There’s a template for it at the bottom.

The four things you’re looking for

A website depends on four separate services, and “where is my site hosted?” is really four questions:

1. The registrar holds your domain name and bills you for it.
2. The DNS provider holds the records that say where the domain points. Often the registrar, not always.
3. The host runs the website and answers when someone visits.
4. The repository holds the source code the host builds the site from, usually on GitHub. Some sites don’t have one.

One company can do more than one of these jobs. Cloudflare can be all of the first three. An AI builder can be the host and hold the code, and may have sold you the domain. The steps below find each one separately, so you know which company is doing which job even when it’s the same company. If you want the concepts first, read GitHub is not your web host; this guide is the practical version.

Step 1: Find the registrar

Every registered domain has a public record naming its registrar. The most reliable place to read it is ICANN’s own lookup tool, at lookup.icann.org. Type your domain name, without “www” or “https”, and read the result.

What to note down:

• Registrar. Under “Registrar Information”. This is the company holding the domain, and where the domain’s account lives.
• Nameservers. Two or more server names, such as ns1.something.com. You need these for Step 2.
• Expiry date. Under “Dates”. If it’s soon, deal with that before anything else.

Personal details are usually hidden in these records, so don’t expect to see a name. The registrar and nameservers are enough. One wrinkle: some builders and hosts sell domains as resellers of a larger registrar. The lookup shows the registrar; the place you actually manage the domain may be the builder. If the registrar name means nothing to you, that’s a sign to check the builder’s domain settings next.

Then: can you log in to the registrar?

Go to the registrar’s website and try to sign in with any email you might have used. If you can, and the domain is listed in the account, you’ve found the domain’s home and it’s yours. If you can’t, one of these is usually true:

• You bought the domain inside an AI builder or a host. Check that tool’s domain settings. It will say either that the domain is registered through the builder, or it will name the registrar and, sometimes, give you a link to manage it there.
• Someone bought it for you. A freelancer, an agency, or a colleague. The registrar name tells you where to ask them to look.
• You registered it and forgot. Search your email for the registrar’s name. Receipts and renewal notices will be there.

The domain guide explains what the registrar account should look like once you’re in it.

Step 2: Find where DNS is managed

The nameservers from Step 1 tell you which company holds your DNS records. Match them against this list:

Once you know the DNS provider, sign in there if you can and open the DNS records for your domain. You’ll see a list of records, each with a type (A, CNAME, MX, TXT and so on), a name, and a value. Take a screenshot or use the export button now, before anything else. Those records are the map for Step 3, and a copy of them is the single most useful thing to have if the site ever breaks.

If you can’t sign in to the DNS provider, you can still read the records from outside. A free lookup tool such as Google’s Dig shows them: enter your domain, and check the A, CNAME, MX and TXT types in turn, for both the bare domain and the www version.

Step 3: Find the host

The host is whatever the domain’s main records point at. Look at the A or CNAME record for the bare domain and the one for www. The value usually names the host outright or gives it away. Hosts change these values over time, and most tell you to use whatever their dashboard shows, so treat this table as a guide to recognising names rather than an exact list:

If DNS is at Cloudflare and the record is “proxied” (an orange cloud in the Cloudflare panel), the public lookup shows Cloudflare’s own addresses rather than the host’s. Sign in to Cloudflare and read the record’s real value there. If the site is a Cloudflare Worker or Pages project, Cloudflare is the host as well.

Two more ways to confirm the host

• The builder’s own address. AI builders that host sites give each one an address on their domain, such as yourproject.lovable.app or yourproject.replit.app. Open the builder, find the project, and see whether it has a “published” address and a “custom domain” setting pointing at your domain. If so, the builder is the host.
• The response headers. Every web page comes with a few lines of hidden information, and hosts often sign them. In Chrome, open your site, right-click and choose Inspect, open the Network tab, reload the page, click the first entry, and open its Headers tab, under Response Headers. A header such as server: Vercel, x-vercel-id, server: cloudflare, cf-ray or x-nf-request-id (Netlify) names the service that answered. If Cloudflare is in front of the site, its headers replace the host’s, which is one more reason to check the Cloudflare account. This is the only step that looks technical; you’re just reading a label.

When you’ve found the host, try to sign in to it with any email you might have used, and look for a project whose name matches your site. If the site is inside a builder, its “project” is the host entry.

Step 4: Find the code and the repository

The host builds the live site from a copy of the source code. Where that copy comes from tells you where the code lives.

1. Check the host’s project settings for a Git connection. On Vercel it’s under the project’s Settings, in the Git section, under “Connected Git Repository”. On Netlify it’s under Project configuration, then Build & deploy, then Continuous deployment, under “Repository”. On Cloudflare it’s in the Worker’s Settings, under Builds. If a repository is connected, its address is shown there, and looks like github.com/someone/something. Note it down: the part after github.com/ is the account that owns the code.
2. Check the builder for a GitHub connection. If the site lives in an AI builder, open the project’s settings and look for “GitHub”, “Git”, “Sync” or “Export”. If it’s connected, the builder shows the repository address. If it isn’t, the only copy of the code is inside the builder.
3. Check GitHub directly. Sign in at github.com and open your list of repositories from the top of the page. If one is named after your site, open it and confirm it contains files. If you belong to an organization, check its repositories too.

Three outcomes are possible, and each is fine to know:

• A repository under your account. You have the code.
• A repository under someone else’s account, with you as a collaborator or not at all. The code exists but isn’t yours yet. Ask for it to be transferred.
• No repository. The code lives only in the builder, or was uploaded to the host by hand. The site works, but you can’t take the code anywhere until you export it and put it in a repository.

If “repository” is a new word, the GitHub guide explains what you’re looking at.

Step 5: Work out who controls each account

You now have up to four accounts: registrar, DNS provider, host, and GitHub. For each one, answer the same four questions and write the answers down:

1. Can I sign in? With my own email and password, not someone else’s.
2. Whose email is on the account? That address receives password resets and renewal notices. It’s the real owner.
3. Whose card is on it? Whoever pays can also stop paying.
4. What is my role? Owner, admin, member, collaborator, or guest.

Where to find your role:

• GitHub. On the repository, open Settings, then Collaborators under “Access” (for an organization’s repository, Collaborators and teams). If you can’t see Settings at all, you aren’t an admin.
• Vercel and Netlify. The team’s settings have a Members page listing everyone and their role. On a personal Vercel Hobby account, you are the owner.
• Cloudflare. The account’s Members page lists members and their roles.
• The registrar and the builder. Most have an account or profile page showing the account email and any additional users.

“I can see the dashboard” is not the same as “I control the account”. The tests are whether the email is yours, whether the card is yours, and whether you could remove everyone else. If any answer is no, you’ve found a conversation to have, and the ownership overview covers what to ask for.

Telling the registrar, DNS provider, host and repository apart

When one company appears more than once, this is how to keep the jobs straight:

So “my site is on Cloudflare” might mean Cloudflare is the registrar, the DNS provider, and the host, or only the DNS provider with the site actually on Vercel. “It’s on GitHub” means the code is there; it says nothing about who runs the site. Naming the job as well as the company removes the ambiguity.

Common setups and what they mean

Most AI-built sites end up in one of a few arrangements.

Everything inside the builder

The builder hosts the site at its own address, may have sold you the domain, and holds the only copy of the code. Convenient, and the least portable. The steps to change it are in the guide to leaving a builder, and the first of them is connecting or exporting the code to a repository you own.

Builder hosting, code on GitHub

The builder still runs the site, but the code is in a repository under your GitHub account. This is a reasonable place to be: you can keep using the builder, and you could move the site to another host without rebuilding it.

Own registrar, GitHub, and a host such as Vercel, Netlify or Cloudflare

The domain is in your registrar account, the code is in your repository, and a host you control builds the site from it. Each piece can be replaced on its own. This is the shape the rest of the guides work towards.

Someone else’s accounts

Any of the above, but with the registrar, host or repository under a freelancer’s or agency’s login. The site may be well built and well run; it just isn’t yours yet. The fix is administrative: transfer the domain, transfer the repository, and be made an owner on the host.

If you get stuck

• Search your email. Receipts, welcome messages and renewal notices name every service you or your builder signed up for. Try the words “domain”, “renewal”, “deploy”, “GitHub”, “Vercel”, “Netlify”, “Cloudflare” and your domain name.
• Ask the tool that built the site. If it was an AI coding agent, ask it plainly: “Where is this site hosted, and which repository is it deployed from?” It can read the project’s configuration and tell you.
• Ask the person who set it up. Send them the record template below and ask them to fill it in. It’s a reasonable request and it takes them ten minutes.
• Ask the builder’s support. They can tell you whether a domain was registered through them and whether your project is connected to a repository.

What to record

Put this in your password manager or wherever your business keeps its important documents, and update it when anything changes.

Once the record shows a repository you own and a host you control, the site is yours in the ways that matter. What’s left is the day-to-day: at that point, fixing a sentence on the site means prompting a coding agent, waiting, and checking, which is a lot of process for a few words. Refino exists for that step. It adds click-to-edit text to the site you already have and saves the change back to your repository, without moving any of the pieces you just mapped. Here is how it works.

Sources

The rules and product behaviour described above were checked against these pages when the guide was last updated. If something here has changed, these are the places to look.

• ICANN Lookup · ICANN
• Identify your domain registrar · Google Workspace Admin Help
• Dig (DNS lookup) · Google Admin Toolbox
• A record and CAA with Vercel · Vercel
• Working with nameservers · Vercel
• Response headers · Vercel
• Git settings · Vercel
• Configure external DNS for a custom domain · Netlify
• Netlify name servers · Netlify
• Repository permissions and linking · Netlify
• Nameservers · Cloudflare
• Proxy status · Cloudflare
• Cloudflare HTTP request and response headers · Cloudflare
• Workers Builds · Cloudflare
• Managing a custom domain for your GitHub Pages site · GitHub
• Managing teams and people with access to your repository · GitHub
• Viewing all your repositories · GitHub
• Custom domain · Lovable
• Connect a domain · Bolt
• Add a custom domain · Replit
• Custom domains · v0
• Network features reference · Chrome DevTools