How to publish an AI-generated HTML website

A website running on localhost is still on your computer. To share plain HTML and CSS, publish the files that visitors’ browsers need. Once hosted, the website does not depend on keeping your computer switched on.

This walkthrough uses an original MIT-licensed example. Open the live demonstration or load its second page directly. It has no authentication, database or form submission service.

If your project uses React and Vite, follow the Git deployment and browser routing guide, using an example built and published on Hostbrid.

If you built the website for a client, the static-site handoff checklist helps review the domain, accounts, code and responsibilities.

1. Check that your website is static HTML

The example places index.html, about.html and styles.css at the repository root. Links use relative paths such as styles.css and about.html. A path to /Users/... or localhost points to your own machine, which visitors cannot access.

If your AI tool produced package.json, a server API or an external backend, these instructions may cover only part of the application. Read which hosting an AI-built website needs. Keep required backend services working rather than removing them to fit a static deployment.

2. Put the files in your own repository

Copy or fork the example into your GitHub account and keep its licence. Replace sample content and images, then confirm that index.html is at the root of the branch you intend to publish. Keep private keys, passwords and customer data out of the repository.

Projects uses Git repositories. Downloading a ZIP does not mean there is a direct ZIP upload in the panel. The Projects documentation explains connecting a provider and selecting a repository; review the permissions you grant.

3. Configure this HTML example

Use the plain HTML preset (estatico). These are the settings verified for these files:

Do not add npm ci or npm run build: this example has no packages to install or code to compile. Files in another folder need an appropriate root and output path. . is not the correct output directory for every framework.

4. Test the public address

Open the project’s HTTPS address from another device. Check the home page, enter /about.html directly, reload it, follow the link between pages and confirm the CSS loads. Check mobile layout too. A “published” status alone does not prove public availability: our first request returned 404 before later checks successfully served the demonstration.

Tested on 8 October 2026: commit cca391c was downloaded and published with the settings above. Both pages and CSS matched the source over HTTPS; navigation and layouts passed at 390 and 1280 px. We used Hostbrid’s internal account. This proves the build and publishing path, but does not certify customer OAuth onboarding or updates triggered by a push.

Published does not mean indexed

A URL opening over HTTPS lets you check publication. It does not demonstrate that Google has indexed it or that it will appear at any particular position. Changing hosting does not guarantee AI recommendations either.

Compare the HTML received in the response with the DOM displayed after the browser runs JavaScript. Text may be present initially or appear later through a script. According to Google’s JavaScript documentation, Google can process JavaScript: initial HTML without that text does not prove Google cannot see it. Seeing it in your browser does not prove Google rendered that page either.

For a page you deliberately intend to show in search, check its HTTP status, robots meta tag and X-Robots-Tag header. An initial noindex matters even if JavaScript later removes it: Google may skip rendering when it encounters it. Read Google’s indexing prevention guidance before changing those instructions. Do not put noindex in robots.txt, and do not remove restrictions from private or intentionally excluded pages. If crawling is blocked, Google may not read the page’s instruction.

In Search Console, examine the URL with its authorised owner or responsible person. Distinguish the stored result from a live inspection: they are different checks, and an API query does not automatically request indexing. HTTP200 without noindex still does not establish indexing or ranking. Record what you observe, then continue with the relevant form or domain checks.

Inspect the original MIT experiment: six synthetic routes compare static HTML, JavaScript-inserted text, meta or header noindex, an initial tag removed by JavaScript and a real HTTP404. HTTP responses and twelve Chrome views were checked at 390 and 1280 px. In the removal case, Chrome displays the text and removes the tag, but that does not establish that Google does the same. To reproduce only this local experiment, follow the README with Node 22.23.3, npm 10.9.9 and Chrome; the tested browser version was 154.0.8037.98. This is not a Lovable export or proof of crawling, indexing or native Hostbrid delivery.

Adding forms or your own domain

The sample contact link opens an email client; it does not process a form. Authentication, payments and data submission need additional services and testing. A custom domain has plan conditions and separate registration and renewal costs: check current plans. For this Git-based publishing workflow, explore Hostbrid Projects.