How to put your website’s code in GitHub

Why the repository is the thing to own

A website is built from a folder of source files. The live site is a copy made from that folder. If the only complete folder is on a developer’s laptop or inside a builder’s platform, then the live site is a photograph of something you don’t hold. A repository under your GitHub account is the original.

It’s worth having for five concrete reasons:

• Portability. Any host can build the site from it. Any developer can work from it.
• History. Every change is recorded and can be undone.
• Coding agents. Claude Code, Cursor, Codex and the builders that sync to GitHub all work on a repository. It’s the one format they share.
• Backup. If a laptop dies or a platform closes, the site is still there.
• Deployment you can trace. A host connected to your repository publishes what’s in it. Nobody has to upload files by hand.

If “repository” is new to you, read GitHub for website owners first. It’s short. This guide assumes you know what one is and gets you to a state where you have one.

Which situation are you in?

Pick the one that matches and skip to it:

• A. The site is already on GitHub, and you want to confirm it’s the right repository and that you control it.
• B. A developer or agency has the repository under their account.
• C. The code only exists on someone’s computer, or was uploaded to the host by hand.
• D. The site came from an AI or site-building platform.

Not sure? The diagnostic guide finds the repository from the host’s settings in a few minutes.

First: a GitHub account you control

Every situation ends with the code in an account that’s yours. Set that up before anything else.

1. Create a GitHub account at github.com if you don’t have one, with an email address you control. It’s free, including unlimited private repositories.
2. Turn on two-factor authentication and save the recovery codes. GitHub requires 2FA for anyone who contributes code, and without the codes a lost phone can mean a lost account.
3. If the site belongs to a business with more than one person involved, create an organization, also free, and make your personal account its owner. An organization owns repositories independently of any one person’s login, so staff and contractors can come and go. For a personal project, your personal account is fine.

A. The site is already on GitHub

Four checks, in order.

1. Which repository is the real one?

Don’t trust the name. Go to the host and read the repository it deploys from: on Vercel, the project’s Settings, then Git, under “Connected Git Repository”; on Netlify, Project configuration, then Build & deploy, then Continuous deployment, under “Repository”; on Cloudflare, the Worker’s Settings, then Builds. That repository, and the branch shown next to it, is the one the live site is built from. If the host has no repository connected, you’re in situation C, whatever exists on GitHub.

2. Whose account owns it?

The repository address is github.com/OWNER/NAME. If OWNER is your personal account or an organization you own, good. If it’s a developer’s account, the builder’s organization, or an organization you’re a member of but don’t own, you’re in situation B.

3. Do you have admin rights, not just access?

Open the repository and look for a Settings tab. If you can’t see it, you don’t have admin rights. On a personal repository, only the owner has them. On an organization repository, open Settings, then Collaborators and teams, and check your role: it needs to say Admin, or you need to be an organization owner. Read or Write access lets someone work on the code; it doesn’t let them transfer, delete or change who else has access, which is what ownership means.

4. Does the site actually deploy from it?

Make a harmless change and see it go live: ask your coding agent to fix a typo, or edit a line of text in the GitHub web editor and commit it. The host should show a new deployment within a couple of minutes, and the change should appear on the site. If it doesn’t, the host is publishing from somewhere else, and the repository is a copy rather than the source; the guide to a website not updating after a deploy finds where the change stopped.

B. A developer or agency has the repository

The code exists and is on GitHub, which is most of the work. What’s wrong is the owner. There are two ways to fix it, and the first is much better.

Ask for the repository to be transferred

GitHub can transfer a repository from one account to another with its full history, and links to the old address keep redirecting afterwards. The developer, who needs admin access to do it, opens the repository’s Settings, uses the Transfer option, and enters your username or your organization’s name. You accept. They can stay on as a collaborator if you want them to keep working on it; you can remove them when you don’t.

After a transfer, check the host. Neither Vercel nor Netlify documents what happens to a project’s Git connection when the repository moves accounts, so don’t assume. Look at the Git setting again, reconnect the repository if it no longer shows the new address, and make a test change as in situation A.

If they won’t or can’t transfer it

Ask for a full copy instead. A developer can clone the repository, which includes the history, and push it to a new repository under your account; or you can download the current files as a ZIP from the repository page (Code, then Download ZIP) and upload them into a new repository yourself, losing the history but keeping the site. GitHub’s web uploader takes at most 100 files at a time, so for a whole site the clone-and-push route is quicker. Then reconnect the host to your repository. From that moment, their copy is the stale one.

Either way, remember that the repository is only one of the accounts involved. Environment variables live on the host, the domain lives at the registrar, and neither moves with the code. The secrets guide is the next step once the code is yours.

C. The code only exists on someone’s computer

This includes a site a developer built and uploaded by hand, a site that was “deployed from my laptop”, and a site whose GitHub repository turns out to be empty or out of date. The project folder needs to be put into a repository under your account, and the host needs to be connected to it.

You don’t need to do the technical part yourself, but you should know what it is, so you can ask for it and check it happened:

1. Create an empty private repository under your account or organization on GitHub. Give it the site’s name.
2. Whoever has the folder turns it into a repository and pushes it to yours. For a developer this is a few commands; for a coding agent, “push this project to the repository at this address” is enough. GitHub Desktop does the same thing with buttons.
3. Open the repository on GitHub and confirm it contains the site’s files, not just one or two.
4. Connect the host to the repository, and make a test change as in situation A. The deployment guides for Vercel, Netlify and Cloudflare cover connecting from scratch.

For the curious, the commands a developer runs from inside the project folder look like this:

git init -b main
git add .
git commit -m "Import site"
git remote add origin https://github.com/OWNER/NAME.git
git push -u origin main

You never need to type these. The point is that they’re routine, take a minute, and leave the folder exactly as it was. Anyone who tells you it’s a big job is describing something else.

If nobody has the folder any more, the host may still have it: some hosts let you download the files of the current deployment. Failing that, the site would have to be rebuilt, which is exactly the situation a repository prevents.

D. The site came from an AI or site-building platform

The key question is whether the platform gives you the actual source of the site, and in what form. Platforms fall into three groups, and the same platform can move between them as it changes, so check its current documentation for “GitHub”, “export” and “download”.

Platforms that sync to GitHub

AI builders such as Lovable, Bolt and v0 can connect to a repository under your own GitHub account and keep it updated as you work. Turn the connection on, and confirm the repository it creates is under your account or organization, not the platform’s. Then it’s situation A: check the host deploys from it. Some of these platforms also host the site themselves; connecting GitHub doesn’t change that, but it means you could move the hosting later without rebuilding.

Platforms that export the source

Some let you download the project as a ZIP of source files, on some plans. That’s situation C: put the download into a repository under your account, and set up a host that deploys from it. Be aware that what you export is the site as of that moment; if you keep editing inside the platform afterwards, the repository falls behind unless the platform also syncs.

Platforms that don’t give you the source

Traditional site builders such as Squarespace and Wix generally let you export content, such as pages, posts and images, but not the working source of the site. Webflow can export a site’s HTML, CSS and JavaScript on its Workspace plans, but not its CMS content, user accounts, ecommerce or forms. Framer doesn’t offer code export at all. For these, “put the site on GitHub” isn’t an operation the platform supports; the honest description of what you own is the content, the domain, and a site that lives in the platform. That’s a fair trade for many businesses. It’s just worth knowing before you depend on it.

A platform’s export is also usually only the code. Databases, user accounts, uploaded files and settings need moving separately; where your website’s data lives goes through them, and the guide to leaving a builder has the full inventory.

What must not go in the repository

Passwords, API keys and similar secrets belong on the host as environment variables, not in the code. If someone puts a secret in a repository, even a private one, treat it as exposed: once it’s in the history it’s hard to remove, and GitHub’s own guidance is to revoke or rotate the secret as the first step, before trying to remove it. This matters when importing a project from a computer, where a developer may have kept a settings file with keys in it next to the code. Ask them to check before pushing.

The ownership checklist

With every box ticked, the repository is the site’s source of truth and it’s yours. That’s the state the rest of the ownership overview builds on, and it’s the state Refino assumes: it edits the words in that repository directly, so a change to a sentence is a commit to your own code rather than a request to whoever built the site. 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.

• Creating a new repository · GitHub
• Adding locally hosted code to GitHub · GitHub
• Transferring a repository · GitHub
• Repository roles for an organization · GitHub
• Creating a new organization from scratch · GitHub
• Downloading source code archives · GitHub
• Removing sensitive data from a repository · GitHub
• About mandatory two-factor authentication · GitHub
• Git settings · Vercel
• Deploying Git repositories with Vercel · Vercel
• Repository permissions and linking · Netlify
• Workers Builds · Cloudflare
• Adding a file to a repository · GitHub
• GitHub integration · Lovable
• Git integration · Bolt
• GitHub · v0
• How do I export my Webflow site code? · Webflow
• Exporting or embedding your Wix site elsewhere · Wix
• Exporting your site · Squarespace
• Can I export my website to HTML and self-host it? · Framer