Hostinger AI Builder: Build and QA a Small-Business Site Before You Publish

This workflow covers a small service-business site with Home, Services, About, and Contact pages. A store, membership area, customer portal, or payment flow needs additional acceptance criteria for accounts, orders, payments, permissions, and data handling.

Use agentic mode for a prompt-led build

Hostinger AI Builder currently offers Manual and Agentic modes. Manual mode centers on drag-and-drop editing. Agentic mode generates and changes the site through chat, while still providing Preview, Edit content, Code, an optional Data view, a mobile device toggle, and a button that opens the preview in a new tab. This guide uses agentic mode, so the labels and form-testing steps may not match a site created in Manual mode. (Hostinger AI Builder setup, agentic mode overview)

Before opening the builder, assemble a small source pack. It prevents polished copy from outrunning what the business can prove.

Write unknown for a missing fact. Do not ask the builder to fill the gap. Phrases such as “award-winning,” “trusted by thousands,” “24/7 service,” or “same-day response” stay out unless the business has current evidence for the exact claim.

Generate the first draft from a bounded brief

In the Hostinger dashboard, go to Websites, choose Add website, select AI Builder, and then select Agentic. You can use a temporary domain during the build and connect the custom domain later. Hostinger allows an image or PDF with the initial prompt, and the initial description must stay within 700 characters. (Hostinger AI Builder setup)

Use this prompt as a template and replace every bracketed field:

Create a four-page website for [BUSINESS NAME], a [BUSINESS TYPE] serving
[VERIFIED AREA]. Add Home, Services, About, and Contact pages. Use only the
facts in the attached business brief. Mark missing details as [NEEDS OWNER
INPUT]. The primary action is [CALL / EMAIL / BOOK / REQUEST A QUOTE] at
[VERIFIED DESTINATION]. Do not invent testimonials, ratings, awards, years in
business, licenses, prices, guarantees, response times, or service areas.

The prompt defines the page set, factual boundary, and visitor action. Design directions can follow once the generated structure is usable. Attach the logo, approved photos, or a short PDF containing the source pack if those files will help the builder follow the brand and business facts.

Hostinger recommends a high-level first message followed by focused changes, usually one action at a time. It also recommends prompts of two to five actionable sentences instead of a large request containing many unrelated edits. (Hostinger prompt practices)

Useful follow-up prompts name the page, element, requested change, and fact source:

On the Home page, replace the hero text with the approved headline and service
area from the attached brief. Keep the existing layout and button destination.

On the Services page, show only the six services listed in the brief. Remove
any service, price, turnaround time, or guarantee that is not in that list.

Add a Contact page form with name, email, phone, and message fields. Store test
submissions in Contact Submissions and send notifications to [OWNER EMAIL].

Use Edit content or Select and Edit for a precise text, link, or image correction. Hostinger recommends the visual editor for static text and image changes, which reduces the chance that a broad prompt will disturb an unrelated section. (Hostinger visual editing guide)

Audit the generated copy against the source pack

Review the site page by page before adjusting colors or spacing. For every statement about the business, identify the source in the brief. Rewrite or delete any sentence that cannot be traced.

Check these details first:

• the business name, location, service area, opening hours, phone number, and email;
• service names and exclusions;
• prices, discounts, response times, and availability;
• qualifications, licenses, awards, ratings, testimonials, and customer counts;
• all primary and secondary button labels and destinations;
• photo captions and alt text that identify a real person, place, product, or project.

A plausible sentence is still a failed check when the owner cannot verify it. If the Home page says “licensed and insured” while the source pack is silent, the release status is blocked. If a testimonial is genuine but permission to publish it is unknown, keep it out of the draft.

Check for residue from the build as well. Search every page for bracketed instructions, Lorem ipsum, generic team biographies, placeholder contact details, stock-image watermarks, and links that still point to # or an example domain.

If the page copy itself is still unsettled, the separate Grow AI Skills landing-page copy workflow shows how to tie a headline, benefits, and CTA to a verified product record before release.

Turn the preview into a release test

A visual skim is too easy to pass. Record an action and an observable result for each check. Hostinger’s agentic editor provides a device toggle and a new-tab preview, so you can inspect the draft without publishing it. (Hostinger agentic mode overview)

The keyboard, title, image-text, heading, contrast, and form checks above are a first review, not a claim of full accessibility conformance. W3C’s Easy Checks asks reviewers to verify unique page titles, meaningful headings, image alternatives, keyboard access, logical focus order, visible focus, labels, and understandable errors. Its forms guidance also warns that placeholder text does not replace a label. (W3C Easy Checks, W3C form instructions)

Test the contact form before publication

The form needs evidence from both sides of the workflow. Submit a synthetic record in Preview, open Data, select the Contact Submissions collection, and confirm that the record appears under Test data. Then confirm that the notification reached the specified inbox. Hostinger separates preview submissions from public submissions: test entries appear under Test data, while submissions made after publication appear under Live data. (Hostinger contact-form guide)

Use a recognizable test value and no real customer information. A success message in the preview proves only that the interface displayed a success state. The Test data record proves storage in the preview environment, and the received email proves delivery to the chosen inbox.

If the record is stored but no email arrives, check that the form prompt included the recipient address and inspect the inbox’s spam folder. If submission fails, preserve the error and the last working version before asking the builder for another change. (Hostinger contact-form troubleshooting)

Fix defects without losing a working version

When one prompt creates an unwanted change, use Undo on that response. For an older stable state, use Restore on the relevant message. Hostinger notes that Undo permanently removes the latest message and its response, while Restore removes the messages after the selected point. Restoring one Code changes entry can revert a single file without rolling back the whole message. (Hostinger undo and restore guide)

After a restore, make the next request smaller. “Fix the site” gives the builder no observable target. “On mobile preview, keep the Request a Quote button inside the hero card at 390 CSS pixels without changing the desktop layout” states where the defect occurs and what must remain unchanged.

Keep a simple defect log while reviewing:

Do not mark a defect fixed because the builder says it completed the request. Repeat the original action and record the result.

Prepare the domain and search metadata

Set a distinct meta title and description for every public page by prompting agentic mode directly. Hostinger generates sitemap.xml and robots.txt for a site with a custom domain after publication, so those files belong in the live smoke test rather than the draft checklist. (Hostinger SEO settings)

Connect the intended domain from the Websites list or from the builder. If DNS is managed elsewhere, follow Hostinger’s current pointing instructions. Agentic mode supports Hostinger nameservers or CNAME records for domain pointing; A and AAAA records are not supported. A domain can be connected while the project remains a private draft, and publication is still required to make the site public. (Hostinger domain guide, Hostinger technical specifications)

Before release, record the exact canonical domain, whether www should resolve, who controls DNS, and when any DNS change was made. Hostinger warns that DNS propagation can take up to 24 hours. Do not treat an immediate failure from one network as proof that the site build is broken. (Hostinger publishing guide)

Use a concrete publish gate

The site is ready for the owner to release only when all of these statements are true:

• every public business claim maps to the current source pack;
• no placeholder, invented proof, unused template page, or example link remains;
• navigation, header links, footer links, and the primary CTA pass in desktop and mobile preview;
• the contact form creates a Test data record and its notification reaches the approved inbox;
• keyboard focus reaches every link, button, and form field in a sensible order;
• each public page has an approved title and meta description;
• the custom domain and DNS method are recorded;
• the owner has approved the final page list, copy, images, contact details, and visitor action.

Any failed item keeps the site in draft. A beautiful Home page does not compensate for a broken form, an invented credential, or a booking button that opens the wrong business.

Publish, then run the checks that Preview cannot prove

Open the project from the Hostinger dashboard, click Edit website, and use Publish in the top-right corner. Wait for the process to finish, then open the public URL in a private browsing window. Hostinger recommends allowing a few minutes for published changes to appear and checking them in an incognito or private window. (Hostinger publishing guide)

Run this short live check:

1. Confirm that the custom domain opens the correct site and that the browser shows HTTPS without a certificate warning.
2. Repeat the main navigation and CTA checks on the public URL.
3. Submit a second synthetic form entry. Confirm that it appears under Live data, not Test data, and that the notification arrives.
4. Open the site on a phone using mobile data to reduce the chance that a local cache or one network is hiding a problem.
5. Confirm that the published page titles and descriptions match the approved values, then verify that the generated sitemap and robots file are available on the custom domain.

Hostinger manages SSL automatically, but activation depends on connecting and pointing the domain and publishing the site. HTTPS is forced by default after SSL is active. If the public site is unavailable or shows an SSL error, verify publication, the connected domain, and the CNAME or nameserver setup, then allow for DNS propagation before changing the site itself. (Hostinger SSL guide)

Keep the site public only if the live checks pass. When a live form fails, a domain opens the wrong project, or HTTPS remains invalid after the expected DNS window, record the failure and fix that release issue before directing customers to the URL.