Built your website with AI? Check these things before you publish

AI website builders can help you get from an idea to a working preview quickly. A preview is a useful milestone, but before sharing the site with customers, check that the page says the right things, works on the devices people use, and sends enquiries where you expect.

Here is a practical pre-launch checklist for a small business website. It is a readiness check, not a security audit or a guarantee that every project is ready for production.

1. Check the goal and the facts

Choose one main action you want a visitor to take: call, message, request a quote, or visit your shop. Make that action easy to find and make sure its destination is correct.

Read every heading, service description, price, location, opening hour, and claim. AI-generated copy can sound confident while getting details wrong. Replace placeholders, invented specifics, and claims you cannot support. Confirm you have permission to use every logo, photo, font, and other asset.

2. Try it on a phone and a computer

Open the preview at a narrow phone width and on a desktop. Check that text is readable, buttons can be tapped, images fit, navigation works, and nothing spills sideways or disappears behind another element. Try the page with the browser zoomed in as well.

Responsive layouts should adapt to the available screen size; a desktop screenshot alone cannot show whether the phone layout is usable. MDN’s responsive design guide explains the underlying approach.

3. Test every link and contact path

Tap each navigation item, phone link, email link, map link, and call to action. If the page has a form, submit a test using information you control. Check the confirmation message and verify that the submission reaches the intended inbox or system. A button that looks right but leads nowhere is still broken.

Do not test with real customer data. Do not collect information you do not need, and do not put passwords, API keys, or private tokens into page text or public source files.

4. Confirm the domain and secure connection

Decide which account owns the domain and hosting, and who is authorized to make changes. Visit the intended public address over HTTPS. Check that the correct page appears, that old preview links are not the only way to reach it, and that any redirects go to the right place.

Keep ownership and access clear. Use the provider’s invitation or collaborator feature when another person needs access; do not send passwords or one-time codes in a message.

5. Check basic search and sharing details

Give the page a clear title and description that match its actual content. Check that the page is not accidentally marked `noindex` if you want it eligible for search. If the site has a sitemap, make sure it lists the pages you intend search engines to find. A sitemap helps discovery; it does not promise indexing or rankings. Google’s documentation explains robots meta tags and sitemaps.

Also preview the page when shared in a message or social post. Confirm the title, description, and preview image are appropriate and do not expose draft information.

6. Know when a checklist is not enough

If you have a simple informational page and the checks pass, you may be ready to publish it yourself. Consider getting technical help when the build fails, files or images are missing, the domain or HTTPS setup is unclear, a form or integration does not work, or the live site behaves differently from the preview.

An app with logins, payments, databases, customer data, or multiple integrations needs a more careful review than a static business page. First clarify what the system does, what data it handles, and which accounts and code you own. A launch review is not automatically a security audit, and not every generated project will be suitable for a quick deployment.

7. Save a handoff record

Before calling the site done, keep a copy of the source or export where available, note which provider and domain are in use, record who owns each account, and write down how to change or take the site offline. If someone helped with the launch, agree who handles later edits, renewals, backups, and support.

Want a second set of eyes?

FlexTech can first review the current preview, the intended public result, and the specific issue holding up launch. If the work fits, the next step is a written scope covering access, changes, checks, ownership, and any costs before work begins. Share a public preview link and describe the blocker; do not send passwords or secret keys.

You can also view the KotaCycle Repair fictional concept demo. KotaCycle Repair is fictional and the page is a layout example, not a client project or customer result.