If you have been on X this week, the mood around vibe coding has shifted. The honeymoon posts are giving way to a more useful argument: demos ship, production breaks. One agency account put it plainly — an AI-generated app can look ready and still be unready to represent a business. Even cautious teams have started treating vibe-coded output like any other untrusted change: useful, fast, and not live until someone reviews it.
That conversation is usually about apps. It applies just as hard to marketing sites.
A chat tool will happily give you a polished homepage, a pricing table, and a contact form in an afternoon. In the browser, it looks like a website. Then you do the unglamorous checks: curl the URL, ask who will edit a typo next month, and write down where the site will live when the trial ends. A lot of those demos fail quietly.
The demo is not the asset
There are now two common ways to get a site out of a prompt.
One is a coding agent — Cursor, Claude Code, Lovable, and the rest — that generates a repo or a preview. The other is a hosted "AI site" runtime, including ChatGPT Sites. As of early November 2026, paid ChatGPT plans can build, publish, and host a site at a chatgpt.site address. That path still does not register a custom domain, run every framework, take payments natively, or give you the post-launch content workflow a business site needs.
Both can be the right tool for a prototype, an internal tool, or a weekend experiment. Neither is automatically a business website.
A business website has to survive contact with customers, search crawlers, and next quarter's edit. That means:
- The public URL is a domain you control, not a rented subdomain.
- The HTML a crawler receives contains the actual copy, not an empty shell that only fills in after JavaScript.
- Someone can change a price, a service page, or a blog post without opening a new chat and hoping the model remembers last week's facts.
- You can leave. Source export, or at least a path onto infrastructure you own, is not a nice-to-have.
If any of those are missing, you have a demo with a nicer typeface.
A production bar you can run in half an hour
You do not need a consultancy to decide whether the preview is shippable. Run these checks on the preview URL before you point a domain at it — or before you tell a customer the site is live.
1. What does a GET request actually return?
Open the preview, then fetch the same URL with curl -sL (or "view source," not DevTools' rendered DOM).
- Pass: the page title, the main heading, and a meaningful paragraph of copy are in the raw HTML.
- Fail: you get a nearly empty document and a JavaScript bundle. Some Lovable apps have this exact gap: they look finished in a browser and almost blank to a crawler.
Search engines and AI answer engines are not required to execute your client bundle the way a laptop does. If the text is not in the response, do not assume it will be indexed or quoted.
2. Who owns the URL and the hosting?
Write down, in one sentence, where the site will run after you publish:
- A vendor subdomain (
something.chatgpt.site,*.lovable.app, and similar) - A custom domain on the vendor's infrastructure, with no export
- Your domain, on a cloud account you control, with a path to take the source elsewhere
The first is fine for a preview. It is a weak place to print on a business card. The second can work, until you want to leave. The third is the one that still exists if the tool changes its plan, its runtime, or its mind.
3. Can you edit the site next month without starting over?
A marketing site starts changing the week after launch: a new offer, a typo in the legal page, a blog post, a localization. Ask:
- Is there a CMS or an admin a non-engineer can use?
- If the only edit path is "open a new chat," what happens to last month's approved copy?
- When you correct a fact, do existing pages update, or does the model invent a slightly different company?
The operational test is simple: make one factual change now, and confirm you could do it again in 30 days without regenerating the whole site.
4. Are the boring search files real?
Before launch day, confirm these exist and are not placeholders:
- A unique title and meta description per indexable page
- Canonicals that point at the URLs you intend to keep
- A sitemap that lists those URLs, and a robots.txt that does not block them
- A deliberate policy for AI crawlers, not a default that appeared because a template included a file
- An
llms.txtonly if you actually want assistants to use it — and if you ship one, it should list real, important pages
We keep a zero-to-indexed launch plan with pass/fail tests for a brand-new site. Steal the launch-day checks even if you built the pages by hand.
5. Who approves what goes live?
Vibe coding is fast because it skips review. That is the point of a prototype, and the risk of a public company page. Name a person who will read the preview — prices, testimonials, claims, redirects — and who can reject an invented metric on sight. An agent can draft. A person should publish.
What we do in PolyDraft, and what we do not claim
This post is written by the PolyDraft team, so here is the honest version.
An AI website builder in our sense is not "describe a company, get a pretty landing page, hope." You describe the business or paste a public URL. The agent researches, plans, writes, builds, and quality-checks a complete site. You inspect a live preview, fix anything that is wrong, and subscribe only when you are ready to publish. The deployed site runs on your domain in your cloud account. Agency plans include source-code export. Domain and cloud costs are separate.
We do not invent customer traffic results. A recurring unsupervised "just publish whatever the model suggests" cycle is product direction, not a current feature. Further research and edits are requested in chat and reviewed before they go live.
If you are building with your own agent stack, you can still hold the same bar: raw HTML that contains the copy, a domain you control, an edit path that is not a disposable chat, and a human who signs off.
Do this before you flip DNS
- Curl the preview. If the copy is not in the HTML, fix rendering first.
- Write down the production host and who owns the account.
- Edit one fact — a price, a headline — and confirm you can do it again next month.
- Check title, canonical, sitemap, and robots.txt on the preview, not after the press release.
- Have a second person read every claim.
- Only then point the domain.
Vibe coding is still a fast way to get a layout. It is a poor reason to skip the production checks a marketing site has always needed.




