AI Website Builders: What They Do Well and Where They Fall Apart

A prospect sent us a URL last March with the message “we already built it, we just need you to make it live and fast.” The site had been generated in about eleven minutes by an AI website builder. It looked fine in a screenshot. Then we ran it: 4.6MB of uncompressed hero PNGs, an LCP of 5.2 seconds on throttled 4G, every heading on the page rendered as a styled div, and a contact form whose action pointed at a placeholder URL that had never been wired up. They had been collecting nothing for nine days.

That is not an argument against AI in web work. We use it daily. It’s an argument about where the technology is genuinely strong and where it quietly hands you a liability you won’t discover until an auditor, a customer, or Search Console tells you.

Here’s the honest version, from someone who has had to clean up after these tools and also ship faster because of them.

What these tools actually are in 2026

“AI website builder” now covers at least three different products, and conflating them is why so much of the discourse is useless.

Prompt-to-site platforms. You describe a business, it generates pages inside a proprietary editor. Wix ADI’s descendants, Hostinger, Framer’s AI features, Durable. The output lives in their runtime. You usually cannot export usable code.

Prompt-to-code generators. v0, Lovable, Bolt, and the coding agents in Cursor or Claude Code. These emit real React, Tailwind, or plain HTML that you own. The quality ceiling is much higher and so is the floor you fall through when it hallucinates an API.

AI features bolted onto existing builders. Elementor AI, Divi AI, Squarespace’s copy tools, Gutenberg plugins. These generate blocks or sections inside a stack you already have. The lowest risk and the lowest ceiling.

The trade-offs are not the same across these three. A platform that cannot export is a different bet entirely from a generator that hands you a Git repo. Decide which category you’re evaluating before you read another comparison table.

Where an AI website builder genuinely wins

Three situations where we reach for one without hesitation.

Killing the blank canvas. Generating eight layout directions for a pricing page in four minutes is real value. Not because any of them ship, but because arguing about a concrete thing is faster than arguing about an abstraction. We’ve cut the “what should this section look like” conversation from a week of Figma rounds to a single call.

Content scaffolding at volume. Forty service pages for a multi-location trades business, each needing a structurally identical but locally distinct page? That is a genuinely good use. The structure is the same; only the tokens change. Just read every one before it goes live, which is the whole point of automating content without producing slop.

Sites nobody will maintain. A one-off event microsite with a six-week lifespan, a personal portfolio, an internal tool. If the total lifetime cost of the thing is under a day of developer time, the quality argument barely matters. Ship it.

Also worth crediting: modern ai web design tools have gotten good at typographic scale and colour contrast defaults. Generated palettes in 2026 usually pass WCAG AA for body text without intervention. That was not true in 2023.

Where they fall apart

Semantics you cannot see

This is the big one. A model optimises for the rendered picture, and nothing in the picture tells you whether a heading is an h2 or a bolded span. We’ve audited generated pages with six h1 elements, no main landmark, and a “card” pattern where the entire tile is a clickable div with an onclick handler and no keyboard affordance at all.

<!-- What a generator handed us -->
<div class="text-3xl font-bold mb-4">Our Services</div>
<div class="card" onclick="location.href='/seo'">
  <div class="text-xl font-semibold">SEO Audits</div>
  <div class="text-sm">From 1,200 GBP</div>
</div>

<!-- What it needed to be -->
<h2>Our Services</h2>
<div class="card">
  <h3><a href="/seo" class="stretched-link">SEO Audits</a></h3>
  <p class="text-sm">From 1,200 GBP</p&got;
</div>

The first version is unreachable by keyboard, invisible to a screen reader’s heading list, and gives Google nothing. It looks identical. That gap between looks-identical and is-identical is the entire problem, and it maps almost exactly onto the failures accessibility auditors find over and over.

The states nobody prompted for

Generated pages show the happy path. Populated cards, three testimonials, a filled form. Ask for the empty state, the 400-character product title, the validation error, the loading skeleton, the mobile nav with fourteen items, and you get either nothing or something invented on the spot. On real client sites, roughly a third of our front-end work is edge states. A builder gives you close to zero of it.

Pages instead of a content model

Most prompt-to-site platforms think in pages. Real businesses have entities: properties, courses, practitioners, case studies. The moment you need “every case study tagged with this service, sorted by date, with a filterable archive,” the page-based model stops helping and you’re either exporting or rebuilding. This is the single most common reason clients come to us three months after generating a site.

Forms and everything server-side

Generated markup routinely includes a form with action="#" or a fake endpoint. Even when the builder provides submission handling, you often get email-only delivery with no CRM route, no Slack notification, no consent logging, and no retention policy, which matters if you’re anywhere near GDPR consent and retention obligations. Always submit a test lead before launch. Always check where it lands.

Performance, still

Full-bleed video heroes, four webfont weights, a scroll library loaded for one fade-in. We’ve seen generated pages ship 1.1MB of JavaScript for what is functionally a brochure. The fix is not exotic: compress the images, subset the fonts, drop the animation library. But nothing in the tool tells you it’s a problem, and the client’s Lighthouse score is your reputation after launch.

The export trap

“Export your code” is the feature everyone checks and almost nobody tests properly. Do this before you commit: generate a real page, export it, and try to change the primary brand colour and the header on every page.

On the better prompt-to-code tools you edit a token and rebuild. On several platform exports you get a folder of standalone HTML files with the colour hardcoded 200 times and a duplicated header in each one. The export is technically real and practically worthless, because you’ve traded a proprietary editor for a codebase with no abstraction in it.

Ask one more question: can it round-trip? If you edit the exported code, can you push changes back into the AI editor? Almost always the answer is no. The export is a one-way door, so treat the moment you walk through it as the moment your maintenance costs become yours.

A decision framework that survives contact with clients

Use an AI builder when:

• The site is under roughly ten pages with no content model behind it.
• Nobody will need to restructure it within twelve months.
• No regulated accessibility requirement applies (no public sector, no enterprise procurement, no EAA scope in the EU).
• The budget genuinely cannot support a developer, and something imperfect beats nothing.

Don’t use one when:

• The site is a revenue channel where a 1.5 second LCP improvement is worth money.
• You need custom post types, filtering, multilingual, or an integration with anything.
• Someone other than the original author will maintain it.
• Brand consistency across 50-plus pages matters.

The middle path most agencies land on is a component-based starting point plus AI for the parts that are genuinely generative. A Bootstrap 5 system like Canvas gives you pre-built, semantically correct sections and a token layer, and you use a model to draft copy, generate variant ideas and write the repetitive markup. You keep the structure a human designed. That is a materially different risk profile, and the numbers behind it are in our cost breakdown of templates versus builders versus custom builds.

How we actually use AI in production

Concretely, on a typical client build in 2026:

1. Discovery and IA stay human. Sitemap, entity model, URL structure. A model can critique these; it should not own them.
2. Moodboard and direction: AI-heavy. Image generation for mood, layout variants for discussion. We covered this pipeline in detail in AI in the design process.
3. Markup: AI-assisted, human-reviewed. The model writes the section from our component library’s conventions. We review heading order, landmarks, focus states and alt text every time. That review is roughly 15 minutes per template and it is not optional.
4. Copy: AI first draft, human edit, always. Generated copy has a tell. It says “solutions” a lot.
5. Performance budget enforced in CI. Lighthouse CI with hard thresholds, because generated assets will blow past them silently.

The interesting shift recently is not the builders at all. It’s tool-using agents wired into real project context, which is why MCP matters more than another website builder AI demo. An agent that can read your design tokens and your existing components produces output that fits the codebase. A generator working from a text prompt produces output that fits nothing.