How to Publish an AI-Built Website on Your Own Domain
Publish an AI-built website on your domain. Deploy the right build, connect DNS without disrupting email, enable HTTPS and verify the public release.
To publish an AI-built website on your own domain, deploy the website to a compatible host, add the domain to that hosting project, then configure the required DNS records and verify HTTPS. Open the domain independently after release and test the visitor’s actual journey. A preview link or successful build is not proof that your own domain serves the intended website.
If the website needs WordPress editing and Niwa customer assistance, publish it on a working WordPress installation with the approved theme and integrations. Static hosting can serve generated files, but it does not become a live WordPress installation by receiving a theme ZIP.
This guide follows a fictional local business releasing its first generated website. It focuses on the practical release, rather than comparing hosting prices or migrating an established site’s content.
Identify what you are deploying
Find out whether you have a static site, an application with a build step, or a WordPress theme. Ask the development tool to identify the entry point, build command, output directory and required backend services.
For a static website, the deployable files include the page HTML and its assets. For a framework project, the source may need to be built before the host can serve it. A project folder containing dependencies and development tools is different from the production output.
A useful handoff request is:
Identify the production build for this website and the host type it needs. Run the existing build process and show the output directory. List any server functions, private configuration and connected services. Explain how to deploy the accepted revision and verify it at the public domain.
Do not let the answer replace the evidence. Check that the build finished and that the named output contains the expected pages and assets. Save the accepted source revision or deployment package so you can identify what is being published.
Deploy to the host before changing DNS
Use a host compatible with the website’s runtime. A static frontend can use static hosting; an application with server behavior needs an appropriate runtime and configuration. A WordPress site needs WordPress hosting and its database.
Cloudflare Pages Direct Upload is one option for prebuilt static assets. In its dashboard flow, create a project, upload the ready-to-serve folder or ZIP, and deploy it. Use the resulting project address to inspect the site. The documentation also describes Wrangler uploads. Cloudflare Pages Direct Upload.
Choose the release method deliberately. A Direct Upload project cannot later switch to Git integration in place; the documented route requires a new project for that change. Dashboard drag-and-drop also does not compile a Pages Functions folder. Use the documented deployment method when the project has that backend requirement.
At the host’s temporary address, test images, navigation, internal pages and forms. Confirm that private service configuration is set in the right environment. Resolve a broken production build before pointing the business’s domain at it.
Keep the domain and its existing services under control
Sign in to the registrar and identify the account that owns the domain. Separately identify the provider currently managing DNS. These may be different accounts.
Save the existing DNS records before making changes. The domain may already support business email, verification records or another subdomain. Changing the website destination should preserve those services. If you change nameservers, reproduce the needed records at the new DNS provider before the switch.
Choose the public address. For example, the business may use example.com as its main website and redirect www.example.com to it, or use the reverse arrangement. Configure the other address deliberately so visitors do not reach an error or a second inconsistent copy.
The registrar account should remain accessible to the owner, with domain renewal understood. Record who manages hosting and DNS so a future website edit does not depend on recovering an unknown account.
Add the domain to the hosting project first
In the hosting project’s domain settings, add the exact hostname you intend to use. Follow the provider’s verification and DNS instructions for that project. Avoid copying records from an unrelated tutorial or another customer’s account.
For Cloudflare Pages, an apex domain such as example.com requires the domain to be a Cloudflare zone with its nameservers pointing to Cloudflare. A subdomain can use an external DNS provider with the appropriate CNAME. Associate the domain with the Pages project through its Custom domains flow before configuring the external record. Cloudflare Pages custom domains.
Netlify also provides a flow to add a custom domain and configure DNS, using Netlify DNS or an external provider. If you use Netlify, follow the records it supplies for your selected arrangement. Netlify domain setup.
Wait for the provider’s domain validation and HTTPS provisioning to complete. Inspect the actual status instead of assuming that a saved DNS record means the public site is ready.
Verify HTTPS and both public hostnames
Open the intended HTTPS URL in a browser outside the development preview. Confirm that the certificate is valid and the page contains the accepted content. Inspect the second hostname and its redirect to the chosen main address.
Check that images, scripts and styles also load over HTTPS. Development URLs and local file paths can survive in generated code, leaving the main page visible but some assets broken. Fix them in the project, deploy a new identified revision and repeat the check.
Verify links to important internal pages. For an application with frontend routing, open a detail page directly and refresh it. A route that works after clicking from the homepage can still fail on a direct request if hosting has not been configured for that application.
Inspect the page title, description and canonical URL at the public domain. The release should not keep a preview hostname as its preferred address. A publicly loading website does not by itself establish search indexing or rankings.
Test connected services at the real domain
Send a test enquiry through the public website and confirm it at the receiving destination. Check the success and failure behavior. Some services use domain-specific configuration, so a form that worked in preview may still need production setup.
If the site accepts payments, test the configured checkout and order confirmation through the provider’s appropriate test procedure. If it offers booking, confirm that the destination shows real availability and completes a reservation. Check business email after DNS changes as well.
For a WordPress site, install and configure Niwa using the setup guidance. Test its public presence and answers using approved business content. If WhatsApp assistance leads to booking, open the connected website booking flow and verify the customer’s selection and completion there.
A supported own-subscription connection has no additional Niwa AI usage fees or Niwa-imposed usage caps. The provider’s terms and limits still apply, and API billing is separate. Confirm the supported connection in the actual setup instead of treating every provider account as interchangeable.
Record the release and make the next update repeatable
Keep the source revision or package, hosting project, domain settings and checks together in a short release record. Include the deployment time and the person responsible for restoring the previous working version if needed.
For the next update, change the source, review the preview, deploy and inspect the public address again. Editing the development project does not necessarily update the live site. Explain that workflow to the owner before handing over access.
On WordPress, Niwa’s website maintenance agent can support authorized content work after launch. The proof is the changed public page, with the correct domain and accepted content.
Niwa Business is USD 150 for a custom WordPress website or migration, hosting, maintenance and AI adaptation. Existing WordPress owners can use the standalone plugin. To discuss publishing an editable business site, send the Niwa team the generated project, domain and required customer journey.
