AI Website Prompts: Six That End at a Live URL

Copy any of the six below into Claude or ChatGPT and you get a page. Copy the fifth one and the page gets an address you can send to somebody.

That last part is the whole reason this list exists. Prompt collections stop at the code, which is the easy half. The prompts here are ordered the way the work actually goes: state the product, get the page, interrogate the vague parts, change one section without wrecking the rest, publish it, then collect remarks and fix them in the same draft.

What makes a website prompt work

Three things, and all three come from the people who build the models.

Anthropic's prompt-engineering guidance puts specificity first: "The more specific you are about what you want, the better the results." Their list of what a working prompt carries is short. Explicit instructions, context and motivation for why the thing matters, constraints, an example where format is what you care about, and permission for the model to say it is unsure instead of guessing. Lead with a verb.

OpenAI's guide for GPT-5 says something that sounds like the opposite and is not: modern models need less scaffolding, so shorter and clearer beats longer and more elaborate. What they want up front is context. Who the model is, what it is doing, what rules it follows.

Lovable's documentation adds the part that is specific to websites. Before you ask for pixels, answer four questions about the thing you are building.

Every prompt below is a way of putting those answers in front of an agent in the order it can use them. Where a prompt borrows a documented pattern, it says so.

Prompt 1: the brief

Use this when the site does not exist yet and you have not decided what it says.

I want a one-page website. Before you write any code, restate my brief back to
me in four lines:

1. What this page is.
2. Who it is for.
3. Why they would read it.
4. The one action I want them to take.

Then list the sections you would build, in order, with one line each on what
that section has to accomplish. Do not write code yet. If any of my four
answers is too vague to design from, say which one and what you need.

Here is what I have: [two or three sentences about the business, the audience,
and the action].

Why it is shaped this way: the four lines are Lovable's four planning questions, and the closing instruction is Anthropic's permission-for-uncertainty principle. A model that is allowed to say "this is too vague" will do it, and a model that is not allowed will invent something plausible instead. The "do not write code yet" line matters more than it looks: once there is code on screen, both of you start editing instead of deciding.

Prompt 2: the one-page site

Use this once the brief survives being read back to you.

Build the page we just agreed on as a single static bundle: index.html plus one
style.css, no build step, no framework, no client-side router. Everything has
to work when the files are served as-is from a static host.

Style: [two style words, for example "minimal and premium"], and specifically:
oversized headline, high contrast, one accent colour, generous whitespace,
system fonts.

Content: use the real copy from my brief. No lorem ipsum, no placeholder
company names, no stock-photo captions describing photos we do not have.

Structure, in this order: [your section list from prompt 1].

Why it is shaped this way: the style-word-plus-specifics pairing is straight out of Lovable's documentation, and it works because "minimal" alone is a mood while "oversized headline, one accent colour" is an instruction. The constraint block is the part people skip, and it is the part that decides whether the result can be published at all. Ask for a framework with client-side routing and you get an app that needs a build step and a server to rewrite unknown paths to the entry file. Ask for a static bundle and you get files that a static host serves exactly as they are.

The "no lorem ipsum" line saves a whole round. Agents fill gaps with placeholder text by default, and placeholder text hides every layout problem that real copy exposes.

Prompt 3: ask me questions first

Use this when you can feel that you have underspecified something but cannot tell what.

Ask me any questions you need in order to fully understand what I want from
this page and how I envision it. Ask them all at once, numbered, then wait for
my answers before building anything.

Why it is shaped this way: the first sentence is Lovable's own documented clarification technique, quoted as they wrote it. The additions are the two things that make it usable. "All at once, numbered" stops the drip of one question per message, and "wait before building" stops the agent from answering its own questions and proceeding.

This is the cheapest prompt on the list and it is the one that most often changes the output. Expect four to eight questions, and expect at least one of them to be something you had genuinely not decided.

Prompt 4: change one section only

Use this after the page exists and something in the middle of it is wrong.

Change only the pricing section.

What to build: three plan cards side by side, the middle one marked as
recommended, monthly price large and the feature list small.
Where it goes: replacing the current pricing block, same position on the page.
What stays untouched: the header, the hero, the footer, style.css outside the
pricing rules, and every other section's markup.

Show me the diff for the pricing block before you apply anything else.

Why it is shaped this way: what-to-build, where-it-goes, what-stays-untouched is Lovable's boundary format, and it exists because an unbounded edit request invites a rewrite. Agents are helpful. Ask one to fix the pricing section and it will notice your header spacing on the way past.

If you have already been through a few rounds of this, the pattern behind it is worth reading on its own: re-prompting to edit is the habit, and this prompt is the shape it takes when the edit has to stay in its lane.

Prompt 5: publish it

This is the one that separates a preview from a website. Connect Birta to your agent once, then this prompt works in the same conversation that wrote the page.

claude mcp add --transport http birta https://birta.dev/mcp

The endpoint is https://birta.dev/mcp, and the setup lives in the Claude Code guide. Then:

Publish this site through Birta.

Create a project called [name], write the files we just built into it with
write_file, create a draft version, and publish it. Then give me the version's
address.

If anything in the bundle would not be served correctly from a static host,
tell me before publishing instead of publishing it broken.

Why it is shaped this way: create_project, write_file, create_version and publish_version are the connector's actual tools, so naming them keeps the agent from improvising a workflow. create_version and publish_version each return that version's own permanent address, which is what you send to somebody. It is the version's address, not the live site's, and that distinction is what makes the next prompt possible.

Two honest notes. A custom domain needs a Solo or Pro plan, so on the free tier your address is a Birta subdomain and the "made in Birta" badge stays on. And the free tier is a real free tier rather than a countdown, which is a longer story in free web hosting.

Prompt 6: collect remarks and fix them in the same draft

Nobody else's prompt list has this one, because it needs somewhere for the remarks to live.

Send me the version address to share with my client.

After they have marked it up, read their remarks with list_version_comments,
make each change in this same draft, and publish a new version. Tell me which
thread numbers you addressed and which ones you could not.

Why it is shaped this way: the person you send the link to needs no account. Version access defaults to a link, a guest passes a signed handoff and gets a nickname, and they mark remarks straight onto the page in the browser, pinned to the element they are talking about. Your agent reads those threads by number, with the author and time on each message, and thread numbers are permanent so a remark can be named later.

One limit to know before you promise anything: the agent reads remarks and cannot reply in the thread. The comments endpoint refuses agent writes. It also cannot mark a thread resolved. Only a project member can do that, in the browser. So the loop is "they mark, the agent fixes, you resolve", and anyone who tells you their agent holds the conversation is describing something else.

Remarks trigger an email digest roughly fifteen minutes after the first one, to everyone with project access, with each person's own remarks stripped out. The reader-facing walkthrough is in version comments.

What these prompts will not get you

The output is static. That is not a limitation of the prompts, it is the shape of the thing they produce, and it is worth knowing before you spend an afternoon.

If what you actually need is an app with accounts and a database, none of this is your answer and no prompt will make it one. If what you need is a page that says the right thing and can be sent to somebody today, the six above are the whole path.

Frequently asked questions