Skip to content

AI Website Builder Free is published by General Action, the company that makes Emdash. When we recommend Emdash, we are recommending our own product. About this site

Build a website for free with AI

You can put a real website online with no hosting bill by combining three things: an open-source static site generator, free static hosting and an AI coding agent that writes the site for you. Two costs remain and nothing removes them: the AI model that does the writing, and a domain name if you want your own address.

This route is for people who can work in a terminal or are willing to learn. If that is not you, a hosted builder’s paid plan is money well spent. See Free plan vs. paid.

  • A free GitHub account, to store the site’s code.
  • Node.js installed on your computer. Astro’s install guide gives the minimum version.
  • An AI coding agent installed and signed in. Claude Code and Codex are two widely used ones.
  • The words and pictures for the site: what you do, who it is for, how to reach you. An agent can draft copy, but it cannot know your prices or your opening hours.

Step 1: Create the project and the repository

Section titled “Step 1: Create the project and the repository”

Open a terminal in the folder where you keep projects and run Astro’s installer:

Terminal window
npm create astro@latest

The wizard asks for a folder name and a starter template and offers to install the dependencies. Accept, then start the development server from inside the new folder:

Terminal window
npm run dev

Astro’s documentation says the site is then served on http://localhost:4321/. Open that address and you are looking at a working starter site.

Now put the project under version control. Create an empty repository on GitHub, then connect the folder to it:

Terminal window
git init
git add .
git commit -m "Starter site"
git branch -M main
git remote add origin https://github.com/YOUR-NAME/YOUR-SITE.git
git push -u origin main

If the wizard already set up Git for you, skip the first three lines. Make the repository public if you plan to use GitHub Pages on a free account. From here on, every change the agent makes is a commit you can inspect and undo.

The agent will invent whatever you leave out. Before you prompt it, put everything that must be right in a file called notes.md at the top of the project.

Name: Harbour Street Physiotherapy
What we do: physiotherapy and sports massage, two practitioners
Address: 14 Harbour Street, [town], [postcode]
Phone: [number] Email: [address]
Hours: Mon to Fri 8:00 to 18:00, Sat 9:00 to 13:00
Treatments and prices: [list each one with its price]
About: [three or four sentences in your own words]
Photos: in the /photos folder, with a line saying what each shows

Ten minutes on this file saves an hour of removing things that were never true.

Start your coding agent in the project folder and describe the site the way you would brief a freelancer. Be specific about pages and content, and say what you do not want.

This is a new Astro project. Build a five-page static website for
Harbour Street Physiotherapy, a two-person clinic.
Pages: Home, Treatments, About, Prices, Contact.
Content: use the text in notes.md. Do not invent prices, staff
names or testimonials. Mark anything missing as [MISSING].
Design: calm and plain, dark green accent, large readable type,
works well on a phone. No animations, no client-side JavaScript
unless a feature needs it.
Each page needs a unique title and meta description.
Run the build when you are done and fix any errors.

The agent creates the pages, layouts and styles, runs the build and reports back. This is the same generate-and-check loop a hosted AI builder runs. The difference is that the files land in your folder.

The first draft is never the finished site. These prompts cover the work a hosted builder does out of sight. Send them one at a time and look at the result after each.

Goal Prompt
Catch invented facts “List every factual claim on the site that does not come from notes.md, with the file it is in. Do not fix anything yet.”
Make search results accurate “Check that every page has one h1, a unique title and a meta description that describes that page. Show me the list.”
Make it usable for everyone “Check heading order, alt text on every image, text contrast against its background, and that every form field has a visible label. Fix what fails and tell me what you changed.”
Keep the pages light “Resize the photos so that no image file is larger than it needs to be for a phone screen, and remove any JavaScript the pages do not need.”
Handle contact “Replace the contact form with an email link and a phone link, because this site has no server.”

Asking for a list before a fix, as in the first row, keeps you in charge of what changes.

Look at every page in the local preview, on a narrow window as well as a wide one. Then run the production build and view that:

Terminal window
npm run build
npm run preview

The build writes the finished site to a dist/ folder. That folder is the whole website, and it is what the host will serve. Before you publish, check three things:

  1. Invented facts. Models fill gaps with plausible text. Search the project for anything you did not supply.
  2. Leftover placeholders. Search for [MISSING] and “lorem”.
  3. Broken links and missing images. Click everything once.

Run git diff to see exactly what changed, ask for corrections one at a time, then commit and push.

Compared on Cloudflare GitHub Pages
Free address A workers.dev subdomain A github.io address
Published limits on the free tier 20,000 files, 25 MiB per file; requests to static assets “free and unlimited” A 1 GB site and a soft limit of 100 GB of bandwidth a month
Business use No restriction of this kind in the pages we read Not allowed as free hosting for an online business or e-commerce site
How a deploy happens A command, or a build triggered by each push A GitHub Actions workflow on each push

The figures come from Cloudflare’s billing and limits pages and GitHub’s Pages limits, read on 13 November 2026.

Astro’s Cloudflare deployment guide describes the setup. A static site needs no adapter. Add the Wrangler command-line tool and a small wrangler.jsonc file that points at the build output:

Terminal window
npm install wrangler@latest --save-dev
{
"name": "harbour-street-physio",
"compatibility_date": "2026-11-13",
"assets": { "directory": "./dist" }
}
Terminal window
npx astro build && npx wrangler deploy

The site goes live on a workers.dev address. To publish on every push instead, import the GitHub repository in the Cloudflare dashboard and set the build command to npx astro build and the deploy command to npx wrangler deploy.

Astro maintains an official GitHub Action for this. Three things have to be right:

  1. Add the workflow file from that guide as .github/workflows/deploy.yml.
  2. In the Astro config, set site to your github.io address and base to the repository name with a leading slash. Internal links then need that prefix too, which is a frequent reason a Pages site loads without its styles.
  3. Under the repository’s Pages settings, choose GitHub Actions as the source.

Each push to main then publishes the site. Commit the lockfile, because the action uses it to detect your package manager.

You can ask the agent to do all of step 6. Give it the link to the relevant guide and tell it which host you chose.

Step 7: Connect your own domain, when you want one

Section titled “Step 7: Connect your own domain, when you want one”

This is the first point where money changes hands. Register a domain with any registrar. Cloudflare’s own registrar says it “does not mark up domain prices at all”, which makes it a reasonable baseline for comparing what others charge.

  • On Cloudflare, a custom domain requires an active zone, meaning the domain’s DNS is managed in your Cloudflare account. You add the domain under the Worker’s settings, and Cloudflare creates the DNS record and the certificate.
  • On GitHub Pages, enter the domain under the repository’s Settings → Pages → Custom domain first, and only then create the DNS records with your domain provider. GitHub’s guide to managing a custom domain gives the records and explains the order: setting DNS first “could result in someone else being able to host a site on one of your subdomains”. A CNAME file in the project does nothing here, because when a site is published by a GitHub Actions workflow “any existing CNAME file is ignored”. Then change site in the Astro config to the new address, remove base, and push so the site is rebuilt with the new links. GitHub supports both subdomains and apex domains.

If you skip this step the site still works, on the host’s subdomain. You can add the domain a year later. Expect to change the site setting and publish once more when you do, so that the canonical addresses and the sitemap use the new domain.

Item Cost Notes
Astro Nothing Open source under the MIT licence
Code storage on GitHub Nothing Pages needs a public repository on GitHub’s free plan
Static hosting Nothing, within the host’s limits See the table in step 6
Domain name A yearly fee Optional, but most real sites want one
AI coding agent A subscription or per-use API billing The one cost that scales with how much you change
Your time An afternoon to start Plus a few minutes of review per change
Symptom Likely cause What to tell the agent
The Pages site appears without styles or images base is missing, or links ignore it “The site is served from a subfolder on GitHub Pages. Set base and fix every internal link.”
The build works locally but fails on the host A different Node.js version, or no lockfile in the repository “Pin the Node.js version for the build and commit the lockfile.”
Cloudflare rejects the upload A file larger than 25 MiB, often a video “Find files over 25 MiB in dist and compress or remove them.”
The contact form does nothing A static site has no server to receive it “Replace the form with an email link, or connect it to a form service I will name.”

Be clear about what a hosted builder would have done for you:

  • No visual editor. Changes happen by asking the agent or editing files.
  • No built-in back end. Forms, bookings, payments and member log-ins need a separate service.
  • No support line. When something breaks, you and the agent fix it.

In return, nothing about the site is rented. There is no badge and no plan to outgrow, and the question in Exporting your site and lock-in never comes up, because the code was yours from the first commit. To see how this route compares with a free plan or a trial, go back to the three routes.

Frequently asked questions

Can I really host a website for free?

Yes, if the site is static, meaning plain HTML, CSS and images with no server behind it. Cloudflare states that requests to static assets are free and unlimited, and GitHub Pages is free for public repositories within published size and bandwidth limits. Both let you connect a domain you own.

Do I need to know how to code to build a site with an AI coding agent?

You do not need to write the code, but you need to be comfortable around it. Expect to install Node.js, run a few terminal commands, use a GitHub account and read a summary of what the agent changed. If that sounds unpleasant, a hosted website builder is the better choice.

Which is better for a free site, Cloudflare or GitHub Pages?

For a personal site or portfolio either works. For a site that promotes or runs a business, use Cloudflare, because GitHub states that Pages is not allowed to be used as free hosting to run an online business or e-commerce site. GitHub Pages is the simpler choice when the code already lives in a public GitHub repository.

How do I add a contact form to a static site?

A static site has no server to receive form submissions, so the form has to post somewhere else. The options are a hosted form service, a small serverless function on your host, or a plain email link. Ask the coding agent to set up whichever you choose, and send a test message before you publish.

How do I change the site after it is live?

The same way it was built. Describe the change to the coding agent, look at the result in the local preview, read what changed, then commit and push. If the repository is connected to the host, the push publishes the new version. There is no dashboard to log in to, and every earlier version stays in the Git history.