When AI builds your website: what you get and what you lose
Author: Milos ZekovicReading time: 11 min
Wix, Framer, and Squarespace can generate and publish a website on their platforms. ChatGPT and Claude Code can generate files that you host yourself. Both approaches can produce a convincing first version without a conventional web project, but they still leave strategy, conversion, SEO, accessibility, and maintenance to a person. Here is what you actually get, what you may give up, and when a proper website project becomes the cheaper decision.

Wix, Framer, and Squarespace can generate and publish a website on their platforms. ChatGPT and Claude Code can generate files that you host yourself. Both approaches can produce a convincing first version without a conventional web project, but they still leave strategy, conversion, SEO, accessibility, and maintenance to a person. Here is what you actually get, what you may give up, and when a proper website project becomes the cheaper decision.
Speed is real. So are the trade-offs
An AI website builder can produce a live page from a short prompt. I now see that happen in two main ways. Hosted builders such as Wix, Framer, and Squarespace offer some version of "describe your business and get a website." People also ask ChatGPT, Claude, or Claude Code to generate HTML, a React app, or an entire repository, then publish it on Vercel, Netlify, or conventional hosting.
The result can look finished. But looking finished is not the same as being ready to sell, rank, convert, or remain useful as the business changes.
The useful question is no longer whether AI can generate a layout. It can. The useful question is what you get and what you give up when a tool publishes a website or hands over generated files without anyone taking responsibility for the underlying decisions.
I do not have a problem with AI generating the first version of a website. I have a problem when nobody qualified reviews that version before it becomes the public face of a business.
This is different from using AI inside a properly managed project. I use AI to draft, explore, refactor, test, and review, but I still own the decisions and the final result. That workflow belongs in how I use AI in web development. This article is about the other offer: a generated website that goes live with very little human judgment around strategy, UX, conversion, or long-term ownership.
What an AI builder actually delivers
Most hosted AI builders provide a practical bundle:
- a template-based layout adapted to your prompt
- copy generated from a short description of the business
- a live URL with hosting included
- a visual editor for changing text, images, and sections
- forms, a blog, basic analytics, or a shop, depending on the platform and plan
For a one-page test, a temporary event, or a company that barely needs a website yet, that may be enough. Speed is the honest benefit. You can send someone a URL this week, and the initial cost is usually lower than commissioning a complete project.
These tools have also improved. In 2026, the output is often more polished, responsive, and editable than the obvious AI-generated templates people were publishing a few years ago. The problem is no longer that every generated website looks broken. The problem is that visual polish can hide missing business decisions.
I still come across websites that look "done" because they have a hero, three cards, a testimonial row, and another CTA. Yet visitors cannot clearly tell what the company sells, who it is for, or what they should do next. That is not a missing animation or something another prompt will necessarily solve. It is a missing decision.
ChatGPT and Claude Code generate files, not a finished product
The same "make me a website" request now goes to chat tools and coding agents as often as it goes to Wix-style builders. I see generated HTML copied into hosting, a ZIP file uploaded to a server, or a repository pushed to Vercel and treated as a finished website.
This route can look more custom than a hosted template, and you will often own the generated files. But owning files does not automatically mean owning a usable product.
What this approach typically gives you:
- code you can open and modify in an editor
- a page that runs locally
- a deployable project, if the hosting setup has been configured
- less platform lock-in than a closed website builder
What it still does not automatically do:
- define the offer or decide what belongs on the first screen
- validate accessibility, performance, analytics, and security before launch
- configure DNS, forms, redirects, backups, consent, and monitoring correctly
- provide a safe way for non-technical editors to update content
- decide who will maintain the dependencies and integrations six months later
I use ChatGPT, Claude, and Claude Code on real WordPress and frontend projects. AI-assisted code can make up a large part of the first implementation, but that is still only the starting point. I manually review the layout across screen sizes, test keyboard navigation, inspect network requests, check headings and metadata, verify forms and analytics, and look for security and performance problems before anything goes live.
AI saves me time. It does not take responsibility for the release.
That is the real difference, not simply which model generated the files. A prompt that says "build me a website," followed by a publish command, is not the same as how I use AI when a client has to depend on the result.
A generated repository can fail the first-screen test just as easily as a generated Wix template. File ownership is useful, but it is not the same as having a website that can support the business.
Generated UX still has to pass the first-screen test
Generated pages tend to fall back on familiar marketing patterns: a large headline, a vague supporting sentence, three benefit cards, a row of logos, and a generic CTA.
Those patterns are not automatically bad. They are simply not specific enough on their own.
The first screen is usually where the problem becomes visible. If a stranger cannot explain the offer after spending a few seconds on the mobile version, the rest of the page will rarely rescue the visit. I use that test in what makes a good homepage. A builder or coding agent can fill the sections, but it cannot know whether the final message is convincing without real business context.
Patterns I often see include:
- slogans that sound confident but communicate very little
- sections that could belong to almost any company in the same industry
- several CTAs competing because the original prompt listed every service
- important proof placed near the bottom of the page or omitted entirely
- forms that ask for information nobody needs
- no clear connection between the website and the actual sales process
A website can look good and still not convert. AI-generated websites fail in this way surprisingly often because visual completeness is much easier to automate than a coherent conversion path.
Accessibility creates another gap. A generated theme may have reasonable colours and still include unlabeled controls, unclear focus states, poor heading structure, keyboard problems, or images without useful alternative text. A strong Lighthouse score can be helpful, but I would not treat it as a complete WCAG 2.2 review.
The same applies to performance. I have taken a marketing website from a GTmetrix B to an A, but that did not happen because I asked AI to "make the website faster." It came from measuring the actual bottlenecks, changing how fonts and videos loaded, splitting heavy JavaScript libraries, and checking the result after each change.
AI helped with parts of that work. The improvement came from knowing what to measure, what to change, and what not to break in the process.
SEO is not a publish button
Publishing a URL is not an SEO strategy. Thin AI-generated copy, repeated heading structures, and missing service or location pages make it difficult to compete for searches that can actually bring work.
Google does not penalise content simply because AI was involved in creating it. Its current guidance on generative AI content focuses on accuracy, quality, relevance, and whether the page provides value. At the same time, generating large amounts of low-value content to manipulate search results can violate Google's spam policies.
The problem is not whether a person or a model wrote the first draft. The problem is publishing content without adding expertise, evidence, or a reason for the page to exist.
What AI builders usually do not decide well on their own:
- how real services map to search intent
- which service, industry, or location pages deserve to exist
- how to write pages that are specific enough to be useful and credible
- how internal links should reflect the way people explore the offer
- which technical SEO settings need to remain under your control
- what content should be maintained after launch and who will maintain it
Discoverability in 2026 also extends beyond a traditional list of blue links. Search results increasingly include AI-generated summaries and answers, but there is no separate "AI SEO" switch that makes a vague website visible. Clear factual language, crawlable content, consistent business information, structured data, and original evidence remain more useful than publishing another batch of generic pages.
If SEO is part of how the business finds clients, start with what actually works for small businesses, not with a checkbox labelled "SEO included."
Maintenance, lock-in, and taking the website with you
Hosted AI builders usually keep the design system, CMS, and publishing process inside their platform. That is convenient until you need something the plan does not support or decide that you want to leave.
Portability also varies. Wix sites must remain on Wix infrastructure, while Framer does not offer HTML export for self-hosting. Squarespace can export some content, products, and contacts, but not the complete design and functionality as a ready-to-run website.
You may own your content and domain while still needing to rebuild the website itself.
Questions I ask before anyone commits to a platform:
- Can you export the content in a format another system can use?
- Can you move the design and functionality, or only the text and data?
- Who owns the custom code, if any exists?
- What happens to forms, redirects, analytics, and DNS if you cancel?
- Who is responsible when an integration or platform update breaks something?
- How difficult will a rebuild be if the business outgrows the builder?
Those questions sit alongside choosing WordPress, custom code, or a visual platform. An AI builder is still a platform choice. The difference is that the first version can appear before anyone has stopped to answer those questions.
I have reviewed websites where the platform was perfectly adequate at the beginning, but the business later needed multilingual content, more control over checkout, or an integration that did not fit. At that point, more time went into working around the builder than the original website had saved.
The first version looked cheap. It had simply delayed the project the business eventually needed.
When an AI builder can be enough
An AI builder can make sense when:
- the offer is simple and the website is mostly a digital calling card
- the campaign or event is short-lived
- the budget is genuinely too small for a commissioned project and the owner accepts that a rebuild may be needed later
- you need a public URL quickly to test whether there is any interest
- someone is still responsible for checking the content, forms, mobile experience, accessibility, and basic analytics
It is usually a weak fit when:
- you sell an offer that depends heavily on trust, expertise, or a distinctive process
- paid traffic lands on the website and needs to convert
- you need custom integrations, multilingual content, or complex permissions
- multiple editors need to update content without breaking the layout
- performance, accessibility, or long-term ownership are important
- the website is expected to become an active part of sales or operations
A generated website can still be useful as a prototype, including one created with ChatGPT or Claude Code. I would rather review a working AI-generated draft than start with a blank brief. We can see what works, remove what does not, and decide what deserves to become part of the real website.
The mistake is not using AI to create the draft. The mistake is treating the draft as the finished business website.
Use AI as a multiplier, not as the final decision-maker
AI in the hands of someone responsible for the outcome and AI publishing without meaningful review are two very different things. One accelerates research, drafting, development, testing, and iteration. The other can publish a plausible-looking collection of assumptions under your brand.
If you want AI to remain useful after launch, it can support search, lead qualification, content workflows, customer service, or internal automation. That belongs with smart web with AI and automation, not with an unattended generate-and-publish step.
If you already have an AI-generated website, the next step is rarely to add more sections. It is to decide whether the offer, the first screen, the technical foundation, and the ownership model can support the business over the next year.
If they cannot, a proper website project is not simply an upgraded version of the generated draft. It is a different job.
Want to check whether an AI-built website is enough?
Send me the URL and a short note explaining what the website is supposed to achieve. I will tell you what I would keep, what I would not scale, and whether a conversation about a proper project is worth your time.