How to Publish an AI-Generated Website

Evidence checked September 28, 2026. VERIFIED means completed and confirmed for Just Make AI Work. OFFICIAL SOURCE VERIFIED means documented but not demonstrated in this project. NEEDS HUMAN CHECK identifies unresolved or untested details. These labels do not promise the same result for every website.

Problem: AI made your website, but how do you put it online?

You have a website that looks right inside an AI tool. Now you want someone else to open it without signing into your account.

The path is website files → hosting → working temporary address → domain and DNS → HTTPS → live website. Hosting stores and serves the site. Deployment puts a particular version onto that service. A domain is the address people type to reach it.

This tutorial follows the actual launch of Just Make AI Work. Its source project used Astro, a tool that generates website pages. We sent it through GitHub to Cloudflare Pages, checked the supplied address, and connected a domain registered with NameSilo. You do not need to learn Astro to understand the process.

This case verifies a small site made of ready-to-serve pages. It does not verify a shop, payment system, member login or application that stores customer data.

What you need

• Access to your AI project and permission to publish its text and images.
• Confirmation of what the tool produces: finished files, a source project, or a site that stays inside the builder.
• A hosting account you control. Our route also needed GitHub and, later, access to the domain registrar.
• A list of pages and features to test, plus a phone for the final visual review.

Before choosing a host, ask your AI tool:

What files does this website need for publishing? Is it a static website made of finished pages, or does it need a running server? What is its build command and output folder? Show the project files that support your answer. Identify anything you cannot verify.

A build turns source files into the finished files the host serves. The output folder contains those finished files. A server handles work that cannot happen in the visitor’s browser alone. Check the tool’s answer against the project and the host’s documentation.

OFFICIAL SOURCE VERIFIED: Cloudflare documents Direct Upload for prebuilt files. We did not use that route. Its documentation says a Direct Upload project cannot later switch to Git integration, so choose the project type deliberately.

NEEDS HUMAN CHECK: Your builder’s export rights, current charges, account requirements and any server requirements. This case does not establish a price comparison.

Step-by-step

1. Check the website before sending it to a host

Open the local preview supplied by your coding tool and check the intended pages. Ask the tool to run the project’s build and show the result. A preview that looks right does not prove the production build works.

Keep a recoverable source copy. Review what will be uploaded: passwords, secret credentials and personal test data do not belong in public website files.

VERIFIED: Our local production build succeeded. The project configuration selected a static site. The output contained a homepage, two category pages, About, Privacy, Affiliate Disclosure and an error page. It also generated a sitemap, the list of page addresses supplied to search engines.

2. Put the source project in GitHub

Git records versions of files. GitHub stores that versioned project online in a repository, a project folder with its history. A commit saves a version; a push sends it to GitHub.

For this route, have your coding tool prepare the repository and send your reviewed project to GitHub. Complete sign-in and access approval yourself. Open the repository and confirm it contains the intended project and latest saved version.

A branch is a named line of versions. Identify the branch intended for the public site. Ours was main; do not assume every project uses that name.

VERIFIED: We used a private GitHub repository and its main branch. Private source storage did not make the deployed website private. This case used assisted Git operations; it does not establish button-by-button instructions for every AI coding tool.

3. Connect the repository to Cloudflare Pages

Open Workers & Pages in Cloudflare and use the Pages Git integration workflow to connect your intended GitHub repository. Confirm you are creating a Pages project. Complete the GitHub authorization for the repository you intend to deploy.

Cloudflare’s GitHub integration guide documents this connection and deployments from subsequent repository changes. Refer to it if your account’s interface differs. This walkthrough does not depend on a button being in a particular corner.

Enter the build settings supported by your project. These were ours:

• Production branch: main. The branch used for the public version.
• Build command: npm run build. The project’s instruction for generating the site.
• Build output directory: dist. The folder containing the finished site.
• Root directory: left blank. The project was at the root of the connected repository.

VERIFIED: Our actual Cloudflare configuration and full deployment log matched these values. The log showed Astro completing the build and Cloudflare publishing the files. These are case settings, not values to copy into every project. The build configuration reference lists framework-specific settings.

4. Test the temporary address before touching DNS

In the project’s Deployments, select the intended production deployment and examine its details and build log. Confirm the expected branch and saved version, a completed build, and successful publication. Copy the public address shown there rather than reconstructing it from memory.

VERIFIED: These were our working addresses:

• Project address: justmakeaiwork.pages.dev.
• Initial deployment address: 2342d6eb.justmakeaiwork.pages.dev.

Open your own address in a browser window where you are not signed into the builder. Check the homepage, then paste a direct inner-page address. Confirm the intended content appears, not just that something loads.

Our real problem: the temporary URL was reported to return 404. A 404 means the requested page was not found. The dashboard’s success message was not enough evidence that the public website worked.

We compared the repository connection, branch, build settings, complete deployment log and exact addresses. Later public requests to both addresses returned HTTP 200, a successful response, with the expected site content. The owner also confirmed the temporary website and desktop appearance in a browser.

NEEDS HUMAN CHECK: We never established the original 404’s cause. We cannot attribute it to DNS, a missing file, caching or a specific configuration repair. Later success does not prove what caused the earlier failure.

If your temporary address still fails, follow the troubleshooting checks below. Do not change your purchased domain’s DNS to repair a failing pages.dev address. First get the host-provided address working.

5. Connect your domain after the temporary site passes

Your registrar is the company where you registered the name. DNS is the address-book system that tells browsers where that name goes. Nameservers identify the service managing those DNS instructions.

VERIFIED: We kept the domain registered at NameSilo and moved its DNS management to Cloudflare. Our completed sequence was:

1. Add the domain to Cloudflare using the domain connection workflow.
2. Review imported DNS records. If the domain already handles email or other services, reconcile their existing records before changing nameservers.
3. At the registrar, replace the old nameservers with the exact pair Cloudflare assigned to your domain. Save and confirm the displayed values.
4. Return to Cloudflare and confirm activation.
5. In the Pages project’s Custom domains, add the root domain and review the proposed DNS change before activating it.

The root domain is the address without www. For ours, Pages proposed replacing three old address records with a CNAME, a record pointing a name at another hostname: justmakeaiwork.pages.dev. We accepted, and the domain became Active.

Use your own assigned nameservers and project target. Do not copy another site’s nameservers or remove unrelated records. We did not transfer the domain registration to Cloudflare.

OFFICIAL SOURCE VERIFIED: The custom-domain documentation distinguishes root domains from subdomains. This root-domain route requires a Cloudflare zone and Cloudflare nameservers. A subdomain can use an external DNS provider but still needs association with the Pages project. We did not test that external-provider route.

6. Choose one main address and check HTTPS

HTTPS encrypts the connection between the visitor and the site. Its certificate lets the browser check the site’s identity. Open the actual https:// address and confirm there is no certificate warning.

VERIFIED: We added both the root domain and www.justmakeaiwork.com to Pages. Both became Active. We then created a Cloudflare redirect rule so www sends visitors to https://justmakeaiwork.com.

The tested rule matched hostname www.justmakeaiwork.com, used 301 Permanent Redirect, retained the page path, and preserved the query string, the part after ?. For example, /about/?ref=verify remained /about/?ref=verify on the root domain. Cloudflare provides an official www-to-root example; our actual rule used a hostname condition rather than that wildcard template.

Test an inner page too. Sending every address to the homepage would lose the visitor’s intended page. Both HTTP and HTTPS versions of our www test redirected correctly, and the destination loaded with certificate validation enabled.

How to check it worked

• Temporary address: the correct site opens without a builder login. VERIFIED: both supplied addresses returned 200.
• Main address: the correct homepage loads over HTTPS. VERIFIED: 200 with certificate validation.
• Inner pages: direct addresses display the intended pages. VERIFIED: two categories, About, Privacy and Affiliate Disclosure returned 200.
• Alternate address: www redirects while retaining the page path and query. VERIFIED: HTTP and HTTPS tests returned 301.
• Sitemap: the file lists intended public addresses. VERIFIED: our actual sitemap is /sitemap.xml.
• Phone usability: readable text, usable navigation and no sideways scrolling. NEEDS HUMAN CHECK: a real-phone launch review is not established by this case.
• Forms, accounts and payments: safe end-to-end tests reach the intended outcome. NEEDS HUMAN CHECK: not demonstrated by this static site.

Ask your coding tool to check response status and page content if you cannot inspect them yourself. A 200 response showing the wrong page is not a pass.

For search readiness, noindex tells search engines to exclude a page; robots.txt gives crawling instructions; a canonical URL identifies the preferred page address.

VERIFIED: After the domain worked, our production configuration allowed indexing. Production pages used the official domain in their canonical URLs, robots.txt allowed crawling, and the sitemap used the official domain. Our PUBLIC_INDEXABLE setting is project-specific, not a universal Cloudflare switch. It required a new build to take effect. These checks establish permission to index, not that Google has indexed or ranked the site.

Common problems

The temporary deployment returns 404

Work through these checks before connecting a domain:

1. Confirm the exact address. Copy it from the intended deployment. Check for a different project or mistyped page path.
2. Read the full log. Confirm the expected version was built and published. The official debugging guide identifies the build log in deployment details.
3. Check the finished files. Ask your coding tool to confirm that the deployed output contains index.html at its top level. OFFICIAL SOURCE VERIFIED: Cloudflare identifies a missing top-level homepage file as one possible root-address 404 cause.
4. Compare build and output settings with the project. Serving the wrong folder can leave intended files unavailable. Do not change values at random.
5. Test the root and inner pages separately. Record the failing URL, time and response when asking for help.

These are diagnostic checks, not a diagnosis of our original incident. Its cause remains unknown.

The temporary site works but the custom domain does not

Keep the working deployment available. Check saved nameservers, Cloudflare activation, the Pages custom-domain entry and its requested DNS target. Do not add duplicate records simply because verification is pending. Our successful case is not a promise of a fixed activation time.

A button appears, but its action does nothing

A visible form or login button does not prove the service behind it exists. Ask the builder what handles the action and whether the host supports it. Complete a safe test before collecting real submissions. This deployment does not verify those features.

Next step

Save the working URL and the settings that produced it. Keep the source recoverable, and repeat page checks after changes. Before changing hosts, identify which requirement your current service cannot meet.

The milestone is that someone outside your account can open the intended pages at your chosen address with valid HTTPS. A deployment confirmation screen alone is not that milestone.